On Mon, Apr 27, 2020 at 5:27 AM Matej Novotny <manovotn(a)redhat.com> wrote:
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:
> 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?