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

Paul Sandoz paul.sandoz at oracle.com
Thu Jun 5 08:07:32 UTC 2014

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?


More information about the core-libs-dev mailing list