[9] RFR (S): 8032400: JSR292: invokeSpecial: InternalError attempting to lookup a method

[Paul Sandoz]

On Jun 4, 2014, at 5:25 PM, Vladimir Ivanov <vladimir.x.ivanov at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://mail.openjdk.java.net/pipermail/mlvm-dev/attachments/20140605/2f63dbd3/signature.asc>