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<da...@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
