On Fri, 13 Mar 2026 23:35:40 GMT, Chen Liang <[email protected]> wrote:
>> Currently, the preview access flag enum constants are made available with a
>> ClassFileFormatVersion.CURRENT_PREVIEW_FEATURES constant. Such a constant is
>> questionable design.
>>
>> We can have an approach to model preview access flags without such a
>> constant, losing the ability for users to inspect through
>> `ClassFileFormatVersion`, but otherwise keeping these interfaces intact:
>>
>> 1. `accessFlags()` factory methods in core reflection
>> 2. Inspection of AccessFlag through ClassFile API
>> 3. The outputs of javap
>>
>> The new design makes use of a new internal API,
>> `jdk.internal.reflect.PreviewAccessFlags`. It replaces the AccessFlag APIs
>> that previously took `ClassFileFormatVersion.CURRENT_PREVIEW_FEATURES`. This
>> introduces a new qualified export from `java.base/jdk.internal.reflect` to
>> `jdk.jdeps` for Javap usage.
>>
>> In addition, with the recent awareness that core reflection/HotSpot only has
>> one unique representation of modifiers, we can remove some contrived
>> representation of access flags present in mainline (that required pulling
>> class version from Class mirrors) and migrate to our simplified system that
>> decodes the uniform representation used by hotspot.
>
> Chen Liang has updated the pull request incrementally with two additional
> commits since the last revision:
>
> - Comment update
> - Remove meaingless bouncer in Reflection
src/hotspot/share/oops/instanceKlass.cpp line 3786:
> 3784: if (!Arguments::is_valhalla_enabled()) {
> 3785: // Remember to strip ACC_SUPER bit without Valhalla
> 3786: access &= (~JVM_ACC_SUPER);
Are you stripping `ACC_SUPER` (the name of the value back then) or
`ACC_IDENTITY` (the new name we used when bringing back the value)?
* If old, then maybe this is better done in `classFileParser` where we already
have some logic to deal with `ACC_SUPER` in old classfiles.
* If new, could this be `JVM_ACC_IDENTITY`?
src/hotspot/share/prims/jvmtiEnv.cpp line 2744:
> 2742: result |= JVM_ACC_SUPER;
> 2743: }
> 2744: *modifiers_ptr = result;
I'm not sure I understand the high-level here, why does JVMTI need to provide
`ACC_SUPER` every time? From the JVMS:
> In Java SE 8, the ACC_SUPER semantics became mandatory, regardless of the
> setting of ACC_SUPER or the class file version number, and the flag no longer
> had any effect. Now the flag has been repurposed as ACC_IDENTITY.
Does this not mean that with historically-compiled class files, `ACC_SUPER,`
could be omitted and not be present, and then `GetClassModifiers` would return
a modifier that didn't exist in the original classfile?
-------------
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2209#discussion_r2940675624
PR Review Comment:
https://git.openjdk.org/valhalla/pull/2209#discussion_r2940712320
