JDK-8233854 : 4.8: Clarify which checks occur during format checking
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 8
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2019-11-08
  • Updated: 2025-05-30
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 :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
JVMS 4.8 attempts to describe the validation that occurs on class file contents during class loading (under the umbrella of "format checking"), but its list of checks is incomplete.

A better approach is to identify *throughout* Chapter 4 the assertions about the class file format that constitute format checks. My suggested approach is to carefully use the word "must" in Chapter 4 iff a format check is being described.

Based on some testing of Hotspot behavior and desire to keep things simple, some suggested behavioral changes:

- Eliminating checks on CONSTANT_NameAndType structures involving restricted method names (names that include < or >) and name/descriptor coordination (4.4.6). These checks should only occur when the constant is referenced from a context that requires a method.

- Ensuring that a CONSTANT_InvokeDynamic structure never uses method name <init> (4.4.10), rather than delaying the check until an invokedynamic instruction is verified.

- Rejecting class or interface declarations with Module, ModulePackages, or ModuleMainClass attributes (4.7.25, 4.7.26, 4.7.27), and non-static field declarations with ConstantValue attributes (4.7.2).

Comments
Note from Alex: I think the super_class definition can be improved. "For a module or a class named java/lang/Object, the value of the super_class item must be 0." will make people wonder which modules are named java/lang/Object when this_class is always module-info. You could add a comma, but I think it's better to (a) do modules last, and (b) open by continuing the phraseology from the preceding this_class item: If this class file defines a class with the name java/lang/Object, the value of ... 0. If this class file defines a class with any other name, the value ... If this class file defines an interface, the value ... If this class file defines a module, the value ...
15-01-2025

Note on this rule from 4.7.6, proposed to be deleted: "If a class file has a version number that is 51.0 or above, and has an InnerClasses attribute in its attributes table, then for all entries in the classes array of the InnerClasses attribute, the value of the outer_class_info_index item must be zero if the value of the inner_name_index item is zero." Alex believes there's a bug trail that is worth exploring to explain why this text was added. It may be that it's useful/important to actually enforce something here, not just provide guidance on what the attribute "ought to" look like.
08-01-2025

Revised presentational changes are attached, and can be found at https://cr.openjdk.org/~dlsmith/8233854/8233854-20240111/specs/format-checking-jvms.html I'll probably do another round of reviewing/polishing this document before proceeding further.
12-01-2024

HotSpot conformance with the specified rules for NameAndType constants should be addressed by JDK-8322655.
22-12-2023

Created separate issues for the behavioral changes associated with module-related attributes (JDK-8322650) and ConstantValue (JDK-8322651).
21-12-2023

Proposed changes to 4.1-4.8 and 5.3.5 are attached.
08-11-2019