From codercooler at gmail.com  Mon Dec  6 04:38:25 2021
From: codercooler at gmail.com (Li Hao Su)
Date: Mon, 6 Dec 2021 12:38:25 +0800
Subject: JVM Specification Error
Message-ID: <CAMwufoV6P9xovfZkfnKZWF6-UyQ9PKF7+goeOdjp7D3PBXSL-Q@mail.gmail.com>

According to the Module Attribute
<https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.25>
:
>
> opens_to_count
> ......
> If opens_to_count is nonzero, then this package is opened by the current
> module in a *qualified* fashion; only code in the modules listed in the exports_to_index
> table may reflectively access the types and members in the package.


I think it should be the opens_to_index table, not the exports_to_index
table.

From alex.buckley at oracle.com  Mon Dec 20 20:01:58 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:01:58 -0800
Subject: An errata about the production rule w.r.t. "CaseConstant" in JLS
 14.11.1 Switch Blocks (Java SE 14 & 15)
In-Reply-To: <CAP+RqFrjC5nOEJWURsC8tPV4HEaLrqN+ZZOchL_C+qe2f71sKg@mail.gmail.com>
References: <CAP+RqFrjC5nOEJWURsC8tPV4HEaLrqN+ZZOchL_C+qe2f71sKg@mail.gmail.com>
Message-ID: <b917636f-8a5b-134c-5390-d288550d960c@oracle.com>

It's not uncommon for the grammar to accept a relatively wide range of 
inputs which are then constrained by semantic rules ("... a compile-time 
error occurs"). Using ConditionalExpression also avoids introducing a 
little-used EnumConstantName production.

Alex

On 10/21/2020 3:04 PM, Brian Jeong wrote:
> The production rule w.r.t. the non-terminal symbol "CaseConstant" in JLS
> 14.11.1 Switch Blocks  (Java SE 14
> <https://docs.oracle.com/javase/specs/jls/se14/html/jls-14.html#jls-14.11.1>
> & 15
> <https://docs.oracle.com/javase/specs/jls/se15/html/jls-14.html#jls-14.11.1>)
> is given as:
> 
> 
> *CaseConstant:ConditionalExpression*
> 
> However, this doesn't seem to meet the sentence:
> 
> *Every case constant must be either a constant expression (?15.29) or the
> name of an enum constant (?8.9.1), or a compile-time error occurs*.
> 
> It looks like a minor erratum, which can be corrected as:
> 
> *CaseConstant:ConstantExpression EnumConstantName  EnumConstantName:Identifier*
> 
> Please review this.
> Thanks,
> 
> - Brian

From alex.buckley at oracle.com  Mon Dec 20 20:07:14 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:07:14 -0800
Subject: JVM Specification Error
In-Reply-To: <CAMwufoV6P9xovfZkfnKZWF6-UyQ9PKF7+goeOdjp7D3PBXSL-Q@mail.gmail.com>
References: <CAMwufoV6P9xovfZkfnKZWF6-UyQ9PKF7+goeOdjp7D3PBXSL-Q@mail.gmail.com>
Message-ID: <ea2541a3-ca72-982b-9161-d8937a18d2e5@oracle.com>

Yes, thank you. Actioned as https://bugs.openjdk.java.net/browse/JDK-8279019

On 12/5/2021 8:38 PM, Li Hao Su wrote:
> According to the Module Attribute
> <https://docs.oracle.com/javase/specs/jvms/se17/html/jvms-4.html#jvms-4.7.25>
> :
>>
>> opens_to_count
>> ......
>> If opens_to_count is nonzero, then this package is opened by the current
>> module in a *qualified* fashion; only code in the modules listed in the exports_to_index
>> table may reflectively access the types and members in the package.
> 
> 
> I think it should be the opens_to_index table, not the exports_to_index
> table.

From alex.buckley at oracle.com  Mon Dec 20 20:30:08 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:30:08 -0800
Subject: JVMS conflicting rules on interface methods
In-Reply-To: <xpaHo2dCqepqVqCQUCwHeqO_rkkjy8jQlZ0KgrVsbdC-YFpNbMhmLr8VRG6XCst9vFLFqbvRf9plguQxk2eMDWCrK5mA1oRZ0kMZlDYZ7p0=@protonmail.com>
References: <xpaHo2dCqepqVqCQUCwHeqO_rkkjy8jQlZ0KgrVsbdC-YFpNbMhmLr8VRG6XCst9vFLFqbvRf9plguQxk2eMDWCrK5mA1oRZ0kMZlDYZ7p0=@protonmail.com>
Message-ID: <cc1a4c6f-261b-b7ca-9bff-e9e76150511e@oracle.com>

Yes, thank you. Actioned as https://bugs.openjdk.java.net/browse/JDK-8279039

On 3/12/2021 4:33 AM, x4e_x4e wrote:
> Hello,
> 
> JVMS 4.2.2 states:
> 
>> Note that a field name or interface method name may be `<init>` or `<clinit>`, but no method invocation instruction may reference `<clinit>` and only the invokespecial instruction (?invokespecial) may reference `<init>`.
> 
> (Interface's may have an <init> method). This seems in contradiction with 2.9.1 which states:
> 
>> In a class, any non-`void` method named `<init>` is not an instance initialization method. In an interface, any method named `<init>` is not an instance initialization method. Such methods cannot be invoked by any Java Virtual Machine instruction (?4.4.2, ?4.9.2) and are rejected by format checking (?4.6, ?4.8).
> 
> (<init> methods in interfaces are rejected by format checking).
> 
> I think it should be clarified whether an <init> method is allowed in an interface classfile.
> Since Java 9 the verifier rejects an <init> method in an interface, so it seems like 2.9.1 is the intended behaviour.
> 
> Related links:
> https://bugs.openjdk.java.net/browse/JDK-8122940
> https://bugs.openjdk.java.net/browse/JDK-8135265
> 
> Thanks,
> x4e

From alex.buckley at oracle.com  Mon Dec 20 20:36:00 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:36:00 -0800
Subject: Question regarding JavaLetter and JavaLetterOrDigit in the JLS
In-Reply-To: <afbd1dd0-922b-0635-5450-f2f5c99de9da@gmail.com>
References: <afbd1dd0-922b-0635-5450-f2f5c99de9da@gmail.com>
Message-ID: <596744e5-744f-d03e-1b47-7e1baf00dd10@oracle.com>

The isJavaIdentifier* methods are already specified in terms of code 
points and general categories. Having the JLS defer to those methods 
simplifies long-term maintenance of the JLS with no loss of information.

Alex

On 5/1/2021 5:16 AM, Ken Domino wrote:
> Folks,
> 
> I have been updating the Antlr grammars for Java in 
> https://github.com/antlr/grammars-v4/tree/master/java. In one of the 
> grammars, semantic predicates are used to evaluate 
> ?Character.isJavaIdentifierStart(int)? and 
> ?Character.isJavaIdentifierPart(int)? for the input, as per Section 3.8 
> of the Java Language Spec:
> 
> ?A "Java letter" is a character for which the method 
> Character.isJavaIdentifierStart(int) returns true.
> A "Java letter-or-digit" is a character for which the method 
> Character.isJavaIdentifierPart(int) returns true.?
> 
> However, I can for a fixed version of the Spec evaluate the two 
> functions for all code points, and then define a rule for Java Letter 
> and Java Digit that is not an operational definition, e.g.:
> 
> fragment JavaLetter : [\p{Lu}] | [\p{Ll}] | [\p{Lt}] | [\p{Lm}] | 
> [\p{Lo}] | [\p{Nl}] | [\p{Pc}] | [\p{Sc}] ;
> fragment JavaLetterOrDigit : [\p{Lu}] | [\p{Ll}] | [\p{Lt}] | [\p{Lm}] | 
> [\p{Lo}] | [\p{Mn}] | [\p{Mc}] | [\p{Nd}] | [\p{Nl}] | [\p{Cf}] | 
> [\p{Pc}] | [\p{Sc}] | [\u{00000000}-\u{00000008}] | 
> [\u{0000000E}-\u{0000001B}] | [\u{0000007F}-\u{0000009F}] ;
> 
> Why does the Spec use an operation definition for JavaLetter and 
> JavaLetterOrDigit rather than to pick a Unicode standard and define the 
> symbols as set of code points and general categories?
> 
> Ken

From alex.buckley at oracle.com  Mon Dec 20 20:54:51 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:54:51 -0800
Subject: A question regarding handling consecutive '>' characters in "3.2.
 Lexical Translations"
In-Reply-To: <CA+TfdNZaj8P-KcHuabYSR5zybQwH+nZ6YVR4p_mgAmJFcTUhxA@mail.gmail.com>
References: <CA+TfdNZaj8P-KcHuabYSR5zybQwH+nZ6YVR4p_mgAmJFcTUhxA@mail.gmail.com>
Message-ID: <116e623c-ce29-98f5-6f5a-ea4386cee6b1@oracle.com>

Lexical translation was clarified in JLS 17, and the ambiguities called 
out. See the revised sections 3.2 and 3.5, especially:

-----
If the input character > appears in a type context (?4.11), that is, as 
part of a Type or an UnannType in the syntactic grammar (?4.1, ?8.3), it 
is always reduced to the numerical comparison operator >, even when it 
could be combined with an adjacent > character to form a different operator.
-----

The lexer is expected to interact with the parser in order to figure out 
whether a > lexeme could be consumed by the indicated productions of the 
syntactic grammar.

Alex

On 3/17/2021 2:20 AM, Javran Cheng wrote:
> Hello Java SE Spec authors,
> 
> I'm recently reading Java SE 16 spec (this is also present in many other
> recent versions) and there is one part in "3.2. Lexical Translations" that
> I would want some clarification:
> 
>> ... There is one exception: if lexical translation occurs in a type
> context (?4.11) and the input stream has two or more consecutive >
> characters ...
> 
> Here I want to know how can I tell whether it is in a type context when the
> lexical analysis is not done - does this sentence just want to make sure
> readers are aware of this ambiguity when it comes to consecutive >
> characters (so how exactly this is done is up to implementor) or is there
> somewhere explained in the spec regarding how to tell a type context during
> lexical analysis?
> 
> Thanks!
> Javran (Fang) Cheng

From alex.buckley at oracle.com  Mon Dec 20 20:55:05 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 12:55:05 -0800
Subject: =?UTF-8?Q?Re=3a_Typo_in_JLS_16=2c_=c2=a717=2e2=2e4?=
In-Reply-To: <AM9PR10MB407106EE55013F1FE3AD80A1FB5D9@AM9PR10MB4071.EURPRD10.PROD.OUTLOOK.COM>
References: <AM9PR10MB407106EE55013F1FE3AD80A1FB5D9@AM9PR10MB4071.EURPRD10.PROD.OUTLOOK.COM>
Message-ID: <284ee482-3867-af1f-d574-46ca6fd8de8f@oracle.com>

Yes, thanks.

On 5/1/2021 10:03 AM, Bokros Ferenc wrote:
> Dear Sirs,
> 
> I'm afraid there is a typo in JLS 16, ?17.2.4 [Interactions of Waits, Notification, and Interruption].
> 
> This section contains two bullet-lists.
> There is an end-of-sentence point missing after the *first list's* last item's last word ("return from wait by throwing an InterruptedException>>>.<<<'').
> 
> The typo is present in both the HTML (https://docs.oracle.com/javase/specs/jls/se16/html/jls-17.html#jls-17.2.4) and the PDF (https://docs.oracle.com/javase/specs/jls/se16/jls16.pdf) versions.
> 
> (There _was_ a similar typo in this section's *second list's* last item, which was seemingly corrected with version upgrade from JLS 11 to JLS 12.)
> 
> Sincerely,
> Ferenc BOKROS

From alex.buckley at oracle.com  Mon Dec 20 21:00:22 2021
From: alex.buckley at oracle.com (Alex Buckley)
Date: Mon, 20 Dec 2021 13:00:22 -0800
Subject: Typos in JLS version 16
In-Reply-To: <CANfdaS1oVksiQHnigisb4cVP3LnirdjQ3+7fsNSiKHDnMEQd-g@mail.gmail.com>
References: <CANfdaS1oVksiQHnigisb4cVP3LnirdjQ3+7fsNSiKHDnMEQd-g@mail.gmail.com>
Message-ID: <31d1d874-450b-4691-6438-025287023045@oracle.com>

Yes, 16 should be 17 and "a identifier" should be "an identifier", thank 
you.

For Example 8.3-1, "Multiply" (the adjective, not the verb) is correct. 
It's not just that there are multiple fields being inherited, it's that 
"the same field" is inherited multiple times. See also Example 9.3-2.

Alex

On 8/11/2021 7:01 AM, Sam Hooper wrote:
> Hi,
> 
> I noticed a few typos when reading version 16 of the JLS
> <https://docs.oracle.com/javase/specs/jls/se16/html/index.html>. Here they
> are:
> 
>     - In 6.5.1
>     <https://docs.oracle.com/javase/specs/jls/se16/html/jls-6.html#jls-6.5.1>,
>     in the non-normative box, "The extraction of a TypeName from the
>     identifiers of a ReferenceType in the *16* contexts above" should say
>     *17* contexts.
>     - In Example 8.3-1
>     <https://docs.oracle.com/javase/specs/jls/se16/html/jls-8.html#d5e13591>,
>     instead of  "Multipl*y* Inherited Fields," I believe the title should
>     say "Multipl*e* Inherited Fields."
>     - In 7.2
>     <https://docs.oracle.com/javase/specs/jls/se16/html/jls-7.html#jls-7.2>,
>     in the last sentence of the example/non-normative box, instead of "in *a*
>     identifier" it should say "in *an* identifier."
> 
> Thanks for your time.
> 
> Sam Hooper
> 214-477-4343