JEP 401 -- reflection and class literals

Dan Smith daniel.smith at
Wed Jun 23 18:54:30 UTC 2021

> On Jun 23, 2021, at 12:39 PM, Brian Goetz <brian.goetz at> wrote:
>> We can "fix" this behavior by supporting "fuzzy matching" in the 'getMethod' method, so that both Point.val.class and Point.ref.class are considered matches for Point.val.class in method signatures. That feels to me like a bridge too far in our efforts to hide complexity from API users. YMMV. (Also doesn't work great if the language supports val/ref overloads; I think we lean towards *not* supporting these.)
> We can surely try to prevent them, but I don't think it really does it much good in this area.  We will surely not want the JVM to be trying to figure out at class load time that:
>     class Foo { (LPoint;LString;I)V m }
>     class Bar extends Foo { (QPoint;LString;I) m }
> that Bar is an invalid class.  So given that classfiles will have these potential conflicts, getMethod(Point.class, String.class, int.class) would have to do the fuzzy thing anyway, and that's a mess.

Oh, sure, not suggesting a JVM validation check here. However, if the language rejects these overloads, then reflection could do something reasonable to just pick one when it encounters them (just like you can overload on return types in the JVM, but 'getMethod' doesn't let you explicitly disambiguate).

But anyway, if there are distinct Class objects for QPoint and LPoint, I don't love the idea of 'getMethod' letting the LPoint class object ever match a QPoint descriptor, regardless of any overloads present.

More information about the valhalla-spec-observers mailing list