[weld-dev] Odd type assignability test

[Matej Novotny]

----- Original Message -----
> From: "Laird Nelson" <ljnelson at gmail.com>
> To: "weld-dev" <weld-dev at 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 at 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/weld/resolution/CovariantTypes.java
> https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/resolution/InvariantTypes.java

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/weld/resolution/BeanTypeAssignabilityRules.java

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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev