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