Subject: Re: Help with javac and Lambda: 8026065: InterfaceMethodref for invokespecial must name a direct superinterface From: Dan Smith Date: 10/24/2013 12:18 PM To: Lois Foltan CC: Robert Field , Karen Kinnear , Kumar Srinivasan , andreas.lundblad@oracle.com, Jan Lahoda , Eric McCorkle , joel.franck@oracle.com, Vicente-Arturo Romero-Zaldivar , Jonathan Gibbons , Alex Buckley , Brian goetz , "HAROLD.SEIGEL Seigel" , Michel Trudeau , Mary lautman On Oct 24, 2013, at 8:48 AM, Lois Foltan wrote: > Additional findings on this topic. The fact that the JCK tests have an inner class may have some bearing on this, however, I also tried a similar test this morning without an inner class: > > interface ParentInterface { > public int testedMethod(); > } > > interface TestedInterface extends ParentInterface { > public default int testedMethod(){ return 1; } > } > > abstract class ParentClass implements TestedInterface { > //empty > } > > class TestedClass extends ParentClass { > public int testedMethod() {return 9;} > public int test() { > return TestedClass.super.testedMethod(); > } > } > > This test case also fails with the newly added VerifyError since TestedClass::test() issues an invokespecial on an indirect InterfaceMethodRef. From the TestClass.class bytecodes > > static int access$001(TestedClass); public int test(); > Code: > 0: aload_0 > 1: invokestatic #3 // Method access$001:(LTestedClass;)I > 4: ireturn > > static int access$001(TestedClass); > Code: > 0: aload_0 > 1: invokespecial #1 // InterfaceMethod TestedInterface.testedMethod:()I > 4: ireturn > } > > > The four JCK tests that are of interest in this discussion are expr63602m06, expr63602m26, expr63602m62 and expr63602m261. This is a javac bug. The generated instruction in access$001 should be invokespecial ParentClass.testedMethod()I —Dan