[External] : Re: JEP 401 -- reflection and class literals

Gernot Neppert mcnepp02 at googlemail.com
Wed Jun 30 14:05:57 UTC 2021

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 mailing list