Arc: select(rawType) does not match beans implementing parameterized types

[yrodiere]

Describe the bug

As seen in #20347, Arc.container().beanManager().createInstance().select(ValueExtractor.class) does not match a bean implementing ValueExtractor<List<?>>, for example.

I managed to work around that in #20382 , but I believe this impacts users as well as our extensions, and should probably get fixed.

Expected behavior

Arc.container().beanManager().createInstance().select(ValueExtractor.class) should match a bean implementing ValueExtractor<List<?>>.

Actual behavior

Arc.container().beanManager().createInstance().select(ValueExtractor.class) does not match a bean implementing ValueExtractor<List<?>>.

How to Reproduce?

Seems trivial to reproduce, but if you need a quick way: revert 01c1c7f and see how io.quarkus.hibernate.validator.test.valueextractor;.SingletonCustomValueExtractorTest starts failing because io.quarkus.hibernate.validator.runtime.HibernateValidatorRecorder#initializeValidatorFactory is unable to retrieve beans of type ValueExtractor (around line 135).

Output of uname -a or ver

No response

Output of java -version

No response

GraalVM version (if different from Java)

No response

Quarkus version or git rev

No response

Build tool (ie. output of mvnw --version or gradlew --version)

No response

Additional information

This seems caused by an incorrect implementation in BeanTypeAssignabilityRules.

According to the javadoc on io.quarkus.arc.impl.BeanTypeAssignabilityRules#matches(java.lang.Class<?>, java.lang.reflect.ParameterizedType):

     * A parameterized bean type is considered assignable to a raw required type if the raw types are identical and all type
     * parameters of the bean type are
     * either unbounded type variables or java.lang.Object.

So according to this definition, ValueExtractor<T> is assignable to ValueExtractor, but ValueExtractor<List<?>> is not.

Personally, I think this method should return true as soon as the raw types are equal.

[quarkus-bot]

/cc @manovotn, @mkouba

[mkouba]

This works as required by the spec: "A parameterized bean type is considered assignable to a raw required type if the raw types are identical and all type parameters of the bean type are either unbounded type variables or java.lang.Object"; see also https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters.

[mkouba]

I'm going to close this issue but feel free to reopen if you need more info.

[yrodiere]

Well, that's a surprising way to define "assignable". But I guess there's no way around it. Thanks for the answer!

[mkouba]

TBH I don't remember the reasoning behind this particular requirement but it was in the spec since v1.0. A similar discussion was held about the required raw type - see https://issues.redhat.com/browse/CDI-517, and the output was that a similar usage of raw types is discouraged by the JLS, i.e. is not something we'd like to promote for a type-safe dependency injection.