[weld-dev] Clarification question on CDI specification section 2.2.1

[Matej Novotny]

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 at gmail.com>
> To: weld-dev at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev