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

[Roger Riggs]

On Mon, 5 Dec 2022 21:47:29 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> 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/reflect/AccessFlag.java line 519:
> 
>> 517:      * @param cffv the class file format version
>> 518:      */
>> 519:     public static Set<AccessFlag> maskToAccessFlags(int mask, Location location,
> 
> The difference in exception handling behavior compared to the method w/o a ClassFileFormatVersion argument should at least be discussed.

I would propose to say:
     
    Mask bits that do not match an {@code AccessFlag} for the location and 
    class file format version are ignored.

The case arises when the mask argument contains mask bits that are not consistent with the locations defined for any AccessFlag.
The current method throws IllegalArgumentException, while the added method returns a set of AccessFlags appropriate to the location and cffv and ignores the undefined mask bits.

If the source of the error/inconsistency is an application developer calling `maskToAccessFlags()` then IAE makes sense.
However, it would puzzling if a call to Class.accessFlags() threw IllegalArgumentException; in that case the mask bits are those of a loaded class, presumed to be conforming to the spec, but none the less having unexpected mask bits.
Such an recurrence is likely very rare but might be the result of a class file created by some means other than the javac compiler. The declaration of each AccessFlag implements the location and cffv information and corresponding mask bits according the JVM spec. If the VM loads the class, then the question is whether the inconsistency should be reported and if so how.

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

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