JEP 401 -- reflection and class literals
Gernot Neppert
mcnepp02 at googlemail.com
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