On Mon, 28 Nov 2022 22:56:27 GMT, Roger Riggs <rri...@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

Reply via email to