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
