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

[Roger Riggs]

On Fri, 27 May 2022 20:21:12 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> With the `AccessFlag` API, what is the role of the `Modifier` API going forward? [Value Objects JEP](https://openjdk.java.net/jeps/8277163) defines the new `identity` and `value` modifiers. [PR #698](https://github.com/openjdk/valhalla/pull/698) proposes to add `Modifier.IDENTITY` and `Modifier.VALUE` constants as the `identity` and `value` modifiers are encoded in a class file using the `ACC_IDENTITY` and `ACC_VALUE` flags. However, with the new improved `AccessFlag` API, the new flags will be defined in the `AccessFlag` API. I think we should avoid adding the new flags in `Modifier` and leave it for the existing usage. Use `AccessFlag` for new features.

Looking over the existing uses of Modifier, as relates to Class.getModifiers(), there are simple uses testing for an individual access flag and others that expect a full set of modifier bits that apply to the class. There are a few places that need all the bits to compose a new set of modifier bits and a few others that test for combinations of bits.
`Class.getModifiers()` is intrinsified, testing against various bit patterns using the static methods of `Modifier` is very performant.

The `Modifer.toString()` method cannot distinguish the flags overloaded by the Class vs Member cases.
Modifier.toString() is used by both Class and Member `toString` methods.
Methods to convert a Set<AccessFlag> to a mask and to produce the 'toString' of the set would be useful.

To replace all uses of Modifier the existing use cases will need some attention.

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

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