JDK-8186092 : Unnecessary loader constraints produced when there are multiple defaults
  • Type: Bug
  • Component: hotspot
  • Sub-Component: runtime
  • Affected Version: 10
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2017-08-10
  • Updated: 2025-07-01
  • Resolved: 2017-09-28
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 10
10 b31Fixed
Related Reports
Causes :  
Relates :  
Description
In the following scenario, Hotspot produces a loader constraint ("Foo" must be the same for loaders of I and J), even though it's not needed: neither default method can be selected for instances of C, due to the conflict.

interface I { default Foo m() { return null; } }
interface J {default Foo m() { return null; } }
class C implements I, J {}

A test is attached. To reproduce:
- Compile *.java
- Uncomment the method declaration in J.java
- Compile J.java
- java Test

Expected: no error
Actual: loader constraint violation

The specification for these constraints is missing, see JDK-8078636. Per the comments, the proposed rule is that preparation should simulate method selection and generate loader constraints iff selection would succeed.
Comments
URL: http://hg.openjdk.java.net/jdk10/master/rev/bc112140e089 User: jwilhelm Date: 2017-11-04 02:58:06 +0000
04-11-2017

URL: http://hg.openjdk.java.net/jdk10/hs/rev/bc112140e089 User: hseigel Date: 2017-09-28 18:36:39 +0000
28-09-2017

Other tests I performed: one abstract, one default: constraint violation, as expected both abstract: no violation, as expected both default, I and J have same loader (different from C): unexpected constraint violation Test I haven't performed: both abstract, but where one abstract overrides a default in a super: expect no violation abstract in superinterface, abstract in _superclass_: expect violation (the abstract class method is selected, later an AME occurs)
10-08-2017