On Mon, 5 Dec 2022 21:47:29 GMT, Joe Darcy <da...@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
