Blessed modifier order does not include sealed/non-sealed
Remi Forax
forax at univ-mlv.fr
Tue Jan 2 18:29:43 UTC 2024
----- Original Message -----
> From: "Pavel Rappo" <pavel.rappo at oracle.com>
> To: "Roger Riggs" <roger.riggs at oracle.com>
> Cc: "core-libs-dev" <core-libs-dev at openjdk.org>
> Sent: Tuesday, January 2, 2024 5:31:06 PM
> Subject: Re: Blessed modifier order does not include sealed/non-sealed
> Hi Roger,
>
> Happy New Year to you too!
>
> Although it's a _somewhat_ separate issue, I found that the shell script refers
> to java.lang.reflect.Modifier#toString which does NOT mention either `sealed`
> or `non-sealed`. More precisely, the script refers to the JDK 8 version of that
> method, but [the
> method](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/Modifier.html#toString(int))
> hasn't changed since 2009 and states that:
>
> ...The modifier names are returned in an order consistent with the suggested
> modifier orderings given in sections 8.1.1, 8.3.1, 8.4.3, 8.8.3, and 9.1.1 of
> The Java Language Specification. The full modifier ordering used by this method
> is:
>
> public protected private abstract static final transient volatile synchronized
> native strictfp interface
>
> It does not seem like `sealed` and `non-sealed` are even modelled by
> java.lang.reflect.Modifier, although `sealed` is modelled by
> `java.lang.Class#isSealed`. It cannot be overlook, can it?
There was always an ambiguity with the package java.lang.reflect, because it reflects the classfile (the .class) and not the source file (the .java).
So j.l.r.Modifier and j.l.r.AccessFlag reflects the modifiers of the classfile, see [1].
The keyword sealed and non-sealed are modifiers in the source file but not in the classfile. Sealed is represented as the attribute PermittedSubclasses and non-sealed is just no modifier (you have to op-out when a hierarchy is sealed in the source file while for the classfile it's opt-in). That's why both sealed and non-sealed are not defined in Modifier.
regards,
Rémi
[1] https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/reflect/AccessFlag.html
>
>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.riggs at oracle.com> wrote:
>>
>> Hi Pavel,
>>
>> yes, a PR would be next.
>>
>> Happy New Year, Roger
>>
>> On 1/2/24 7: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.rappo at 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
>>>>
More information about the core-libs-dev
mailing list