RFR: 8297271: AccessFlags should be specific to class file version

Joe Darcy darcy at openjdk.org
Tue Nov 29 02:42:21 UTC 2022


On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The accessFlags() methods added (in JDK 20, the current release) to java.lang.Class, java.lang.reflect.Executable, and java.lang.reflect.Field assume the access flags are from the current/most recent class file format version. For current and past class file format versions there are few significant variations but future changes are anticipated that change the meaning of some access flag mask bits.

Hmm. I don't agree with that characterization of the current situation. The AccessFlag class has a method that takes a ClassFileFormatVersion argument and there are regression tests of the AccessFlag feature that user downrev versions of class file to exercise all the functionality:

https://github.com/openjdk/jdk/blob/master/test/jdk/java/lang/reflect/AccessFlag/StrictAccessFlagTest.java

It is more accurate to say that the class file version is an *implicit* argument to all the give-me-the-access-flags functionality.
 
> The accessFlags() methods are clarified to return the access flags that are applicable to the class file format version of the class. The existing AccessFlag.Locations API already contains information about the locations that are applicable to a class file format version. That information should be used to construct the set of AccessFlags returned. A method is added to AccessFlag that returns the applicable flags for a particular mask, Location, and class file format version:

The current implementation does rely on the JVM "doing the right thing"(TM) in terms of screening out access_flags bits that are not appropriate for the class file version. However, I don't think this needs to be underlined, necessarily. Perhaps a sealed interface, strawman name AccessFlags, stated such a requirement for the core reflection classes?

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

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



More information about the security-dev mailing list