On Wed, 24 Jun 2026 16:42:55 GMT, Jaikiran Pai <[email protected]> wrote:
>> David Simms has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 2847 commits: >> >> - Merge branch '8317277' into jep401_sub_review_8317279 >> - Merge remote-tracking branch 'valhalla/lworld' into 8317277 >> - 8387024: [lworld] Remove the mention of mutexes from the specification >> text of value classes >> >> Reviewed-by: alanb, dholmes, liach >> - 8387054: [lworld] BACKOUT JDK-8375694 C2: Dead loop constructed with >> CastPP in late inlining >> >> Reviewed-by: dholmes >> - 8386904: [lworld] ProblemList tests that fail due to JDK-8375645 on all >> platforms >> 8387050: [lworld] ProblemList two >> compiler/valhalla/inlinetypes/TestValueClasses.java sub-tests in Xcomp mode >> >> Reviewed-by: dholmes >> - 8386638: [lworld] Port JEP 401 to PPC64 >> >> Co-authored-by: Richard Reingruber <[email protected]> >> Reviewed-by: dbriemann, rrich, lfoltan >> - Merge >> >> Merge jdk-28+3 >> - 8386815: [lworld] Reduce the number of constructors in IdentityException >> >> Reviewed-by: liach, alanb >> - 8386626: [lworld] Only enable valhalla IR tests in >> ScalarReplacementWithGCBarrierTests.java for aarch64 and x86 >> >> Reviewed-by: mhaessig, mchevalier >> - 8386718: [lworld] C2: Integer overflow in arraycopy scaling for flat >> arrays >> >> Reviewed-by: qamai >> - ... and 2837 more: https://git.openjdk.org/jdk/compare/915efc50...af3e8048 > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31123#discussion_r3470631298
