JEP 401 -- reflection and class literals

[Gernot Neppert]

Am 27.06.2021 um 11:58 schrieb Remi Forax:
> I disagree on your last bullet point,
> I think that less is more in that context, we do not have to have a syntax to express the secondary class exactly like we do not allow Foo<String>.class.
> So instead of allowing Point.ref.class and Point.val.class, i think it's better to have no language support given that we can already write Point.class.asPrimitiveObjectClass().
>
I do agree that we might not need syntactic sugar for specifying the 
"byValue-type" of a primitive class, given that the method 
Class#asPrimitiveObjectClass() will be available.

However, using this method in an expression such as:

Point.class.getMethod("transform", Point.class.asPrimitiveObjectClass());

looks overly verbose to me. Plus, the method can be invoked on every 
class, even non-primitive ones. So we might end up seeing useless code like:

Point.class.getMethod("parse", String.class.asPrimitiveObjectClass());

So, let me propse something that may strike the right balance between 
ease-of-use and verbosity, at least for the Java language:

The Java Language specification could mandate that each primitive class 
T shall contain a public final static member of type Class<T>, named 
"VALUE_TYPE".

(specifying auto-generated members for certain types would follow 
precedent set by Enum-classes, see JLS section 8.9.3: Enum Members)

The above code would then look like this, neatly conveying the intent:

Point.class.getMethod("transform", Point.VALUE_TYPE);


Also, please bear in mind that all the Primitive Type Wrappers currently 
have such a public final static member named "TYPE".

After migrating these wrappers to primitive classes, the "TYPE" members 
could be deprecated and supplanted by the standard "VALUE_TYPE" members.

Additionally, it could then be advertized in JavaDoc that the canonical 
way of specifying a type-mirror for the legacy primitives should be 
"[primitive-wrapper-class].VALUE_TYPE" instead of 
"[primitive-type-name].class".

In the long term, we wouldn't be seeing ugly "int.class" anymore, and 
this would lead to highly consistent code such as:

Point.class.getMethod("move", Point.VALUE_TYPE, Integer.VALUE_TYPE);