JDK-8233861 : 5.3: Clean up class loading specification
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 8
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • Submitted: 2019-11-08
  • Updated: 2023-12-20
  • Resolved: 2023-12-20
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
There are a few issues with the specification of class loading:

- Checks relating to `final` classes and methods, and an absent superclass, occur in practice at class loading time, not verification time. They should appear in 5.3.5, not 4.10. (There's actually quite a lot of overhead in 4.10 to support these checks. With the change, verification is only concerned with methods with code.)

- The rules preventing circularity in superclasses/superinterfaces are imprecise.

- Class loading behavior when there are multiple threads attempting to load a class is unspecified.

- The behavior when a `loadClass` method does not behave as expected or throws an exception is not fully specified.

- The notion of creating an "array class" does not belong in a discussion about class loading. (The section is about processing `class` files, not accounting for every java.lang.Class instance.)

Comments
Many of these changes, including addressing anomalous 'loadClass' behavior, were adopted with Sealed Classes, JDK-8260516. Concerns about circularity and concurrency have been spun off into their own issue, JDK-8268628. Load-time 'final' checks were specified by JDK-8243582; removing the redundant checks in verification was left to JDK-8258138. The treatment of "array class" loading is covered by JDK-8322507.
20-12-2023

Proposed changes to 4.10, 5.3, and 5.4.3 are attached.
08-11-2019