JEP 401 -- reflection and class literals

[Peter Levart]

On 26/06/2021 17:41, Peter Levart wrote:
> What I'm asking is this: why couldn't the following always hold (local 
> vars):
>
> Foo.val v = ...
> Foo.ref r = ...
>
> assert v.getClass() == Foo.val.class;
> assert r.getClass() == Foo.ref.class;


I knew this was a stupid question. Immediately after considering:

Object vo = v;
Object ro = r;

assert vo.getClass() == ???;
assert ro.getClass() == ???;


...I realized that the primitive class type (val vs. ref) is not a 
property of the object, but rather the property of how its value is 
passed around and stored by VM. Since .getClass() can only return 
something that characterizes the object and not how its value is stored 
or passed, the primitive class type (through Q or L descriptors) is more 
a property of a field or array element or method parameter or method 
return as Gernot Nappert said in his reply:


On 24/06/2021 09:16, Gernot Neppert wrote:
> I'm reading your various proposals to reconcile descriptors with 
> type-mirrors, and they all seem to have their awkward corner-cases.
>
> Granted, we have "Q-type" descriptor vs. "L-type" descriptors for 
> class members, method argumens and method return-types, and we need to 
> make this disctinction visible *somehow* via reflection.
>
> But: do we really need to have two different type-mirrors 
> corresponding to these descriptors?
> Isn't the "Q-ness" rather a property of the Field, method Parameter or 
> method return-type, and therefore should be available there via 
> reflection as a simple boolean property?
>
> Given a value-favoring class "Point" and the following declaration:
>
> public class Foo {
>
>     Point.ref pt;
>
>    public void setPoint(Point p) {
>         this.pt = pt;
>
>     }
>
>     public Point.ref getPoint() {
>         return pt;
>     }
> }
>
> Extending the reflection API for the corresponding classes from 
> java.lang.reflect would look something like this:
>
> assertFalse(Point.class.getDeclaredField("pt").isByValue());
>
> assertTrue(Point.class.getMethod("setPoint", 
> Point.class).getParameters()[0].isByValue());
>
> assertFalse(Point.class.getMethod("getPoint").getParameters()[0].isReturnByValue()); 



Extending reflection API in this way could work for querying the 
properties of fields, methods and constructors, but there are also those 
"find me a method / constructor with specific parameter types" 
reflection methods:

Class.get(Declared)Method(String name, Class<?>... parameterTypes)
Class.get(Declared)Constructor(Class<?>... parameterTypes)

It would be possible, but awkward to add methods like:

Class.get(Declared)Method(String name, Class<?>[] parameterTypes, 
boolean[] parameterByValue)


Seems like we are forced to re-use Class objects to hold this additional 
info. Remi says that there should only be "primary" (ref type) primitive 
class literals (Foo.class) and no (Foo.ref.class or Foo.val.class) and 
that val type mirrors should be obtained by calling a method (such as 
Foo.class.asPrimitiveValType()), but that makes methods/constructors 
using val-typed parameters second class citizens when using reflection. 
There's nothing wrong with Foo.ref.class and Foo.val.class per-se. It 
seems the question is more whether we actually need type mirrors for 
val-types and not how to obtain them (Foo.val.class is surely nicer than 
Foo.class.asPrimitiveValType() and not a bit less expressive).

We already have two kinds of primitive class type mirrors since 
primitive types are going to be retro-fitted as primitive classes 
(int.class vs. Integer.class). So today, when you say:

Math.class.getMethod("min", Integer.class, Integer.class)

...you get "NoSuchMethodException", so there's no fuzziness in matching 
the parameter types. You have to use the correct type mirrors:

Math.class.getMethod("min", int.class, int.class)


So I thing introducing fuzziness for primitive class parameter types 
except for retrofitted primitive types would just make things more 
irregular.

I also think what Brian proposed (Foo.class is aligned with .getClass()) 
is pretty consistent when you think about it long enough.


Regards, Peter