JDK-8258138 : 4.10: Eliminate redundant 'final' checks in verification
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2020-12-12
  • Updated: 2024-01-10
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8243582 - 5.3.5: Perform 'final' error checks during class loading, not verification
Relates :  
JDK-8233861 - 5.3: Clean up class loading specification
Relates :  
JDK-8267650 - Better-defined JVM class file validation
Description
In JDK-8243582, it was recognized that the invariants associated with ACC_FINAL classes and methods are checked at class derivation time, *not* verification time. The appropriate rules were added to 5.3.5.

Meanwhile, 4.10 continues to claim that verification performs these checks. These rules should be removed.

Doing so properly will involve significant changes, as many of the rules defined in 4.10.1 exist solely to identify methods that might override an ACC_FINAL method in a superclass.
Comments
Concrete changes: - 4.10: Delete "In both strategies...", including the following 3 bullets - 4.10.1: Delete "A class is type safe if all its methods are type safe... and bytecode verification has completed successfully.", including the 'classIsTypeSafe' rule. Replace it with: "The Prolog predicate `methodIsTypeSafe` (4.10.1.5) determines whether the `Code` attribute of a particular method of a particular class or interface conforms to the structural constraints described in 4.9.2. The structural constraints are satisfied by the method if and only if the `methodIsTypeSafe` predicate is true." And revise the bullet: "Fourth, we specify how a method is type checked~~, for methods without code~~ (4.10.1.5) ~~and methods with code (4.10.1.6)~~." - 4.10.1.1: Begin the section with this, revising some useful text deleted from 4.10.1: "The Prolog term Class represents a binary class or interface that has been successfully loaded (5.3). This specification does not mandate the precise structure of this term." "Similarly, the Prolog term Method represents a method of a Class, and the Prolog term Loader represents a class loader of a Class. We do not specify the structure of the method or class loader." Delete the following unused Prolog accessors and update the count: 'classIsNotFinal', 'classMethods', 'classAttributes', 'methodAttributes', 'isNotFinal', 'isStatic', 'isNotStatic', 'isPrivate', 'isNotPrivate'. - 4.10.1.5: Delete this section. - 4.10.1.6: Move the first half into 4.10.1.5 (call it "Type Checking Methods"). Delete the 'methodIsTypeSafe' rule and reuse this name for 'methodWithCodeIsTypeSafe'.
10-01-2024