JDK-8322650 : 4.7.25, 4.7.26, 4.7.27: reject class/interface declarations with module-related attributes
  • Type: Bug
  • Component: specification
  • Sub-Component: vm
  • Affected Version: 21
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-12-21
  • Updated: 2023-12-21
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-8233854 - 4.8: Clarify which checks occur during format checking
Relates :  
JDK-8322651 - 4.7.2: reject ConstantValue attributes on non-static fields
Description
The Module, ModulePackages, and ModuleMainClass attributes are specified to appear at most once "in the attributes table of a ClassFile structure". There is no distinction made between ClassFile structures that define modules and ClassFile structures that define classes/interfaces.

In practice, HotSpot treats a Module, ModulePackages, or ModuleMainClass attribute appearing on a class or interface declaration as a "non-predefined" attribute and ignores its contents.

This means that, e.g., within the Module attribute, a 'requires_index' pointing to a CONSTANT_Class is considered invalid when the attribute is attached to a module, but is ignored when the attribute is attached to a class or interface. HotSpot even allows multiple Module attributes to appear on a class or interface.

This sort of flag-dependent categorization of attributes (as determined by ACC_MODULE and ACC_INTERFACE) is not supported by 4.7, and envisions a finer-grained distinction between predefined and non-predefined attributes than the specification is equipped to handle. Of course, we can make a special-case rule, but the added complexity does not seem justified.

A class or interface declared with one of these attributes is extremely unlikely to appear outside of conformance tests, and if it did, that would indicate a bug that the creator of the class file would benefit from having flagged by class loading.

Proposed change: or class or interface with one of these attributes violates format checking, and should fail to load.
Comments
Note that in a class file prior to 53.0, these attributes would be considered non-predefined in any context, and would be ignored. The new behavior would only apply to version 53+ class files.
21-12-2023
Proposed changes: 4.7.25 There ~~may be at most~~ **must be exactly one** Module attribute in the attributes table of a ClassFile structure **representing a module**. **There must not be a Module attribute in the attributes table of a ClassFile structure representing a class or interface.** 4.7.26 There may be at most one ModulePackages attribute in the attributes table of a ClassFile structure **representing a module**. **There must not be a ModulePackages attribute in the attributes table of a ClassFile structure representing a class or interface.** 4.7.27 There may be at most one ModuleMainClass attribute in the attributes table of a ClassFile structure **representing a module**. **There must not be a ModuleMainClass attribute in the attributes table of a ClassFile structure representing a class or interface.**
21-12-2023
A related change in JDK-8233854 is to include these attributes among those that are "critical to correct interpretation of the class file by the Java Virtual Machine". While ACC_MODULE class files are never loaded by JVMS, these classes and their attributes do affect the interpretation of class files in areas like access checking.
21-12-2023