Re: [weld-dev] Odd type assignability test
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "weld-dev" <weld-dev(a)lists.jboss.org>
Sent: Monday, April 27, 2020 5:20:26 PM
Subject: Re: [weld-dev] Odd type assignability test
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[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.
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...
Yes, these two are pretty much JLS rules.
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:
https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/wel...
Yes, this is also correct.
Note that there are also EventTypeAssignabilityRules,
DelegateInjectionPointAssignabilityRules - each implementing some of the spec bits.
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> .
Also correct, but I cannot tell you why it was designed like this.
I have no idea what is a the basis for such use case :)
Is all this correct?
Best,
Laird
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev