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]:
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? :)
Matej
_________________________________________________________________________________
[1] https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters
----- Original Message -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "Matej Novotny" <manovotn(a)redhat.com>
Sent: Sunday, April 26, 2020 10:52:57 PM
Subject: Odd type assignability test
Hello; I ran across this test during some code reading to better understand
type assignability. It's in BeanTypeAssignabilityTest.java:
@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));
}
Am I reading this right? Is this saying that a reference of type
Foo<String> should be able to receive a Foo<E>, where E doesn't extend
String?
I understand that any method that declares a type variable E and returns a
Foo<E> will happen to produce a compatible reference. That is:
public <E> Foo<E> blatz() { /* ... */ }
can be called like this:
final Foo<String> foo = blatz(); // should work; E's upper bounds will be
String here
But in this test, E has no upper bounds, so how does it work?
Thanks,
Laird
7:38 a.m.
New subject: Odd type assignability test
Dne 27. 04. 20 v 14:26 Matej Novotny napsal(a):
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]:
> 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? :)
I think that you're right. Foo<E> is basically Foo<E extends Object> and
according to the rules String is assignable to Object.
Matej
_________________________________________________________________________________
[1] https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters
----- Original Message -----
> From: "Laird Nelson" <ljnelson(a)gmail.com>
> To: "Matej Novotny" <manovotn(a)redhat.com>
> Sent: Sunday, April 26, 2020 10:52:57 PM
> Subject: Odd type assignability test
>
> Hello; I ran across this test during some code reading to better understand
> type assignability. It's in BeanTypeAssignabilityTest.java:
>
> @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));
> }
>
> Am I reading this right? Is this saying that a reference of type
> Foo<String> should be able to receive a Foo<E>, where E doesn't
extend
> String?
>
> I understand that any method that declares a type variable E and returns a
> Foo<E> will happen to produce a compatible reference. That is:
>
> public <E> Foo<E> blatz() { /* ... */ }
>
> can be called like this:
>
> final Foo<String> foo = blatz(); // should work; E's upper bounds will be
> String here
>
> But in this test, E has no upper bounds, so how does it work?
>
> Thanks,
> Laird
>
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
--
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 -----
From: "Laird Nelson" <ljnelson(a)gmail.com>
To: "weld-dev" <weld-dev(a)lists.jboss.org>
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 < 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?
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
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
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 -----
From: "Matej Novotny" <manovotn(a)redhat.com>
To: "Laird Nelson" <ljnelson(a)gmail.com>
Cc: "weld-dev" <weld-dev(a)lists.jboss.org>
Sent: Tuesday, April 28, 2020 9:21:19 AM
Subject: 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:51:54 PM
> Subject: Re: [weld-dev] 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?
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
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
_______________________________________________
weld-dev mailing list
weld-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
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:
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...
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 -----
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
1705
days inactive
1706
days old
7 comments
3 participants
participants (3)
-
Laird Nelson -
Martin Kouba -
Matej Novotny