7:26 a.m.
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.
And from CDI spec[1]:
Isn't that the same case? Or am I just running low on caffeine? :)
Matej
_________________________________________________________________________________
[1] https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters
----- Original Message -----
7:38 a.m.
New subject: Odd type assignability test
Dne 27. 04. 20 v 14:26 Matej Novotny napsal(a):
I think that you're right. Foo<E> is basically Foo<E extends Object> and
according to the rules String is assignable to Object.
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
10:51 a.m.
New subject: Odd type assignability test
On Mon, Apr 27, 2020 at 5:38 AM Martin Kouba <mkouba(a)redhat.com> 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?
Best,
Laird
2:21 a.m.
New subject: Odd type assignability test
----- Original Message -----
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.
7:09 a.m.
New subject: Odd type assignability test
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 -----
11:38 a.m.
New subject: Odd type assignability test
On Tue, Apr 28, 2020 at 5:09 AM Matej Novotny <manovotn(a)redhat.com> wrote:
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]
Oh, that's really funny; I remember being bitten by this bug a long time
ago. Thanks for the extra info.
Best,
Laird
10:20 a.m.
New subject: Odd type assignability test
On Mon, Apr 27, 2020 at 5:27 AM Matej Novotny <manovotn(a)redhat.com> wrote:
Yes; that's right.
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...
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...
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?
Best,
Laird
2:11 a.m.
New subject: Odd type assignability test
----- Original Message -----
Yes, these two are pretty much JLS rules.
Yes, this is also correct.
Note that there are also EventTypeAssignabilityRules,
DelegateInjectionPointAssignabilityRules - each implementing some of the spec bits.
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 :)
1769
days inactive
1770
days old
7 comments
3 participants
participants (3)
-
Laird Nelson -
Martin Kouba -
Matej Novotny