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.
