JDK-8027229 : IncompatibleClassChangeError expected for 2 or more maximally-specific matching methods
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-10-24
  • Updated: 2014-06-26
  • Resolved: 2013-11-13
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 Other Other
8Fixed hs25Fixed hs25,port-stage-ppc-aixFixed
Related Reports
Blocks :  
JDK-8026742 - DefaultMethodsTest.java fails expecting AbstractMethodError
Duplicate :  
JDK-8028340 - Maven crashes with assert(is_miranda(m, ik()->methods(), ik()->default_methods(), ik()->super())) failed: should be a miranda_method
Description
Given the following (indirectly compiled in such a way to avoid errors):

interface K { int m() default { return 99; } }
interface L { int m() default { return 101; } }
interface J extends K, L {}
interface I extends J, K { int m() default { J.super.m(); } }
class C implements I {}

C c = new C(); c.m(); // expected: ICCE; actual no error

An IncompatibleClassChangeError is expected but none is thrown. c.m() links to K.m().
Comments
The test was extracted from two places - so use these to verify the fix: 1. tools/javac/lambdaShapes/org/openjdk/tests/vm/DefaultMethodsTest.java and 2. nsk testbase defMethTest: SuperCallTest: testSuperConflict Also cleaned up 8027304 fix.
13-11-2013
I have a fix for this test case. I need to shake it out with thorough testing.
24-10-2013
Attached "testSuperConflict_ICCE_or_AME_or_none.zip" is a stand alone test case that fails to produce an IncompatibleChangeError. The invocation of the default method wires up to K.m(), which is the first interface J extends from: interface J extends K,L { } [6403] static jint IV_C.m() [6403] 1220669 3 0x0000000169387428 0x0000000104273f10 dup [6403] 1220670 4 0x0000000169387428 0x0000000104273f10 invokespecial 3 <C.<init>()V> [6403] virtual void C.<init>() [6403] 1220671 0 0x00000001047727a0 0x0000000000000008 aload_0 [6403] 1220672 1 0x0000000169387428 0x00000000000000db invokespecial 1 <java/lang/Object.<init>()V> [6403] 1220673 4 0x0000000169387428 0x0000000000000000 return [6403] static jint IV_C.m() [6403] 1220674 7 0x0000000030000021 0x0000000000000004 invokevirtual 4 <C.m()I> [6403] virtual jint I.m() [6403] 1220675 0 0x00000001047727a8 0x0000000000000008 aload_0 [6403] 1220676 1 0x0000000169387428 0x00000000000000db invokespecial 1 <J.m()I> [6403] virtual jint K.m() [6403] 1220677 0 0x0000000104772750 0x0000000000000008 bipush 99 [6403] 1220678 2 0x0000000000000063 0x0000000000000008 ireturn [6403] virtual jint I.m() [6403] 1220679 4 0x0000000000000063 0x0000000000000000 ireturn [6403] static jint IV_C.m() [6403] 1220680 10 0x0000000000000063 0x0000000000000008 ireturn [6403] static void IV_C.main(jobject) [6403] 1220681 6 0x0000000000000063 0x0000000000000010 invokevirtual 7 <java/io/PrintStream.println(I)V> Change the order to "extends L, K" and invocation wires up to L.m(). According to the specification: http://cr.openjdk.java.net/~dlsmith/jsr335-0.6.3.html#JJVMS-6.5.invokespecial "Otherwise, if more than one of the maximally-specific matching methods is not abstract, an IncompatibleClassChangeError is raised."
24-10-2013