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, seeJDK-8078636. Per the comments, the proposed rule is that preparation should simulate method selection and generate loader constraints iff selection would succeed.
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
- relates to
-
JDK-8078636 5.4.2: The term "inherited" is not defined
-
- Resolved
-