JEP 401 -- reflection and class literals

[Gernot Neppert]

Am So., 27. Juni 2021 um 11:59 Uhr schrieb Remi Forax <forax at univ-mlv.fr>:

> 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().
>
> Not having a syntax for Point.ref.class/Point.val.class is important
> because as you say it's inconsistent, for good, with Point being either an
> identity class or a primitive object class.
> Not surfacing that inconsistency in the language make things easier to
> understand and using methods of java.lang.Class instead make the intent
> more clear at the expanse of being more verbose.
>
> regards,
> Rémi
>

OTOH, proper "value-favoring" primitive classes are *meant to* be passed
around by-value, right?

So, given

primitive class Point {
Point transform(Point origin);
}

programmers might by deeply puzzled to find out that this will fail:

/*1*/ Point.class.getMethod("transform", Point.class);

...and they are instead expected to write

/*2*/ Point.class.getMethod("transform",
Point.class.asPrimitiveObjectClass());

Does that really "make the intent more clear", as you claim?

I think, being able to write

/*3*/ Point.class.getMethod("transform", Point.val.class);

would better express the intent.
However, being able to use /*1*/ without further ado would be even more
consistent - which would be automatically possible if the meaning of
"T.class" did depend on the "value/reference-favoring"
characteristic of the primitive type. Back to square one :)