[External] : Re: JEP 401 -- reflection and class literals
mcnepp02 at googlemail.com
Wed Jun 30 14:40:08 UTC 2021
Sorry, I don't know what to make of your latest reply - maybe I'm not
expressing myself clearly.
What I was referring to was that, until quite recently, the proposal (1)
said that T.class should denote the non-nullable type for a value-favoring
primitive class and the nullable type for a reference-favoring one.
The latest propsal (2) suggests to have T.class always refer to the
nullable type. Right?
Now, for our famous value-favoring primitive type Point,
the most common usecase will be methods such as transform(Point pt);
Less common will be methods such as move(Point.ref pt) that require some
additional thinking & typing.
With the proposal (1):
In reflective code, the common usecase of finding "transform" would simply
require Point.class.getMethod("transform", Point.class),
whereas finding "move" would require some more afterthought, either
Point.class.getMethod("move", Point.ref.class) or
This looks consistent to me.
With the new proposal (2):
In reflective code, the common usecase of finding "transform" would now
require either Point.class.getMethod("transform", Point.val.class) or
This strikes me as inconsistent, and that's all there is to it :)
Am Mi., 30. Juni 2021 um 16:09 Uhr schrieb Brian Goetz <
brian.goetz at oracle.com>:
> Internally, there pretty much have to be, unless we want to entirely
> rewrite reflection, MethodHandle, MethodType, etc, to use something other
> than jl.Class to represent field descriptors. Not being able to
> distinguish between LFoo and QFoo in reflection/method handles would be a
> no-go. So when you pull on that string ...
> On 6/30/2021 10:05 AM, Gernot Neppert wrote:
> Well, if you guys decide that there will be two distinct type-mirrors per
> primitive class, the tools to distinguish overloaded methods will obviously
> be there, no matter what the details were.
> I was merely pointing out that reflective use would be more consistent
> with non-reflective use if the expression "T.class" took into account the
> value/reference-favoring flavour: the most concise notation would work "as
> expected" for the most common usecase, while the less likely scenarios
> would require more boilerplate code...
> Am Mi., 30. Juni 2021 um 15:30 Uhr schrieb Brian Goetz <
> brian.goetz at oracle.com>:
>> Now, what is getMethod() supposed to do? A fuzzy match? That's a pretty
>> massive departure from what "getMethod" has historically meant. (And, for
>> MethodHandles, its worse; lookup is supposed to be precise.)
>> The reality is these overloads are going to happen, and reflection needs
>> sharp enough tools to distinguish between them.
More information about the valhalla-spec-observers