RFR: JDK-8266670: Better modeling of access flags in core reflection [v28]

[Joe Darcy]

On Thu, 16 Jun 2022 06:27:59 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> This is an early review of changes to better model JVM access flags, that is "modifiers" like public, protected, etc. but explicitly at a VM level.
>> 
>> Language level modifiers and JVM level access flags are closely related, but distinct. There are concepts that overlap in the two domains (public, private, etc.), others that only have a language-level modifier (sealed), and still others that only have an access flag (synthetic).
>> 
>> The existing java.lang.reflect.Modifier class is inadequate to model these subtleties. For example, the bit positions used by access flags on different kinds of elements overlap (such as "volatile" for fields and "bridge" for methods. Just having a raw integer does not provide sufficient context to decode the corresponding language-level string. Methods like Modifier.methodModifiers() were introduced to cope with this situation.
>> 
>> With additional modifiers and flags on the horizon with projects like Valhalla, addressing the existent modeling deficiency now ahead of time is reasonable before further strain is introduced.
>> 
>> This PR in its current form is meant to give the overall shape of the API. It is missing implementations to map from, say, method modifiers to access flags, taking into account overlaps in bit positions.
>> 
>> The CSR https://bugs.openjdk.java.net/browse/JDK-8281660 will be filled in once the API is further along.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Appease jcheck.

A note on the regression tests, I'm expanding the set of tests for the different access flags in different locations. I've partitioned these separately for class, field, method flags, etc. Those sorts of locations could potentially be combined into a single test, but I think it is clearer to have them separate (and in a bulk regression test run, they shouldn't take much longer to run as separate tests). To test ACC_STRICT, earlier source and target settings need to be used so that test is separate.

In the course of writing tests for ACC_SUPER, it looks like Class.getModifiers() strips out the ACC_SUPER bit in the VM implementation ([JDK-4109635](https://bugs.openjdk.org/browse/JDK-4109635)). I'm sure those who have knives sharpened to remove SUPER will be encouraged by this, but I'd still prefer to leave SUPER as an AccessFlag for now.

As a follow-up to this work, it may be necessary or helpful to have a different library access point or an additional library access point to query information from the JVM. Alternatively, the VM could take responsibility for constructing the AccessFlag sets. For example, if (and when) there is reuse of a bit position for a single construct, say on a class file, the interpretation of the bit is dependent on class file version. While the VM knows that the class file version is, the libraries don't currently have access to that information and knowing that versioning information in some capacity would be needed to properly construct the access flags.

I'm going to take a pass at writing tests for ModuleDescriptor before considering pushes these changes.

Thanks for all the review feedback so far.

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

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