RFR: JDK-8266670: Better modeling of access flags in core reflection [v6]
Joe Darcy
joe.darcy at oracle.com
Thu Feb 17 20:41:05 UTC 2022
Okay; I'll work on a location/context enum to model where flags can
appear for the next iteration as the place-holder ElementType enum fro
annotations doesn't quite work for this VM-centric context.
Thanks,
-Joe
On 2/17/2022 10:16 AM, Brian Goetz wrote:
> Yes, and ...
>
> There are words of flags elsewhere scattered through the JDK, such the
> InnerClasses attribute, module flags in the Module attribute, and
> flags on the "requires" entries in the Module attribute. Having one
> abstraction to cover all these locations, even though reflection
> doesn't currently serve up them all, would be a sensible thing.
>
>
>
> On 2/17/2022 11:34 AM, Roger Riggs wrote:
>> On Thu, 17 Feb 2022 01:38:42 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 CSRhttps://bugs.openjdk.java.net/browse/JDK-8281660 will be
>>>> filled in once the API is further along.
>>> Joe Darcy has updated the pull request with a new target base due to
>>> a merge or a rebase. The incremental webrev excludes the unrelated
>>> changes brought in by the merge/rebase. The pull request contains
>>> ten additional commits since the last revision:
>>>
>>> - Update JVMS references.
>>> - Merge branch 'master' into JDK-8266670
>>> - Reorder constants by mask value per review feedback.
>>> - Merge branch 'master' into JDK-8266670
>>> - Respond to more review feedback.
>>> - Respond to review feedback explicitly stating returned sets are
>>> immutable.
>>> - Fix typo from review feedback.
>>> - Merge branch 'master' into JDK-8266670
>>> - JDK-8266670: Better modeling of modifiers in core reflection
>> The jvms also has `access_flags` for parameters.
>> [4.7.24. The MethodParameters
>> Attribute](https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.24)
>>
>> Even if java.lang.reflect.Parameter is not a "Member", it would be
>> useful for Parameter to have an `accessFlags()` method and loosen up
>> the spec for AccessFlag to allow its use in Parameter.
>> Its access flags have the same underlying bit patterns and definitions.
>>
>> -------------
>>
>> PR:https://git.openjdk.java.net/jdk/pull/7445
More information about the core-libs-dev
mailing list