Make Converter side by side with Config

[Emily-Jiang]

Some other specs such as JNoSQL, Reactive Messaging need a way to convert from String to other Object or some other types. At the moment, the convert is attached to config. You will have to get a config and then use the converter. If the config is not needed, there is no need to build the config.

It will be great to make converter surfaced up and have its own identity. We could have ConverterProvider.getConverter() or use the current ConfigProvider.getConverter() without the need to build a config.

[dmlloyd]

I like this idea. But, I really think it suggests a separate MP specification since the use cases fall outside of configuration. If a new MP specification is initiated, then MP Config could replace its conversion mechanism with it in a future version.

[radcortez]

I also agree it makes more sense to have a separate Convert API that every spec could benefit from.

[kenfinnigan]

I see two approaches:

1. Config develops a Converter API for itself, which gets replaced in the future if/when MP has a separate Converter API, but it's an API focused on Config conversion only
2. Do nothing around a Converter API and wait for it to be done as a separate spec first.

[Emily-Jiang]

Thanks @dmlloyd @radcortez @kenfinnigan ! I'll open a discussion on microrpofile mailinglist to see what others think regarding creating a Converter spec.

[emattheis]

+1 for embracing an external spec for converters if such a thing emerges, but I don't think we want to promote the idea that you should use MicroProfile Config as a factory for such converters.

[Emily-Jiang]

@emattheis If the converter is going to be a spec, config will depend on it, not the other way around.

[emattheis]

@Emily-Jiang understood. I just want to make sure we don't encourage use of Config's converters for non-Config scenarios in the interim if we move forward with #495.

[dmlloyd]

A means to convert in the context of a configuration (i.e. #495) and a means to acquire a converter in the context of a configuration (i.e. #492) are both useful, because sometimes configuration code needs to convert values in special circumstances but still using the converters that were registered with the configuration, which is not something a separate converter spec will replace. Even if there is a separate converter spec, someone somewhere still has to specify the converters to use for a configuration. We often use specialized converters within Quarkus for example (e.g. to convert Enum-typed values using special mapping rules or to support an abbreviated syntax for Duration, to name a couple cases). These converters are specific to the configuration, not the application or any other larger scope.

So therefore I think it's clear that even if we moved forward with an external spec, #492 and #495 should both move forward as well.

[dmlloyd]

@Emily-Jiang understood. I just want to make sure we don't encourage use of Config's converters for non-Config scenarios in the interim if we move forward with #495.

I don't think this would be a disaster, especially given that we can drop in the spec converter types in replacement in a 2.0 or 3.0 of MP Config. I can't think of a case that we are (or are proposing) usage of converters that would be a problem in light of a separate specification.

[dmlloyd]

I think it was agreed that this should be done in a separate specification.