Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]
On Tue, 14 Jun 2022 01:40:53 GMT, liach wrote:
>> Joe Darcy has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Make mask fields final in ModuleDescriptor.
>
> src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
>
>> 298: /**
>> 299: * {@return a set of access flags for the given mask value
>> 300: * appropriate for the location in question}
>
> Should we specify that the returned set is unmodifiable/immutable?
Sure; that would be consistent with other parts of the PR.
-
PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]
On Tue, 14 Jun 2022 01:25:02 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:
>
> Make mask fields final in ModuleDescriptor.
src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 127:
> 125: * 0x0020}.
> 126: */
> 127: SUPER(0x_0020, false, Set.of(Location.CLASS)),
Should we document that this flag won't appear in `Class#accessFlags` no matter
if it's declared in the class file?
src/java.base/share/classes/java/lang/reflect/AccessFlag.java line 300:
> 298: /**
> 299: * {@return a set of access flags for the given mask value
> 300: * appropriate for the location in question}
Should we specify that the returned set is unmodifiable/immutable?
-
PR: https://git.openjdk.org/jdk/pull/7445
Re: RFR: JDK-8266670: Better modeling of access flags in core reflection [v24]
> 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: Make mask fields final in ModuleDescriptor. - Changes: - all: https://git.openjdk.org/jdk/pull/7445/files - new: https://git.openjdk.org/jdk/pull/7445/files/fd682ac8..75ac9c18 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=23 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7445&range=22-23 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/7445.diff Fetch: git fetch https://git.openjdk.org/jdk pull/7445/head:pull/7445 PR: https://git.openjdk.org/jdk/pull/7445
