How must converters be indexed?

[ljnelson]

Suppose I call Config.getOptionalValue("foo", CharSequence.class).

Suppose there is not a Converter indexed under CharSequence.class directly.

Suppose there is a Converter registered under String.class (there must be, if I read the specification properly, because String has a valueOf() method).

Must the Converter<String> be used in this case by a Config implementation? If so, could you provide the specification reference, please?

Or: Must it not be used? If not, could you provide the specification reference, please? Will an IllegalArgumentException be thrown (I presume that is the exception that is thrown if conversion cannot happen for any reason)?

May it be used? (If this area is undefined, then what, honestly asking, is the purpose of this particular method?)

(The javadoc for getOptionalValue() also does not require that converters be used at all, i.e. it would be legal for a Config implementation to do whatever it wants in this method to perform conversion. But that's a separate issue that was never fully resolved.)

[JHahnHRO]

I don't think that's explicitly specified. However: Certain use cases do use subclasses implicitly, e.g. CDI injection. This works:

class Foo {
@Inject @ConfigProperty(name="foo")
CharSequence cs;
}

This will use the String-Converter, because there must be a CDI bean (necessarily a producer method in this case) of type String with qualifier @ConfigProperty and this injection point resolves to this bean.

However, the way this is implemented (and the only this can be implemented) is that all injection points are scanned at startup (or even at built-time) and a synthetic bean of the corresponding type is registered. Of course, this will not register all possible subtypes. The CharSequence examples only works, because the @ConfigProperty String bean must always be registered anyway.

I have not tried it, but I imagine, this could be a mess if two types in a class hierarchy both qualify for automatic converters. Injection points for the superclass will then resolve to two @ConfigProperty beans.