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

[Brian Goetz]

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