JDK-8297271 : AccessFlags should be specific to class file version
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang:reflect
  • Affected Version: 20
  • Priority: P3
  • Status: In Progress
  • Resolution: Unresolved
  • Submitted: 2022-11-18
  • Updated: 2022-12-05
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 20
20Unresolved
Related Reports
CSR :  
JDK-8297741 - AccessFlags should be specific to class file version
Cloners :  
JDK-8296950 - [lworld] AccessFlags should be specific to class file version
Relates :  
JDK-8266670 - Better modeling of access flags in core reflection
Description
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 accessflags that appear in the class file and depending on the class file version.

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

The modifier bit ACC_SYNTHETIC (0x1000) is not defined before class file format version 50.
Comments
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