JDK-8087356 : 5.5: Do not guard superinterface initialization on state of superclass
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Priority: P4
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2015-06-12
  • Updated: 2018-08-03
  • Resolved: 2016-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 9
9Fixed
Related Reports
Relates :  
JDK-8043190 - 5.5: Trigger interface initialization on default method invocation
Relates :  
JDK-8043188 - 12.4.1: Trigger interface initialization on default/static method invocation
Description
Step 7 of the initialization process in 5.5 states (emphasis mine):

"Next, if C is a class rather than an interface, *and its superclass has not yet been initialized*, then let SC be its superclass and let SI1, ..., SIn be all superinterfaces of C (whether direct or indirect) that declare at least one non-abstract, non-static method."

In the case in which the superclass has been initialized but a superinterface has not, this is incorrect.  The superinterface should be initialized anyway.
Comments
Yes, the factoring of already-initialized checks in step 7 is wrong. It should read "7. Next, if C is a class rather than an interface, then let SC be its superclass and let ...", and the loop over supertypes should do the already-initialized check for each superinterface. JLS 12.4.2 has exactly the same issue.
12-06-2015
Simple fix is to simply delete the clause: "Next, if C is a class rather than an interface, then let SC be its superclass and let SI1, ..., SIn be all superinterfaces of C (whether direct or indirect) that declare at least one non-abstract, non-static method." The phrase is redundant: when we recur on a superclass or superinterface, we will immediately stop when we discover it is already initialized (Step 4). Further, the spec even explicitly notes that this can be optimized to avoid any locking: "A Java Virtual Machine implementation may optimize this procedure by eliding the lock acquisition in step 1 (and release in step 4/5) when it can determine that the initialization of the class has already completed". However, if we want to keep the phrase anyway, the right place to put it is inside the loop over supertypes: "For each S in the list [ SC, SI1, ..., SIn ], ***if S has not yet been initialized,*** recursively perform this entire procedure for S. If necessary, verify and prepare S first."
12-06-2015