Re: [weld-dev] Odd type assignability test
On Tue, Apr 28, 2020 at 5:09 AM Matej Novotny 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 ___ weld-dev mailing list weld-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev
Re: [weld-dev] 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 and List you can have a singular producer method that
returns List
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"
> To: "Laird Nelson"
> Cc: "weld-dev"
> Sent: Tuesday, April 28, 2020 9:21:19 AM
> Subject: Re: [weld-dev] Odd type assignability test
>
>
>
> - Original Message -
> > From: "Laird Nelson"
> > To: "weld-dev"
> > 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 < mko...@redhat.com > wrote:
> >
> >
> > I think that you're right. Foo is basically Foo 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 void testFooStringAssignableFromFooE() {
> > Type a = new TypeLiteral>() {
> > }.getType();
> > Type b = new TypeLiteral>() {
> > }.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 void testStringFooMatchesVariableFoo() throws Exception {
> > Type stringFooType = new TypeLiteral>() {
> > }.getType();
> > Type variableFooType = new TypeLiteral>() {
> > }.getType();
> > Assert.assertTrue("Foo should match Foo",
> > 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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/weld-dev
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
Re: [weld-dev] Odd type assignability test
- Original Message -
> From: "Laird Nelson"
> To: "weld-dev"
> 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 < mko...@redhat.com > wrote:
>
>
> I think that you're right. Foo is basically Foo 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 void testFooStringAssignableFromFooE() {
> Type a = new TypeLiteral>() {
> }.getType();
> Type b = new TypeLiteral>() {
> }.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 void testStringFooMatchesVariableFoo() throws Exception {
> Type stringFooType = new TypeLiteral>() {
> }.getType();
> Type variableFooType = new TypeLiteral>() {
> }.getType();
> Assert.assertTrue("Foo should match Foo",
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
Re: [weld-dev] 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 is the required parameterized type here and Foo 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 is basically Foo 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"
>> To: "Matej Novotny"
>> 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 void testStringFooMatchesVariableFoo() throws Exception {
>> Type stringFooType = new TypeLiteral>() {
>> }.getType();
>> Type variableFooType = new TypeLiteral>() {
>> }.getType();
>> Assert.assertTrue("Foo should match Foo",
>> getRules().matches(stringFooType, variableFooType));
>> }
>>
>> Am I reading this right? Is this saying that a reference of type
>> Foo should be able to receive a Foo, where E doesn't extend
>> String?
>>
>> I understand that any method that declares a type variable E and returns a
>> Foo will happen to produce a compatible reference. That is:
>>
>> public Foo blatz() { /* ... */ }
>>
>> can be called like this:
>>
>> final Foo 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
--
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
