RFR: 8297271: AccessFlags should be specific to class file version [v2]

[Joe Darcy]

On Mon, 5 Dec 2022 19:52:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field implicitly uses the access flags from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.
>> 
>> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Updated the descriptions of AccessFlags being dependent on the class file version number.
>    Removed unnecessary tests of ACC_SYNTHETIC, the class file format version
>    tests for strictfp cover them sufficiently.
>  - WIP: simplify

src/java.base/share/classes/java/lang/Class.java line 1345:

> 1343:      * <li> its {@code INTERFACE} flag is absent, even when the
> 1344:      *      component type is an interface
> 1345:      * <li> its class file format version is that of the component class

Please remove this requirement.

First, I'm not sure if it is true of the implementation. Even if it were true today, I don't think it is necessary to guarantee this as the class file format version is not directly retrievable by end-users (nor do I think it should be).

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

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