JEP 401 -- reflection and class literals

[Brian Goetz]

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