Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9]
On Fri, 18 Feb 2022 14:53:42 GMT, Roger Riggs wrote: > The Location enum does give more control over the places modifiers can occur > and be extended as needed. But its unfortunate there's no (simple/obvious) > mapping to the other concepts of the corresponding types, such as ElementType > or Class/Method/Constructor. I don't have a clear use case for the mapping, > so maybe its just a rough edge that can be smoothed out when AccessFlags gets > used. A near-future iteration of this work will include functionality to map from an integer to a set of access flags. Since there are flags with the same mask position, such as volatile and bridge, some location context is needed to know which mapping 0x_0040 -> BRIDGE 0x_0040 -> VOLATILE is correct and desired in context. The Location enum could include a condensed primer on how Java programs get compiled into class files (constructors are just weird static methods to the VM!), but I didn't think that was necessary for the initial version and the included comment "Just stub-out constant descriptions for now." was meant to imply more detailed discussion would be forthcoming. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9]
On Fri, 18 Feb 2022 03:38:36 GMT, Joe Darcy 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: > > Switch to location enum. The Location enum does give more control over the places modifiers can occur and be extended as needed. But its unfortunate there's no (simple/obvious) mapping to the other concepts of the corresponding types, such as ElementType or Class/Method/Constructor. I don't have a clear use case for the mapping, so maybe its just a rough edge that can be smoothed out when AccessFlags gets used. - PR: https://git.openjdk.java.net/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v9]
> 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: Switch to location enum. - Changes: - all: https://git.openjdk.java.net/jdk/pull/7445/files - new: https://git.openjdk.java.net/jdk/pull/7445/files/131010f3..c3f6b0a4 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk=7445=08 - incr: https://webrevs.openjdk.java.net/?repo=jdk=7445=07-08 Stats: 112 lines in 1 file changed: 78 ins; 0 del; 34 mod Patch: https://git.openjdk.java.net/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.java.net/jdk/pull/7445
