While we are here, I also note that the script does not explicitly take into
account the `default` modifier on an interface method. However, after reading
https://docs.oracle.com/javase/specs/jls/se21/html/jls-9.html#jls-9.4 it seems
that whenever `default` appears, it should be alone one way or another; thus,
ordering is not an issue.
Indeed, here are the modifier possibilities for an interface method declaration:
public private abstract default static strictfp
And here are the relevant constraints:
- explicit public is discouraged
- abstract, default, and static are mutually exclusive
- strictfp is obsolete
- private and default are mutually exclusive
So if `default` appears, except for uncompilable, discouraged, or obsolete
cases, it should be alone. Thoughts?
> On 2 Jan 2024, at 17:23, Roger Riggs <roger.ri...@oracle.com> wrote:
>
> Hi Pavel,
>
> I agree, the script should refer to the JLS.
> Some people look to the javadoc but its not authoritative on the language.
>
> Roger
>
> On 1/2/24 12:18 PM, Pavel Rappo wrote:
>> 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
>>>>>>>
>>>>>>>
>
