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):
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