JDK-8027304 : JVM: inheriting abstract and default should invoke default -- currently IncompatibleClassChangeError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 8
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-10-25
  • Updated: 2014-06-26
  • Resolved: 2013-10-30
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 :  
Relates :  
Description
DefaultMethodsTest.testAmbiguousReabstract fails.

     interface I { int m(); }
     interface J { default int m() { return 88; } }
     class C implements I, J {}
     
     C c = new C(); c.m() should == 88 instead ICCE

Note: this test in DefaultMethodsTest has been updated to match the spec.


Comments
JDK-8027220 has the updated jdk DefaultMethodsTest The vm defmeth tests were updated in our local repository and Christian will push the change to the vmsqe testbase for ConflictingDefaultsTest:testAmbiguousReabstract which had a name change to testMaximallySpecificDefault to reflect the specification change.
30-10-2013

Also requires change to vm defmeth test: ConflictingDefaultsTest:testAmbiguousReabstract: renamed test to testMaximallySpecificDefault since the specification has changed to return the maximally specific default method if there is only one, rather than requiring a single maximally specific method that is a default.
28-10-2013

Have a fix for this change in requested behavior, shaking it out with extensive testing.
28-10-2013