Right, the language model (javax.lang.model) is a better target to refer to
when considering _source_ files. However, java.lang.reflect.Modifier
corresponds to a set returned by javax.lang.model.element.Element#getModifiers,
not to a single instance of javax.lang.model.element.Modifier; the order of
that set is unspecified.
So perhaps the right thing would be to directly refer to JLS from the script.
What do you think?
> On 2 Jan 2024, at 16:56, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> Hi Pavel,
>
> It better to look to javax.lang.model.element.Modifier for the language view
> of the class.
>
> java.lang.reflect.Modifier covers the modifier flags as represented in the
> class file and defined in the JVMS.
> * The values for the constants
> * representing the modifiers are taken from the tables in sections
> * {@jvms 4.1}, {@jvms 4.4}, {@jvms 4.5}, and {@jvms 4.7} of
> * <cite>The Java Virtual Machine Specification</cite>.
> Sealing is represented in the class file as a non-empty list of permitted
> classes. Hence the method of java.lang.Class.
>
> Since java.lang.Modifier.toString is based on the flag bits from the class
> file, "sealed" would not appear in any string it generates.
>
>
> It might be possible to inject a comment in the toString method similar to
> the comment about interface not being a true modifier and including a
> reference to the javax.lang.model.element.Modifier enum.
>
> Roger
>
>
> On 1/2/24 11:31 AM, Pavel Rappo wrote:
>> 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?
>>
>>
>>> On 2 Jan 2024, at 14:38, Roger Riggs <roger.ri...@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.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
>>>>>
>>>>>
>>>
>>
>
