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
