Bug ID: JDK-8297271 AccessFlag.maskToAccessFlags should be specific to class file version

Versions (Unresolved/Resolved/Fixed)

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 25
25 b22Fixed

Some access flags apply only to class files with a range of class file versions.
The java.lang.AccessFlag class should return the AccessFlag corresponding to the actual access flags that appear in the class file and depending on the class file version.

The AccessFlag.maskToAccessFlags(mask, location) maps the mask to the set of AccessFlags based on the current classfile version number.

For class files with older class file format version numbers the mapping should include the version number specifi. 

For example, the access flag SYNTHETIC was introduced in class file format version 50 and its locations were updated in version 51.

The modifier bit ACC_SYNTHETIC (0x1000) is not defined before class file format version 50.

Changeset: bee273d6 Branch: master Author: Chen Liang <liach@openjdk.org> Date: 2025-05-01 14:37:26 +0000 URL: https://git.openjdk.org/jdk/commit/bee273d6b4e34692952d4e7474ab72ee5c54e33a
01-05-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/24760 Date: 2025-04-18 20:33:27 +0000
30-04-2025
I think we should aim to make this available before Valhalla. This is useful for the ClassFile API - we wish to throw an exception if we detect an ACC_STRICT in post-JDK 17 method access flags. The addition of CFFV-aware version also promotes the use of the CFFV version over the other one (which presumably detects the flags for the latest version). P.S. the other version currently is accepting ACC_STRICT, despite it already is obsolete.
06-12-2024
From a specification perspective, I think it is sufficient for JDK 20 to note that the modifer -> access flag mapping may be dependent on class file version. A class file format version dependent version of maskToAccessFlags is reasonable too.
02-12-2022
In terms of the fundamental information, the bits used for both modifiers and access flags come from HotSpot. This information comes from the access_flags() method on a HotSpot Klass. See for example, ./hotspot/share/oops/instanceKlass.cpp The results of access_flags().as_int() are then processed to varying degrees to implement compute_modifier_flags() (which strips out ACC_SUPER) and the HotSpot-core-libs access point JVM_GetClassAccessFlags, which does not strip out ACC_SUPER. If the core observation of this bug is "SYNTHETIC can be seen on some class files where it isn't defined," then I think that could be addressed in HotSpot by zeroing out that bit position in a class file version dependent manner.
02-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/11399 Date: 2022-11-28 22:56:27 +0000
28-11-2022
Note some of this information is implicitly exposed via the AccessFlag.locations(ClassFileFormatVersion cffv) method.
28-11-2022

Blocks :	JDK-8355956 - Prepare javap for class file format aware access flag parsing
Blocks :	JDK-8337220 - AccessFlags validation should respect ClassFile version
CSR :	JDK-8297741 - AccessFlag.maskToAccessFlags should be specific to class file version
Causes :	JDK-8358078 - javap crashes with NPE on preview class file
Cloners :	JDK-8296950 - [lworld] AccessFlags should be specific to class file version
Relates :	JDK-8266670 - Better modeling of access flags in core reflection
Relates :	JDK-8298300 - Filtering AccessFlags by class file format version (i.e. ACC_SYNTHETIC)
Relates :	JDK-8347471 - Provide valid flags and mask in AccessFlag.Location