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

Joe Darcy darcy at openjdk.org
Tue Dec 6 02:25:01 UTC 2022


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

>> 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.

For the purposes at hand of specifying the access flags as dependent on the class file format version, if the access flags are already completely specified, there is no need to mention a possible dependence on the class file format version, especially give the spec from a few lines down:

* For {@code Class} objects representing void, primitive types, and 
* arrays, access flags are absent other than as specified above.

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

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


More information about the core-libs-dev mailing list