RFR: 8297271: AccessFlags should be specific to class file version

[Joe Darcy]

On Tue, 29 Nov 2022 15:33:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Yes, the location information via `AccessFlags.locations(ClassFileFormatVersion)` provides the needed information. And the tests verify that information. My objective was to make the AccessFlags returned for a class reflect the class file format version number of the underlying class. Currently, it is implicitly the current class file format version supported by the VM, not necessarily the version of the class loaded. Suggestions welcome for how that is exposed in the APIs and implemented.

I don't agree the assessment that the API implicitly assumes the class file version used to compute the access flags is the latest one supported by the JVM.

In the context of the accessFlags methods defined in core reflection, the implementation in the Java libraries and the specification implicitly assume the JVM "does the right thing" with respect to access flags per JVMS 4.1. The ClassFile Structure:

"All bits of the access_flags item not assigned in [Table 4.1-B](https://docs.oracle.com/javase/specs/jvms/se19/html/jvms-4.html#jvms-4.1-200-E.1) are reserved for future use. They should be set to zero in generated class files and should be ignored by Java Virtual Machine implementations."

So the desired (and actual observed) behavior is that in effect a class file version specific mask is applied to screen out the access flag bits before they are handed back to the core reflection library code to build the Set<AccessFlag> for a class, method, field, etc.

-------------

PR: https://git.openjdk.org/jdk/pull/11399