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

[Joe Darcy]

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