Forwarding this email to weld-dev to make it public
So, the Foo<String> is the required parameterized type here and Foo<E> is parameterized bean type.
Yes; that's right.
And from CDI spec[1]:
> A parameterized bean type is considered assignable to a parameterized required type if they have identical raw type and for each parameter:
> * the required type parameter is an actual type, the bean type parameter is a type variable and the actual type is assignable to the upper bound, if any, of the type variable, or
Isn't that the same case? Or am I just running low on caffeine? :)
Right, I know that's the case but…well, here:
So Weld (apparently) implements covariant type matching rules (and invariant type matching rules used by the covariant ones). They are in the CovariantTypes and InvariantTypes classes. To my eyes, these rules are just JLS rules (not CDI specific except for boxing I think) and after staring at them crosseyed for a while they make sense.
Then, in BeanTypeAssignabilityRules, there are specific "matching" rules for the bits laid out in CDI section 5.2.4 that I think differ from the JLS rules, but I might be making a mistake:
It looks like this case is specially handled by that (CDI specific) logic, not by the JLS logic. Because the bounds of E at the moment that the test runs are exactly Object, not exactly String. And I didn't think a reference of type Foo<String> could accept a reference of type Foo<Object>.
Is all this correct?
Best,
Laird