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.
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
|