On Wed, 3 Jan 2024 16:40:32 GMT, Pavel Rappo <pra...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/Class.java line 264:
>>
>>> 262: /**
>>> 263: * Returns a string describing this {@code Class}, including
>>> 264: * information about modifiers, {@linkplain #isSealed() sealing},
>>> and type parameters.
>>
>> If Class.toGenericString is a useful API point for describing the blessed
>> order of modifiers in the JDK
>> perhaps the existing classes that describe modifiers could/should cross
>> reference this method.
>
> Given potential lossiness of source modifiers presentation by
> java.lang.reflect, I don't think this method is a good host for describing
> the canonical modifier order. Mentioning? Probably. Describing? No.
>
> Separately, but also related: while it does not seem impossible, this PR does
> not implement `non-sealed`.
I think the best place, or least-bad place, to discuss the "modifier" ordering
of sealed/non-sealed would be an informative note on Modifier.toString(int) --
"The sealed/non-sealed Java language modifiers are not represented in the class
file as access flags and thus not modeled by this class
[java.lang.reflect.Modifier] .... sealed/non-sealed should be presented in the
same location as final."
Since it doesn't seem possible to do so, I did not attempt to relay
"non-sealed" information in this PR :-)
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/17239#discussion_r1440765048
