JEP 401 -- reflection and class literals
Brian Goetz
brian.goetz at oracle.com
Wed Jun 23 18:39:02 UTC 2021
> 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.
More information about the valhalla-spec-observers
mailing list