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

Laird Nelson ljnelson at gmail.com
Wed Feb 26 13:13:22 EST 2020


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20200226/663edda9/attachment.html 


More information about the weld-dev mailing list