JDK-8373093 : [lworld] Modifier.toString for Modifier.STRICT
Type:Bug
Component:core-libs
Sub-Component:java.lang:reflect
Affected Version:repo-valhalla
Priority:P4
Status:Open
Resolution:Unresolved
Submitted:2025-12-04
Updated:2025-12-05
The Version table provides details related to the release that this issue/RFE will be addressed.
Unresolved : Release in which this issue/RFE will be addressed. Resolved: Release in which this issue/RFE has been resolved. Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.
When --enable-preview, java.lang.reflect.Modifier.toString() should show "strictfp" only if not --enable-preview.
Comments
The masking of inappropriate modifier bits will address this issue.
This can be closed as a dup when JDK-8373125 is sync'd to Valhalla.
05-12-2025
PS See
https://github.com/openjdk/jdk/pull/28672
for a proposed fix in JDK 27.
05-12-2025
[~rriggs], for Field.toString() in particular, in JDK 27 mainline it looks to be missing "&& Modifier.fieldMods()" which I believe would resolve the proximal issue at hand. (Method and Constructor look to call and retrieve the appropriate bit masks already before passing on int with the modifiers to toString().)
The specs of the core reflection toString() methods date back to early days of the platform and for contemporary standards border on being an anti-pattern of over-specification.
I wouldn't be against either of:
* Rewriting the specification of all the methods to be more like informative prose and less like the textual description of a grammar
* Reimplementing toString on top of access flags rather than modifiers, even if this is somewhat slower.
05-12-2025
The impetus for this was `Field.toString()` that included `strictfp` when it clearly did not.
Some variation of masking of the `getModifier` bits based on the class file version number might be an option.
Modifier.toString itself has only the bits passed to it and knows nothing about where the bits came from.
Compatibility of `toString` methods is potentially an issue, though it would be good if the `toString` implementations for `Method`, `Field`, and `Class` game complete and non-misleading information.
05-12-2025
As noted by [~liach], the AccessFlag API was introduced specifically to better handle recycling of flag positions to mean different things in different class files versions, and, secondly, to better accommodate reuse of flag positions to mean different things on different constructs. (The latter situation led to the introduction of methods like Modifiers.classModifiers() so better screening of modifier bits could be done and not have "volatile" methods reported, etc.)
Old class files with strictfp methods still exist. Especially since STRICT_INIT doesn't have a source-level modifier, I agree the details of this suggested change are not the best approach.
05-12-2025
I don't think this is the right thing to do. Modifer.toString reflects source modifiers. The strict init access flag does not have a corresponding source modifier.
In addition, Modifer.toString() is bound to be incorrect for class modifiers. It reports identity classes as synchronized. I suggest to deprecate Modifier.toString() and offer alternative API to create a string from a set of AccessFlag instead.