RFR: 8297271: AccessFlags should be specific to class file version [v2]
Roger Riggs
rriggs at openjdk.org
Mon Dec 5 23:12:25 UTC 2022
On Mon, 5 Dec 2022 21:43:03 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/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).
For arrays, the implementation does use the cffv of the element type and it is a natural extension of the description of Class.accessFlags() using some of the modifiers (public, protected, and private) of the component type (as written a couple of lines above). But it may be a bit of overreach to say that its appropriate for other modifiers of an array to have the same behavior.
-------------
PR: https://git.openjdk.org/jdk/pull/11399
More information about the core-libs-dev
mailing list