7:13 p.m.
I found a need to look at section 2.2.1 of the specification (
https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#legal_bean_types
).
It says (in part, and I quote):
- A bean type may be an array type. Two array types are considered
identical only if the element type is identical.
- A bean type may be a primitive type. Primitive types are considered to
be identical to their corresponding wrapper types in java.lang.
I want to ask a question about the word "identical" in the bullet points
above. I'll refer to the bullet points above as #1 and #2 respectively.
Obviously (for example) Object.class is identical to Object.class. This
cannot be in doubt.
Next, let's look at #2. #2 effectively says that for the purposes of CDI,
int.class is "identical to" Integer.class. This is true in CDI even
though int.class
!= Integer.class and int.class.equals(Integer.class). I understand this
fully; this is effectively boxing and unboxing conversions as defined by
the JLS (
https://docs.oracle.com/javase/specs/jls/se13/html/jls-5.html#jls-5.1.7).
Now consider int[].class and Integer[].class.
In Java, this doesn't compile (obviously):
final Integer[] integers = new int[0];
And this doesn't compile either (equally obviously):
final int[] ints = new Integer[0];
But in #1, the second sentence (together with section 5.2.1 where typesafe
resolution is discussed) seems to indicate that *for the purposes of CDI* a
target type of Integer[].class should be able to conceptually accept a bean
type of int[].class (and vice versa).
This would seem to be the case because Integer[].class.getComponentType()
is Integer.class, and int[].class.getComponentType() is int.class, and
(according to #2) Integer.class is "identical to" int.class.
Was this the intention? Was it intended that, for example, a producer
method that returns int[] should be able to have its return value converted
by the container so that it "fits in" an injection point of type
Integer[].class? Or was this imprecise use of language, where "identical"
in #2 doesn't apply to #1?
Thanks,
Best,
Laird
10:34 a.m.
Hello Laird,
the two bullet points IMO do not have an overlap, e.g. your bean can be an array type but
there is no (un)boxing there, or it can be a primitive type in which case there is
(un)boxing.
As for section 5.2.1, it says:
The bean has a bean type that matches the required type. For this
purpose, primitive types are considered to match their corresponding wrapper types in
java.lang and array types are considered to match only if their element types are
identical.
I don't see this imply any unboxing for arrays with primitive types but we might both
have different understanding of it.
And a quick test in Weld shows me that it's currently done the way I described.
Was this the intention? Was it intended that, for example, a producer
method
that returns int[] should be able to have its return value converted by the
container so that it "fits in" an injection point of type Integer[].class ?
Or was this imprecise use of language, where "identical" in #2 doesn't
apply
to #1?
If you think it's unclear, feel free to propose better wording in CDI.
They're using GH issues now - https://github.com/eclipse-ee4j/cdi
Regards
Matej
----- Original Message -----
> From: "Laird Nelson" <ljnelson(a)gmail.com>
> To: weld-dev(a)lists.jboss.org
> Sent: Wednesday, February 26, 2020 7:13:22 PM
> Subject: [weld-dev] Clarification question on CDI specification section 2.2.1
>
> I found a need to look at section 2.2.1 of the specification (
> https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#legal_bean_types
> ).
>
> It says (in part, and I quote):
>
>
>
>
> * A bean type may be an array type. Two array types are considered
> identical only if the element type is identical.
> * A bean type may be a primitive type. Primitive types are considered to
> be identical to their corresponding wrapper types in java.lang .
>
> I want to ask a question about the word "identical" in the bullet points
> above. I'll refer to the bullet points above as #1 and #2 respectively.
>
> Obviously (for example) Object.class is identical to Object.class . This
> cannot be in doubt.
>
> Next, let's look at #2. #2 effectively says that for the purposes of CDI,
> int.class is "identical to" Integer.class . This is true in CDI even
though
> int.class != Integer.class and int.class.equals(Integer.class) . I
> understand this fully; this is effectively boxing and unboxing conversions
> as defined by the JLS (
> https://docs.oracle.com/javase/specs/jls/se13/html/jls-5.html#jls-5.1.7 ).
>
> Now consider int[].class and Integer[].class .
>
> In Java, this doesn't compile (obviously):
>
>
>
>
> final Integer[] integers = new int[0];
>
> And this doesn't compile either (equally obviously):
>
>
>
>
> final int[] ints = new Integer[0];
>
> But in #1, the second sentence (together with section 5.2.1 where typesafe
> resolution is discussed) seems to indicate that for the purposes of CDI a
> target type of Integer[].class should be able to conceptually accept a bean
> type of int[].class (and vice versa).
>
> This would seem to be the case because Integer[].class.getComponentType() is
> Integer.class , and int[].class.getComponentType() is int.class , and
> (according to #2) Integer.class is "identical to" int.class .
>
Was this the intention? Was it intended that, for example, a producer
method
that returns int[] should be able to have its return value converted by the
container so that it "fits in" an injection point of type Integer[].class ?
Or was this imprecise use of language, where "identical" in #2 doesn't
apply
to #1?
>
> Thanks,
> Best,
> Laird
>
> _______________________________________________
> weld-dev mailing list
> weld-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
1520
days inactive
1521
days old
1 comments
2 participants
participants (2)
-
Laird Nelson -
Matej Novotny