RFR: JDK-8266670: Better modeling of access flags in core reflection [v25]

[Joe Darcy]

On Tue, 14 Jun 2022 14:17:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 213:
> 
>> 211:      * <code>{@value "0x%04x" Modifier#STRICT}</code>.
>> 212:      */
>> 213:     STRICT(Modifier.STRICT, true, Set.of(Location.METHOD)),
> 
> ACC_STRICT is defined for class files and appears in the Class.getModifiers() before class file version 46. 
> Also it is included in Modifer.classModifiers();  Modifer.CLASS_MODIFIERS.
> it might be worth a note saying it is class file version specific.

The ACC_STRICT bit is defined for class file major versions 46 through 60:
https://docs.oracle.com/javase/specs/jvms/se18/html/jvms-4.html
It is the first access flag to be retired in this way.

A number of the access flags (ENUM, ANNOTATION, VARARGS, BRIDGE) are only defined for JDK 5.0 and later, class file major version 49 and above. A similar situations hold for other flags introduced to support modularity only being defined for class file major versions 53 and above.

For JDK 20, the native class file major version is 64.

It would be possible to add some kind of ClassFileVersion enum or other API mechanisms to support a query like "what major versions are this access flag defined?" However, I don't think it is necessary to include such information in the core reflection API at this time and interested parties can lookup the information in the JVMS editions. (I think ClassFileVersion enum would be more appropriate for a byte code manipulation library.)

I'll work on at least adding an explanatory paragraph with a disclaimer that the defined access flags are class file version specific and this class is intended to capture class file versions over time.

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

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