JEP 401 -- reflection and class literals

Gernot Neppert mcnepp02 at
Sun Jun 27 17:54:52 UTC 2021

Am 27.06.2021 um 18:42 schrieb Peter Levart:
> ...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

Exactly - thank you for acknowleding the point I was trying to make!

> 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. 

Hmm, if you otherwise agree that we do not need distinct type-mirrors, 
this argument looks a bit weak to me.

If there was only one type mirror per primitive class and thus no 
overloading on "by-value-ness" possible, I don't think you would 
actually need those kind of query-methods.

It would surely suffice to be able to test the "by-value-ness" of  the 
parameters after getting hold of the method/constructor!

More information about the valhalla-spec-observers mailing list