From gavin.bierman at oracle.com  Mon Nov 25 16:07:44 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 16:07:44 +0000
Subject: typo
In-Reply-To: <CAE=Q7zkko_5bZmEvY-ru8rykV1qy2mkK2-GFkYkWkpPgR+vBaQ@mail.gmail.com>
References: <CAE=Q7zkko_5bZmEvY-ru8rykV1qy2mkK2-GFkYkWkpPgR+vBaQ@mail.gmail.com>
Message-ID: <E22A1CE1-4F0B-4FDE-A47B-BAD9A1771DC1@oracle.com>

Thank you Felix. This change will be made to edition 24 of the JLS.

Thanks,
Gavin

On 10 Dec 2022, at 19:07, Felix Pahl <joriki27 at gmail.com> wrote:

At https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html, "it is possible to known" should be "it is possible to know".

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/eb63bcdd/attachment-0001.htm>

From gavin.bierman at oracle.com  Mon Nov 25 16:15:30 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 16:15:30 +0000
Subject: Typos in Java spec
In-Reply-To: <tencent_D04C25A54EC25983FA2772A6DC1044B5080A@qq.com>
References: <tencent_D04C25A54EC25983FA2772A6DC1044B5080A@qq.com>
Message-ID: <D7EA1CC5-65B1-4348-BF68-CFA4F374C2BC@oracle.com>

Thank you! We?ll make those corrections in the next editions of the JLS/JVMS.

Gavin

> On 11 Jan 2023, at 13:39, ??? (Hu Yajie) <2500418497 at qq.com> wrote:
> 
> Hi. I'd like to report that the latest Java spec contains the following
> opening parentheses that are not closed.
> 
> [JLS]
> 
> Section 8.7, third paragraph from last:
>    A static initializer introduces a static context (?8.1.3
> 
> Section 15.8.3, last paragraph:
>    At run time, the class of the actual object referred to may be C or
>    a subclass of C (?8.1.5.
> 
> [JVMS]
> 
> Section 4.7.27, first paragraph:
>    The ModuleMainClass attribute is a fixed-length attribute in the
>    attributes table of a ClassFile structure (?4.1.


From gavin.bierman at oracle.com  Mon Nov 25 16:47:44 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 16:47:44 +0000
Subject: Edit suggestion in section 3.10.4 Character Literals
In-Reply-To: <CACQZjSP9JZbYwjA1yi2ygQcut-9hU76O0WgNrBDM4PtfuFMM+A@mail.gmail.com>
References: <CACQZjSP9JZbYwjA1yi2ygQcut-9hU76O0WgNrBDM4PtfuFMM+A@mail.gmail.com>
Message-ID: <784B33E2-2F5E-49AB-B3CC-6C626A2AEC36@oracle.com>

Thank you! We?ll make this correction in the next edition of the JLS.

Gavin

On 11 Apr 2023, at 20:16, Turkhan Badalov <badalov.turxan at gmail.com> wrote:

In the paragraph below, I believe the preposition "by" is skipped. Shouldn't it be "The character represented BY a character literal"?

> The character represented a character literal is the content of the
character literal with any escape sequence interpreted, as if by execution of
String.translateEscapes on the content.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/2764d23d/attachment-0001.htm>

From gavin.bierman at oracle.com  Mon Nov 25 17:08:33 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 17:08:33 +0000
Subject: typo in JLS 20
In-Reply-To: <188e79d6a4b.21efb348623976.900052122439105888@zensoftech.co.in>
References: <188e79d6a4b.21efb348623976.900052122439105888@zensoftech.co.in>
Message-ID: <D7BE1ACE-3567-4F09-BFDD-36F54A834E7F@oracle.com>

Thank you for your suggestion.

On 23 Jun 2023, at 10:37, Pravin <pravin at zensoftech.co.in> wrote:

Hello sir/madam,

In the last para on page 44. the following sentence

Supplementary characters must be represented
either as a surrogate pair within a char sequence, or as an integer, depending on
the API they are used with.

may be replaced with

Supplementary characters must be represented
either as a surrogate pair within a java.lang.CharSequence, or as an integer, depending on
the API they are used with.

regards,
Pravin


You may find this article interesting: https://www.oracle.com/technical-resources/articles/javase/supplementary.html

You?ll find the following explanation:

This article also uses the terms  character sequence or  char sequence  in many places to summarize all the containers of character sequences that the Java 2 Platform knows:  char[], implementations of  java.lang.CharSequence (such as the  String class), and implementations of  java.text.CharacterIterator.


I hope this explains the JLS terminology.

Many thanks,
Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/3e512c9c/attachment.htm>

From gavin.bierman at oracle.com  Mon Nov 25 17:16:12 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 17:16:12 +0000
Subject: =?utf-8?B?UmU6IFRoZSBKYXZhwq4sTGFuZ3VhZ2UgU3BlY2lmaWNhdGlvbi4gVHlwZSBv?=
 =?utf-8?Q?n_page_33?=
In-Reply-To: <219db5f0-7a6d-44d7-934f-cfcbc5f48db5@gmail.com>
References: <5c3387de-6757-49c5-88fe-11ca656899a9@gmail.com>
 <fcb49a07-193d-48a7-a700-5d1b152f1c54@oracle.com>
 <219db5f0-7a6d-44d7-934f-cfcbc5f48db5@gmail.com>
Message-ID: <269228E3-0997-4A25-8B4B-912D7F5270BE@oracle.com>

Hi Dzmitry,

Thanks for your email. In fact, if you look further in Wikipedia: https://en.wikipedia.org/wiki/English_alphabet#Letter_names

You?ll see that in the table it gives both spellings for ?L?, i.e. ?el? or ?ell?. It has a footnote for ?ell? stating this is the US spelling. (I suspect this is why Leslie Lamport picked it for LaTeX.)

The rest of the JLS adopts US spellings always, so I propose that we keep to the ?ell? spelling.

Best wishes,
Gavin

On 26 Jul 2024, at 23:17, Dzmitry Krakadzeyau <krakadzeyau at gmail.com> wrote:


Hi, Alex,

LaTeX is a cool tool but according to https://en.wikipedia.org/wiki/L:

L, or l, is the twelfth letter<https://en.wikipedia.org/wiki/Letter_(alphabet)> of the Latin alphabet<https://en.wikipedia.org/wiki/Latin_alphabet>, used in the modern English alphabet<https://en.wikipedia.org/wiki/English_alphabet>, the alphabets of other western European languages and others worldwide. Its name in English is el<https://en.wikipedia.org/wiki/English_alphabet#Letter_names> (pronounced /??l/<https://en.wikipedia.org/wiki/Help:IPA/English> EL<https://en.wikipedia.org/wiki/Help:Pronunciation_respelling_key>), plural els.

Reference:

"L" Oxford English Dictionary, 2nd edition (1989) Merriam-Webster's Third New International Dictionary of the English Language, Unabridged. (1993)

I have Oxford English Dictionary, 2nd edition (1989) and confirm that it mentions "el" but not "ell".


On 7/26/24 18:09, Alex Buckley wrote:
"ell" is used in US English for the name of the letter 'l'. See also \ell in LaTeX.

Alex

On 3/29/2024 5:02 PM, Dzmitry Krakadzeyau wrote:
Hi,

The document "/jls22.pdf/":

/Specification: JSR-397 Java SE 22
Version: 22
Status: Final Release
Release: March 2024
/

has a type on page 33:

/The suffix L is preferred, because the letter l (*ell*) is often hard to distinguish from the digit 1 (one)./

It must be "/letter l (*el*)/".

--
Best regards,
Dzmitry Krakadzeyau


--
Best regards,
Dzmitry Krakadzeyau

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/dcc2ef7e/attachment-0001.htm>

From gavin.bierman at oracle.com  Mon Nov 25 17:35:39 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 17:35:39 +0000
Subject: unclear grammar java 20
In-Reply-To: <AM9P191MB138268C88FC0613BCB7EB06BE25AA@AM9P191MB1382.EURP191.PROD.OUTLOOK.COM>
References: <AM9P191MB138268C88FC0613BCB7EB06BE25AA@AM9P191MB1382.EURP191.PROD.OUTLOOK.COM>
Message-ID: <62ACDEA3-A93E-4FC7-830B-04FB274E3BD2@oracle.com>

Hi Ed,

Thanks for your email. Whilst I can imagine that such a thing would be useful, I?m afraid that we make no claims that the grammar in the JLS is suitable for plugging directly into a parser generator or any other tool. Indeed there are places in the JLS where the grammar is used to capture semantic rather than syntactic issues, and places where we impose semantic rather than syntactic restrictions.

Thanks,
Gavin


On 14 Jun 2023, at 10:08, Doorn, Ed van <ed.vandoorn at ou.nl> wrote:

Part of my research is detecting design patterns in Java sources.
Therefore it is necessary to parse Java sources

I used the grammar specified in https://docs.oracle.com/javase/specs/jls/se20/html/index.html.
First, I made the grammar useful for the bottom-up parser generator cup (http://www2.cs.tum.edu/projects/cup/)
This resulted in more than 100 shifts/reduce and reduce/reduce conflicts.
Reduce/reduce conflicts and suggest grammar mistakes.

Second, I made the grammar useful for the top-down parser generator Grammatica (https://grammatica.percederberg.net<https://grammatica.percederberg.net/>).
This resulted in many errors because the LL () grammar is not valid.

An example:
The production rule for ClassOrInterfaceType and ClassType is:

ClassOrInterfaceType:
ClassType<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-ClassType>
InterfaceType<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-InterfaceType>


ClassType:
{Annotation<https://docs.oracle.com/javase/specs/jls/se20/html/jls-9.html#jls-Annotation>} TypeIdentifier<https://docs.oracle.com/javase/specs/jls/se20/html/jls-3.html#jls-TypeIdentifier> [TypeArguments<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-TypeArguments>]
PackageName<https://docs.oracle.com/javase/specs/jls/se20/html/jls-6.html#jls-PackageName> . {Annotation<https://docs.oracle.com/javase/specs/jls/se20/html/jls-9.html#jls-Annotation>} TypeIdentifier<https://docs.oracle.com/javase/specs/jls/se20/html/jls-3.html#jls-TypeIdentifier> [TypeArguments<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-TypeArguments>]
ClassOrInterfaceType<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-ClassOrInterfaceType> . {Annotation<https://docs.oracle.com/javase/specs/jls/se20/html/jls-9.html#jls-Annotation>} TypeIdentifier<https://docs.oracle.com/javase/specs/jls/se20/html/jls-3.html#jls-TypeIdentifier> [TypeArguments<https://docs.oracle.com/javase/specs/jls/se20/html/jls-4.html#jls-TypeArguments>]

This results in an infinite loop: ClassOrInterfaceType produces a ClassType and  ClassType produces
ClassOrInterfaceType .....

Some production rules have more than one alternative which starts with @
which is not valid LL and can not be solved by looking ahead with more tokens.

Is a valid bottom-up grammar e.g. LALR(1) of top-down grammar LL(k) available?

ANTLR provides a LL() grammar for Java 9, that is of course out of date.

With regards,

Ed van Doorn

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/974f04a7/attachment-0001.htm>

From gavin.bierman at oracle.com  Mon Nov 25 17:54:44 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 17:54:44 +0000
Subject: Two Uncertain Technical Errors and Omissions of JLS 21
In-Reply-To: <242b8357.3b67.18b9410c773.Coremail.jimdragongod@126.com>
References: <242b8357.3b67.18b9410c773.Coremail.jimdragongod@126.com>
Message-ID: <2E19B56F-0C63-4AA6-999F-B14287487F95@oracle.com>

Dear Jim,

Thanks for your email.

On 3 Nov 2023, at 07:23, jim <jimdragongod at 126.com> wrote:

Dear Authors of JLS 21?
    I've found two uncertain technical errors and omissions of ?The Java? Language Specification Java SE 21 Edition??as follows?
?1?uncertain omission
      The "Chapter 19. Syntax" says: "This chapter repeats the syntactic grammar given in Chapters 4, 6-10, 14, and 15, as well as key parts of the lexical grammar from Chapter 3, using the notation from ?2.4."  I checked over all the repeated productions after Chapter 3, and found that the "Productions from ?14 (Blocks, Statements, and Patterns)" lacked the definition of production "VariableAccess", which is:
    VariableAccess:
        ExpressionName
        FieldAccess
I think this may be an omission, because all other productions after Chapter 3 are present.

Indeed it is an omission! Thanks. This will be corrected in the next edition of the JLS.


?2?uncertain error comment
Sited from the two possible execution order "Example 17.4.5-1" in Chapter 17:
1: B = 1;
3: A = 2;
2: r2 = A; // sees initial write of 0
4: r1 = B; // sees initial write of 0
and
1: r2 = A; // sees write of A = 2
3: r1 = B; // sees write of B = 1
2: B = 1;
4: A = 2;
I think there should be a swap between the above comments?is it right?


No, I don?t think so. If you read to the end of the example (I highlight the import part in bold):

In this execution, the reads see writes that occur later in the execution order. This may seem
counterintuitive, but is allowed by happens-before consistency. Allowing reads to see later
writes can sometimes produce unacceptable behaviors.


You are being confused by the ?counterintuitive? semantics I think!

Thanks,
Gavin


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/40036499/attachment.htm>

From gavin.bierman at oracle.com  Mon Nov 25 18:15:11 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 18:15:11 +0000
Subject: is instanceof an operator?
In-Reply-To: <CWLP265MB262509D9185D05FDAA5FAB96C7489@CWLP265MB2625.GBRP265.PROD.OUTLOOK.COM>
References: <CWLP265MB262509D9185D05FDAA5FAB96C7489@CWLP265MB2625.GBRP265.PROD.OUTLOOK.COM>
Message-ID: <C24ED1F1-3BC0-4157-BDFD-DFD6B59A094A@oracle.com>

Hi Anton,

Thanks for your email. It is perhaps a little confusing, but chapter 3 is talking about the lexical structure of the language, i.e. the tokens. So, 3.12 is talking about the syntactic tokens that we call the operators. (Perhaps more precisely, the operator tokens.)

Chapter 15, in contrast, is talking about the various categories of expressions. It uses ?operator? in a quite different sense (really it is talking about operator expressions). For example in 15.5, when talking about errors in casts:

In a cast, when the actual class of the object referenced by the value of the
operand expression is not compatible with the target type specified by the cast
operator (?5.5, ?15.16); in this case a ClassCastException is thrown.

Note the reference to the cast operator here (in bold), which isn?t in the list of 3.12 either.

So, when reading chapter 15, one should have this categorisation in mind (from 15.2):


Expressions can be broadly categorized into one of the following syntactic forms:

? Expression names (?6.5.6)

? Primary expressions (?15.8 - ?15.13)

? Unary operator expressions (?15.14 - ?15.16)

? Binary operator expressions (?15.17 - ?15.24, and ?15.26)

? Ternary operator expressions (?15.25)

? Lambda expressions (?15.27)

? switch expressions (?15.28)

So, the category of unary operator expressions includes cast expressions too. In that spirit, the category of binary operator expressions includes the instanceof expressions, and hence in the context of chapter 15, we can speak of instanceof as a (binary) operator.

Hope this helps,
Gavin

On 31 May 2023, at 11:14, Anton.Dil <anton.dil at open.ac.uk> wrote:

Greetings,

I have a query about which tokens should be considered operators.

Many sources say that instanceof is an operator, including the JLS, e.g. at https://docs.oracle.com/javase/specs/jls/se17/html/jls-15.html#jls-15.20.2

However, instanceof is not included in the list of operators here https://docs.oracle.com/javase/specs/jls/se17/html/jls-3.html#jls-3.12

Which is correct? Should instanceof be in the operators list?

Regards,

Anton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/26ffec78/attachment-0001.htm>

From gavin.bierman at oracle.com  Mon Nov 25 23:10:38 2024
From: gavin.bierman at oracle.com (Gavin Bierman)
Date: Mon, 25 Nov 2024 23:10:38 +0000
Subject: Small discrepancies in JLS 14+
In-Reply-To: <036601da4315$a14ccc70$e3e66550$@gmail.com>
References: <036601da4315$a14ccc70$e3e66550$@gmail.com>
Message-ID: <64CD12E1-0046-4BD9-BDF3-416A919B866F@oracle.com>

Thanks for your email, Marc. You are correct, there is no point to the production for ConstantExpression, as the nonterminal is not used anywhere. It should have been removed when we refactored the switch grammars in JEP 361. Of course, we still use the phrase ?constant expression?  but it isn?t defined syntactically by a grammar; 15.29 does not define "constant expression" syntactically as "Anything that matches ConstantExpression". Rather, 15.29 defines it _semantically_, as an expression that meets various criteria.

This will be corrected in the next edition of the JLS.

Many thanks,
Gavin


On 9 Jan 2024, at 16:05, mazas.marc at gmail.com wrote:

Hi all

This if of any help.

While writing a parser of the JLS (in fact a translator from the JLS grammar to a corresponding JavaCC grammar), I found some discrepancies.

The most interesting one is in JLS 14+ (e.g. for JLS 21: https://docs.oracle.com/javase/specs/jls/se21/html/jls-19.html):
The (last) production ConstantExpression is no more called in other productions; formerly it was called in SwitchLabel, which now calls  CaseConstant {, CaseConstant}.
The corresponding chapters (e.g. https://docs.oracle.com/javase/specs/jls/se14/html/jls-15.html#jls-15.29) still uses the term ?Constant Expressions?; shouldn?t it use ?Case Constants? ?

Another one was PackageName in JLS 1.8, defined but not called, but now it is called.

The Type production is also defined but not called (one can understand that).

And of course the CompilationUnit is defined and not called.

Regards
Marc Mazas

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241125/45c3f525/attachment.htm>

From pravin at zensoftech.co.in  Tue Nov 26 01:00:14 2024
From: pravin at zensoftech.co.in (Pravin)
Date: Tue, 26 Nov 2024 06:30:14 +0530
Subject: typo in JLS 20
In-Reply-To: <D7BE1ACE-3567-4F09-BFDD-36F54A834E7F@oracle.com>
References: <188e79d6a4b.21efb348623976.900052122439105888@zensoftech.co.in>
 <D7BE1ACE-3567-4F09-BFDD-36F54A834E7F@oracle.com>
Message-ID: <19365fbb2b6.73007df5110661.2861152011703479612@zensoftech.co.in>

Thanks Gavin.

Yes it makes sense, to use char sequence or character sequence, since it is inclusive of char[] and the java.text.CharacterSequence also.

I suggest that the font for char in the text needs to be updated as normal text since here it is not used as a keyword of java.

Also some place to mention about the coverage of char sequence or character sequence.



Thanks and Regards.

Pravin







---- On Mon, 25 Nov 2024 22:38:33 +0530 Gavin Bierman <gavin.bierman at oracle.com> wrote ---



Thank you for your suggestion.
 
On 23 Jun 2023, at 10:37, Pravin <mailto:pravin at zensoftech.co.in> wrote:


Hello sir/madam,



In the last para on page 44. the following sentence



Supplementary characters must be represented

either as a surrogate pair within a char sequence, or as an integer, depending on

the API they are used with.



may be replaced with



Supplementary characters must be represented

either as a surrogate pair within a java.lang.CharSequence, or as an integer, depending on

the API they are used with.



regards,

Pravin








You may find this article interesting:?https://www.oracle.com/technical-resources/articles/javase/supplementary.html



You?ll find the following explanation:



This article also uses the terms??character
 sequence?or??char?sequence??in
 many places to summarize all the containers of character sequences that the Java 2 Platform knows:??char[],
 implementations of??java.lang.CharSequence?(such
 as the??String?class),
 and implementations of??java.text.CharacterIterator.





I hope this explains the JLS terminology.



Many thanks,

Gavin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jls-jvms-spec-comments/attachments/20241126/2c59b0fe/attachment-0001.htm>