On Wed, 24 Jun 2026 22:14:52 GMT, Chen Liang <[email protected]> wrote:

>> src/java.base/share/classes/java/lang/reflect/Executable.java line 213:
>> 
>>> 211:     @Override
>>> 212:     public Set<AccessFlag> accessFlags() {
>>> 213:         return AccessFlagSet.ofValidated(AccessFlagSet.METHOD_FLAGS, 
>>> getModifiers());
>> 
>> Before this change, the declaring class' class file version was being taken 
>> into account to decide the returned `AccessFlag`s. That no longer seems to 
>> be the case now and this implementation uses the latest class file version 
>> in this decision making. Is that intentional? Would a call to 
>> 
>>> java.lang.reflect.AccessFlag#maskToAccessFlags(int mask, Location location, 
>>> ClassFileFormatVersion cffv)
>> 
>> be more appropriate here?
>
> Yes. If you look at hotspot's representation of access_flags, you will 
> realize there is one uniform representation - older flags from previous 
> formats gets translated to that uniform representation in ClassFileParser. 
> And that uniform representation is NOT the latest class file version's 
> `maskToAccessFlags`: for example, it currently permits useless `ACC_STRICT` 
> bit for methods to be returned by `getModifiers()` and `accessFlags()`, not 
> allowed by the JVMS. This is similar to how later class file versions don't 
> allow jsr/ret but hotspot supports them anyways.

So for each location and preview on/off, there is one uniform way to parse the 
hotspot representation. Many locations have the same configuration or 
compatible preview on/off configurations for the same location; in case of 
compatible configurations, I use the more general flags set, like I use 
`PreviewAccessFlags.FIELD_PREVIEW_FLAGS` for Fields, because making another 
switch to `AccessFlagSet.FIELD_FLAGS` for preview off accomplishes the same 
behavior. The only place where the preview on configuraiton is incompatible 
with the preview off configuration is Class and inner class access flags, which 
is handled in `Class::accessFlags`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3470642338

Reply via email to