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 >>>>>>> >>>>>>> >