JDK-8078636 : 5.4.2: The term "inherited" is not defined
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 8
  • Priority: P5
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2015-04-24
  • Updated: 2018-01-17
  • Resolved: 2018-01-17
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 11
11Fixed
Related Reports
Relates :  
JDK-8186092 - Unnecessary loader constraints produced when there are multiple defaults
Relates :  
JDK-8177020 - Nestmates JVMS changes
Description
JVMS rarely talks about inheritance, which is a Java language concept.  In a search of the document, all usages appear to be non-normative, with the exception of 5.4.2:

"If C implements a method m declared in a superinterface <I, L3> of C, but C does not itself declare the method m, then let <D, L2> be the superclass of C that declares the implementation of method m inherited by C."

This should be phrased by referencing invokeinterface method selection, or defined directly in terms of names, signatures, and superclasses, rather than talking about inheritance.  (For example, can the "inherited" method be private?  JLS says no, but selection would allow it.)
Comments
Fixed with JDK-8177020.
17-01-2018
Proposed rule: for a class C being prepared, for each superinterface method I.m, if selection from C would produce a method B.m, then generate constraints for B.m and I.m. If no method would be produced (e.g., maximally-specific superinterface method set contains 0 or 2 defaults), there are no constraints.
10-08-2017
Further, the rule does not account for the possibility that the "inherited" method may come from an interface. class C implements I, J {} // should require Foo to match in loaders of I and J interface I { void m(Foo arg); } interface J { default void m(Foo arg) {} } ((I) new C()).m(null); Fortunately, Hotspot seems to generate a loader constraint here.
10-08-2017