On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov <vladimir.x.iva...@oracle.com> wrote:
> https://bugs.openjdk.java.net/browse/JDK-8032400 > http://cr.openjdk.java.net/~vlivanov/8032400/webrev.00/ > > Consider the following hierarchy: > class T1 { int m() { return 1; }} > class T2 extends T1 { static int m() { return 2; }} > class T3 extends T2 { int m() { return 3; }} > > T3 has a method, which does the following using method handles: > T3::test { invokespecial T1.m() T3 } > > T1.m lookup attempt from T3 ends up as T2.m lookup, but it fails since T2 has > static method with the same signature. Lookup.getDirectMethodCommon doesn't > expect such failure and throws InternalError. > > JVMS specification states the following: > // JVMS 6.5: invokespecial > // ... 2. Otherwise, if C is a class and has a superclass, a search > // for a declaration of an instance method with the same name and > // descriptor as the resolved method is performed, starting with the > // direct superclass of C and continuing with the direct superclass > // of that class, and so forth, until a match is found or no further > // superclasses exist. If a match is found, then it is the method to > // be invoked. > > The fix is to comply with the spec and search upper in the class hierarchy if > lookup attempt fails. > > Testing: regression test, jdk/test/java/lang/invoke, tests on access checks. > Looks ok. The behaviour of MethodHandles.Lookup.findSpecial got me confused for a while :-) Minor point: is it also worth exposing a T3.lookup() method and on the returned Lookup calling findSpecial(T1.class, "m", MethodType.methodType(int.class), T3.class).invokeExact() to ensure the programmatic path also works? Paul.
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ mlvm-dev mailing list mlvm-dev@openjdk.java.net http://mail.openjdk.java.net/mailman/listinfo/mlvm-dev
