On Thu, 5 Mar 2026 17:54:14 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.
src/java.base/share/classes/java/lang/reflect/Modifier.java line 40:
> 38: *
> 39: * @apiNote
> 40: * {@code Modifier} was designed with two assumptions:
I think the apiNote will need a few iterations on the wording. I don't like it
starting with the assumptions and then saying that the assumptions aren't
valid. Instead I think it would be better to say that the translation of source
modifiers to access flags has evolved since the API was originally introduced.
In addition, the bit may represent different flags. The API can still be used
for source modifiers that directly map to an access flag. New code is
encouraged to use AccessFlags.
src/java.base/share/classes/java/lang/reflect/Modifier.java line 261:
> 259: *
> 260: * @deprecated
> 261: * This method tries to describe the source modifiers from an access
> flags
I agree that the methods should be deprecated but I think the `@deprecated`
text will need a few iterations. I think it would be better to start with
something like "This method was originally specified to describe the source
modifiers ..." rathe rthan "This tries ...".
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/30093#discussion_r2942319495
PR Review Comment: https://git.openjdk.org/jdk/pull/30093#discussion_r2942254650
