On Fri, 27 May 2022 20:21:12 GMT, Mandy Chung <mch...@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
