Must a Config actually use Converters?

The Config interface of course does not refer to them at all.

The ConfigBuilder interface accepts them but there does not seem to be a requirement anywhere I can find that these Converters actually be used by a Config implementation.

By contrast, ConfigSources, which are also accepted by a ConfigBuilder, clearly show up in the Config interface (although they give rise to another issue whose comment section apparently augments the specification).

The specification around Converters also mentions, at the bottom:

If a Converter implements the java.lang.AutoCloseable interface then the close() method will be called when the underlying Config is being released.

What does “underlying” mean?

Also this implies that an autocloseable Converter must be used in some unspecified way by exactly one Config instance, or it will be at risk of being closed improperly from the viewpoint of some other Config instance. This doesn’t seem to be spelled out anywhere.

For clarity: clearly I understand the intent is that conversion must happen using Converter instances during the Config#getValue(String, Class) method in some hazy way. But it seems to me there is no such requirement anywhere.

If such conversion must be used, is it reasonable to provide a getConverters() method on Config, much as there is a getConfigSources() method on Config?

Is it therefore also reasonable to suggest that there be a full specification of how conversion must behave when the getValue(String, Class) and getOptionalValue(String, Class) methods are invoked?

[dmlloyd]

I agree that the specification quality is very sub-par. This has caused us many headaches as well maintaining SmallRye Config and Quarkus. I’m hoping that if we can get past #443 and #445, we can follow up with some proposals which would greatly improve the specification language.

[kenfinnigan]

@ljnelson https://github.com/eclipse/microprofile-config/pull/498 contains the changes