Note that in terms of updating the implementation of toGenericString()
JDK-8322878 to included sealed information, since strictfp is a no-op in
the same release sealed/non-sealed was added, a class file can be
sealed XOR strictfp
Therefore, Class.toGenericString() could print the modifiers from
getModifiers() and then add sealing information while retaining the
blessed modifier order. In other words, the
"Modifier.toString(modifiers)" code in Class.toGenericString() does not
have to be "interrupted" to handle presenting sealed information in the
blessed order.
HTH,
-Joe
On 1/2/2024 4:08 AM, Pavel Rappo wrote:
I assume the order for `sealed` and `non-sealed` has effectively been decided
by JLS: https://docs.oracle.com/javase/specs/jls/se21/html/jls-8.html#jls-8.1.1
8.1.1. Class Modifiers
...
ClassModifier:
(one of)
Annotation public protected private
abstract static final sealed non-sealed strictfp
...
If two or more (distinct) class modifiers appear in a class declaration,
then it is customary, though not required, that they appear in the order
consistent with that shown above in the production for ClassModifier.
Shall I just create a PR?
On 2 Jan 2024, at 11:56, Pavel Rappo <pavel.ra...@oracle.com> wrote:
I couldn't find any prior discussions on this matter.
I noticed that bin/blessed-modifier-order.sh has not been updated for the [recently
introduced](https://openjdk.org/jeps/409) `sealed` and `non-sealed` keywords. I also note
that we already have cases in OpenJDK where those keywords are ordered differently. If we
have a consensus on how to extend the "blessed order" onto those new keywords,
I can create a PR to update the script.
-Pavel
