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

Roger Riggs rriggs at openjdk.java.net
Mon Feb 14 15:51:08 UTC 2022


On Fri, 11 Feb 2022 18:31:57 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.

Looks promising, some comments:

The terminology in the JVMS is about modifiers; can the class name include the word Modifier, perhaps ModifierFlag(s)?
Several of the modifiers are not related to "access".

The `getXXXFlags()` methods in Class, etc. should mention the Set is immutable/unmodifiable.
The post-Beans API signature would be just "flags()" without the Get prefix.  Consistency with the current methods may tend to keep the prefix.

The Set manipulation functions are not very smooth (but true for all Sets).
Checking for `anyOf` or `allOf` a set of modifiers has to be written out as a boolean expression.
Though `allOf` could create an intermediate set.

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

PR: https://git.openjdk.java.net/jdk/pull/7445


More information about the core-libs-dev mailing list