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" <[email protected]> > To: [email protected] > 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 > [email protected] > https://lists.jboss.org/mailman/listinfo/weld-dev _______________________________________________ weld-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/weld-dev
