JDK-8022074 : IncompatibleClassChangeError when creating method reference to outer class private method
  • Type: Bug
  • Component: tools
  • Sub-Component: javac
  • Affected Version: 8,8-repo-lambda
  • Priority: P2
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2013-08-01
  • Updated: 2019-09-19
  • Resolved: 2013-10-04
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Resolved
Related Reports
Blocks :  
Blocks :  
Relates :  
Description
Following code causes IncompatibleClassChangeError to be thrown:

interface MyFunctionalInterface {
    void invokeMethodReference(int a);
}

public class Test {
    private void m(int a) {
        System.out.println(a);
    }
    void test() {
        class Inner {
            MyFunctionalInterface createMethodReference() {
                m(12);
                return Test.this::m;
            }
        }
        MyFunctionalInterface fi = new Inner().createMethodReference();
        fi.invokeMethodReference(1);
    }

    public static void main(String argv[]) {
        new Test().test();
    }
}

The output is:
12
Exception in thread "main" java.lang.IncompatibleClassChangeError
	at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:384)
	at Test$1Inner.createMethodReference(Test.java:13)
	at Test.test(Test.java:16)
	at Test.main(Test.java:21)
Caused by: java.lang.IllegalAccessException: member is private: Test.m(int)void/invokeSpecial, from Test$1Inner
	at java.lang.invoke.MemberName.makeAccessException(MemberName.java:742)
	at java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:1173)
	at java.lang.invoke.MethodHandles$Lookup.checkMethod(MethodHandles.java:1136)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(MethodHandles.java:1247)
	at java.lang.invoke.MethodHandles$Lookup.getDirectMethod(MethodHandles.java:1237)
	at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(MethodHandles.java:1329)
	at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(MethodHandleNatives.java:382)
	... 3 more

Method m is successfully invoked while creating method reference to it fails.

This has occurred on lambda b100(x64), Windows7x64.
Comments
This is a MethodHandle bug, dup of JDK-8022720
04-10-2013

This says: If m is private, then m is accessible if and only if C is T, or C encloses T, or T encloses C, or T and C are both enclosed by a third class. So, the big question mark is that this 292 bug does not have 8 as its fix version.
04-10-2013

It is the latter, the accessor is being generated, it however is not being used. Test gets a static access$000 method. But the bootstrap in Test$1Inner directly refers to Test.m(). So the MethodHandle code throws an exception.
04-10-2013

This is not related to the cluster of interface private issues. Two things to investigate: is the inner class private method accessor not being generated in this case? Or generated but not used?
04-10-2013

Affected tests: lang/LMBD/lmbd140/lmbd14003m0202/lmbd14003m0202 lang/LMBD/lmbd140/lmbd14003m1012/lmbd14003m1012 lang/LMBD/lmbd140/lmbd14004m1101/lmbd14004m1101 lang/LMBD/lmbd140/lmbd14004m201/lmbd14004m201 lang/LMBD/lmbd140/lmbd14004m3111/lmbd14004m3111 lang/LMBD/lmbd140/lmbd14005m2002/lmbd14005m2002 lang/LMBD/lmbd140/lmbd14005m5102/lmbd14005m5102 lang/LMBD/lmbd140/lmbd14006m2002/lmbd14006m2002 lang/LMBD/lmbd140/lmbd14007m0021/lmbd14007m0021 lang/LMBD/lmbd140/lmbd14007m01101/lmbd14007m01101 lang/LMBD/lmbd140/lmbd14007m1011/lmbd14007m1011 lang/LMBD/lmbd140/lmbd14007m2001/lmbd14007m2001 lang/LMBD/lmbd140/lmbd14007m401/lmbd14007m401 lang/LMBD/lmbd140/lmbd14008m3012/lmbd14008m3012 lang/LMBD/lmbd140/lmbd14008m4002/lmbd14008m4002 lang/LMBD/lmbd140/lmbd14008m41121/lmbd14008m41121 lang/LMBD/lmbd140/lmbd14008m51021/lmbd14008m51021
02-10-2013

Test names moved from JCK-7301601 to make Aurora happy lang/LMBD/lmbd140/lmbd14003m0202/lmbd14003m0202_rt lang/LMBD/lmbd140/lmbd14003m1012/lmbd14003m1012_rt lang/LMBD/lmbd140/lmbd14004m1101/lmbd14004m1101_rt lang/LMBD/lmbd140/lmbd14005m2002/lmbd14005m2002_rt lang/LMBD/lmbd140/lmbd14005m5102/lmbd14005m5102_rt lang/LMBD/lmbd140/lmbd14006m2002/lmbd14006m2002_rt RULE lang/LMBD/lmbd140/lmbd14007m0021/lmbd14007m0021_rt Exception any lang/LMBD/lmbd140/lmbd14007m2001/lmbd14007m2001_rt lang/LMBD/lmbd140/lmbd14007m31011/lmbd14007m31011_rt lang/LMBD/lmbd140/lmbd14008m51021/lmbd14008m51021_rt lang/LMBD/lmbd140/lmbd14009m0/lmbd14009m0_rt lang/LMBD/lmbd140/lmbd14009m022/lmbd14009m022_rt lang/LMBD/lmbd140/lmbd14009m04/lmbd14009m04_rt lang/LMBD/lmbd140/lmbd14009m111/lmbd14009m111_rt lang/LMBD/lmbd140/lmbd14009m133/lmbd14009m133_rt lang/LMBD/lmbd140/lmbd14010m0/lmbd14010m0_rt lang/LMBD/lmbd140/lmbd14010m04/lmbd14010m04_rt lang/LMBD/lmbd140/lmbd14010m13/lmbd14010m13_rt lang/LMBD/lmbd140/lmbd14011m0/lmbd14011m0_rt lang/LMBD/lmbd140/lmbd14011m022/lmbd14011m022_rt lang/LMBD/lmbd140/lmbd14011m04/lmbd14011m04_rt lang/LMBD/lmbd140/lmbd14011m111/lmbd14011m111_rt lang/LMBD/lmbd140/lmbd14011m133/lmbd14011m133_rt lang/LMBD/lmbd140/lmbd14012m151/lmbd14012m151_rt
27-09-2013

private methods access related, I originally got this from you last week along with three other bugs. This one is blocked because of the private method access you are working with now. So I guess it's better for this to be in your orbit too. For the rest of the bugs I took from you, one is solved and the other is under revision. Thanks
24-09-2013

This should wait for JDK-8010319 to be solve.
17-09-2013

Following JCK8 Compiler Suite tests fail due to this issue: lang/LMBD/lmbd142/lmbd14201m62/lmbd14201m62.html
03-09-2013

This is a javac bug. The related bug is JDK-8010319.
05-08-2013