<div dir="ltr"><div dir="ltr"><span style="font-size:0.875rem">On Mon, Apr 27, 2020 at 5:27 AM Matej Novotny <<a href="mailto:manovotn@redhat.com">manovotn@redhat.com</a>> wrote:</span><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Forwarding this email to weld-dev to make it public<br>So, the Foo<String> is the required parameterized type here and Foo<E> is parameterized bean type.<br></blockquote><div><br></div><div>Yes; that's right.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
And from CDI spec[1]:<br>
> A parameterized bean type is considered assignable to a parameterized required type if they have identical raw type and for each parameter:<br>
> * 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<br>
<br>
Isn't that the same case? Or am I just running low on caffeine? :)<br></blockquote><div><br></div><div>Right, I know that's the case but…well, here:</div><div><br></div><div>So Weld (apparently) implements covariant type matching rules (and invariant type matching rules used by the covariant ones). They are in the <font face="monospace">CovariantTypes</font> and <font face="monospace">InvariantTypes</font> 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.</div><div><br></div><div><a href="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/CovariantTypes.java</a><br></div><div><a href="https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/resolution/InvariantTypes.java">https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/resolution/InvariantTypes.java</a></div><div><br></div><div>Then, in <font face="monospace">BeanTypeAssignabilityRules</font>, 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:</div><div><br></div><div><a href="https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/resolution/BeanTypeAssignabilityRules.java">https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/resolution/BeanTypeAssignabilityRules.java</a><br></div><div><br></div><div>It looks like this case is specially handled by that (CDI specific) logic, not by the JLS logic. Because the bounds of <font face="monospace">E</font> at the moment that the test runs are exactly <font face="monospace">Object</font>, not exactly <font face="monospace">String</font>. And I didn't think a reference of type <font face="monospace">Foo<String></font> could accept a reference of type <font face="monospace">Foo<Object></font>. </div><div><br></div><div>Is all this correct?</div><div><br></div><div>Best,</div><div>Laird</div></div></div>