Martin poked around this some more and found some interesting bits. If you want to uncover why it is like this, take a look at: * CDI-389[1] * Related email discussion[2] * Slightly related DS issue[3]
I glanced over it and my understanding is that at some point it was actually written the other way around (1.1), but then reverted(1.2). The reason was producer methods - any bean with generics needs to be dependent scoped and once you have a dependent scoped producer method, then you can produce different bean for each injection point. E.g. for injection points List<Integer> and List<String> you can have a singular producer method that returns List<E> and it should be able to satisfy both IPs (when you inspect the IP via InjectionPoint metadata). But I think you could also easily have a producer that will throw a class cast exception at runtime... Matej _____________________________________________________________________________________ [1] https://issues.redhat.com/browse/CDI-389 [2] https://lists.jboss.org/pipermail/cdi-dev/2013-July/004283.html [3] https://issues.apache.org/jira/browse/DELTASPIKE-405 ----- Original Message ----- > From: "Matej Novotny" <[email protected]> > To: "Laird Nelson" <[email protected]> > Cc: "weld-dev" <[email protected]> > Sent: Tuesday, April 28, 2020 9:21:19 AM > Subject: Re: [weld-dev] Odd type assignability test > > > > ----- Original Message ----- > > From: "Laird Nelson" <[email protected]> > > To: "weld-dev" <[email protected]> > > Sent: Monday, April 27, 2020 5:51:54 PM > > Subject: Re: [weld-dev] Odd type assignability test > > > > > > On Mon, Apr 27, 2020 at 5:38 AM Martin Kouba < [email protected] > wrote: > > > > > > I think that you're right. Foo<E> is basically Foo<E extends Object> and > > according to the rules String is assignable to Object. > > > > Just to be clear, this test (that I added temporarily to CovariantTypesTest > > and ran just to make sure) fails (as I'd expect): > > > > @Test > > public <E> void testFooStringAssignableFromFooE() { > > Type a = new TypeLiteral<Foo<String>>() { > > }.getType(); > > Type b = new TypeLiteral<Foo<E>>() { > > }.getType(); > > assertTrue(CovariantTypes.isAssignableFrom(a, b)); // kaboom > > } > > > > But this test (the one under discussion) in BeanTypeAssignabilityRules > > succeeds (obviously or Weld's test suite would be broken): > > > > @Test > > public <E> void testStringFooMatchesVariableFoo() throws Exception { > > Type stringFooType = new TypeLiteral<Foo<String>>() { > > }.getType(); > > Type variableFooType = new TypeLiteral<Foo<E>>() { > > }.getType(); > > Assert.assertTrue("Foo<String> should match Foo<E>", > > getRules().matches(stringFooType, variableFooType)); > > } > > > > So the rules CDI uses to do type matching (represented by > > BeanTypeAssignabilityRules ) are deliberately different from those used by > > JLS (represented by CovariantTypes ), right? > > CovariantTypes/InvariantTypes are used by BeanTypeAssignabilityRules. > My understanding was that CDI dictates some rules, few of which are different > or requiring some extra steps compared to pure JLS. That's why during > evaluation you go through BeanTypeAssignabilityRules and whenever applicable > you delegate to Covariant/InvariantTypes. > > > > > Best, > > Laird > > > > _______________________________________________ > > weld-dev mailing list > > [email protected] > > https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ > weld-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev > _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
