On Thu, 16 Apr 2026 23:08:22 GMT, Chen Liang <[email protected]> wrote:
>> In project valhalla development, we discovered that `Modifier.toString` >> becomes more problematic than helpful: there's now a mix-and-match of >> modifiers from access flags and other class file sources, for example, >> classes now can have ACC_IDENTITY, which clashes with ACC_SYNCHRONIZED, and >> the correct modifier to reflect, "value", must be deduced by the users >> manually. >> >> With fewer bits available for the access flags, it becomes more apparent >> that future source modifiers will no longer be reflected by >> `Modifier.toString`, and future access flags are more likely to be reflected >> incorrectly. Thus, we should dissuade users from this API in the long run. >> >>> This method tries to describe the source modifiers from an access flags >>> value. Since the introduction of this API, new source modifiers are >>> often represented by `class` file constructs other than access >>> flags, and access flags values in different `class` file >>> structures have different interpretations. As a result, the source >>> modifiers reported by this API may be incomplete or incorrect. >>> >>> The source modifiers of a declaration should be reconstructed manually, >>> by examining its reflective object. In addition, the reflective object >>> methods that provide user-friendly text representations, such as >>> `Class#toGenericString()`, render the source modifiers. >>> >>> The access flags of a declaration, with the correct interpretation, can >>> be obtained from the `accessFlags()` methods on the reflective >>> objects, such as `Class#accessFlags()`. >>> >>> To print an access flags value for debug output, consider using the >>> format ``%04x` instead of this method; this method omits all class >>> file access flags without a corresponding source modifier. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > Chen Liang 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 six additional commits since > the last revision: > > - Missed comment > - Revisions > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/deprecate-modifier-tostring > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/deprecate-modifier-tostring > - Merge branch 'master' of https://github.com/openjdk/jdk into > fix/deprecate-modifier-tostring > - Deprecate Modifier.toString src/java.base/share/classes/java/lang/reflect/Modifier.java line 53: > 51: * Java SE 5.0 introduced many new access and property flags, such as > {@link > 52: * AccessFlag#SYNTHETIC ACC_SYNTHETIC}. Unlike {@code ACC_SUPER}, these > access > 53: * and property flags are reported by the {@code getModifier()} methods. Should this be `getModifiers()`? Suggestion: * and property flags are reported by the {@code getModifiers()} methods. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/30093#discussion_r3106976659
