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