From jlahoda at openjdk.org  Wed Mar  1 10:20:53 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 Mar 2023 10:20:53 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when primitive
 type changes
Message-ID: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>

The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.

There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.

This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.

There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.

This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.

-------------

Commit messages:
 - 8303355: The Depend plugin does fully recompile when primitive type changes

Changes: https://git.openjdk.org/jdk/pull/12801/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12801&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303355
  Stats: 63 lines in 1 file changed: 31 ins; 23 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/12801.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12801/head:pull/12801

PR: https://git.openjdk.org/jdk/pull/12801

From vromero at openjdk.org  Wed Mar  1 11:18:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Mar 2023 11:18:05 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when
 primitive type changes
In-Reply-To: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
Message-ID: <4bmHu189JLzD266D0F-zzSuce1WjTXyzSDAVlsaYd9Y=.ef6c8a0c-929f-4024-8051-4612cfad04bf@github.com>

On Wed, 1 Mar 2023 10:12:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.
> 
> There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.
> 
> This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.
> 
> There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.
> 
> This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.

make/jdk/src/classes/build/tools/depend/Depend.java line 885:

> 883:         @Override
> 884:         public Void visitPrimitiveType(PrimitiveTypeTree node, Void p) {
> 885:             update(node.getPrimitiveTypeKind().name());

shouldn't `DependTest` include a test to stress this new code?

-------------

PR: https://git.openjdk.org/jdk/pull/12801

From erikj at openjdk.org  Wed Mar  1 14:08:06 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Wed, 1 Mar 2023 14:08:06 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when
 primitive type changes
In-Reply-To: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
Message-ID: <P_A1diNgHYh82a-okllEGoY_0qPtRXuq_3fPfTlYUDc=.cea9a6f9-3d65-40e5-9d75-9d32dd7d1762@github.com>

On Wed, 1 Mar 2023 10:12:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.
> 
> There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.
> 
> This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.
> 
> There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.
> 
> This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.

Marked as reviewed by erikj (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12801

From jlahoda at openjdk.org  Wed Mar  1 18:56:49 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 Mar 2023 18:56:49 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when
 primitive type changes [v2]
In-Reply-To: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
Message-ID: <DiB19fFYx1hzyFRvRHrFPOqmXpb6CYcW3c8BxmSa_o0=.8fafa082-fec8-4ba2-9205-4c0b4bca091e@github.com>

> The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.
> 
> There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.
> 
> This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.
> 
> There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.
> 
> This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Adjusting DependTest, as suggested on the review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12801/files
  - new: https://git.openjdk.org/jdk/pull/12801/files/63cd6884..de84439d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12801&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12801&range=00-01

  Stats: 50 lines in 2 files changed: 46 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12801.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12801/head:pull/12801

PR: https://git.openjdk.org/jdk/pull/12801

From jlahoda at openjdk.org  Wed Mar  1 19:01:16 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 1 Mar 2023 19:01:16 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when
 primitive type changes [v2]
In-Reply-To: <4bmHu189JLzD266D0F-zzSuce1WjTXyzSDAVlsaYd9Y=.ef6c8a0c-929f-4024-8051-4612cfad04bf@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
 <4bmHu189JLzD266D0F-zzSuce1WjTXyzSDAVlsaYd9Y=.ef6c8a0c-929f-4024-8051-4612cfad04bf@github.com>
Message-ID: <Q1LWh_aQgA4W-6T7lI652xs4CSTOimHoB1xNwXja1z8=.cea029b4-b474-4b53-aaf8-d6545bd8b3e6@github.com>

On Wed, 1 Mar 2023 11:09:17 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjusting DependTest, as suggested on the review
>
> make/jdk/src/classes/build/tools/depend/Depend.java line 885:
> 
>> 883:         @Override
>> 884:         public Void visitPrimitiveType(PrimitiveTypeTree node, Void p) {
>> 885:             update(node.getPrimitiveTypeKind().name());
> 
> shouldn't `DependTest` include a test to stress this new code?

Test updated:
https://github.com/openjdk/jdk/pull/12801/commits/de84439d64f6882d64f657fee0f6c55b2f717a9c

Thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12801

From vromero at openjdk.org  Wed Mar  1 19:44:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 1 Mar 2023 19:44:05 GMT
Subject: RFR: 8303355: The Depend plugin does fully recompile when
 primitive type changes [v2]
In-Reply-To: <DiB19fFYx1hzyFRvRHrFPOqmXpb6CYcW3c8BxmSa_o0=.8fafa082-fec8-4ba2-9205-4c0b4bca091e@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
 <DiB19fFYx1hzyFRvRHrFPOqmXpb6CYcW3c8BxmSa_o0=.8fafa082-fec8-4ba2-9205-4c0b4bca091e@github.com>
Message-ID: <9vmWYDQP8zQfpOC2AugwiSp1BiJVIbraY7vuFZ-BRHs=.8b7ce1dc-682f-462c-a873-1fef68f6780b@github.com>

On Wed, 1 Mar 2023 18:56:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.
>> 
>> There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.
>> 
>> This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.
>> 
>> There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.
>> 
>> This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjusting DependTest, as suggested on the review

looks good, thanks

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12801

From jlahoda at openjdk.org  Thu Mar  2 09:44:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 2 Mar 2023 09:44:24 GMT
Subject: Integrated: 8303355: The Depend plugin does fully recompile when
 primitive type changes
In-Reply-To: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
References: <6wApt96uhBhrpUrQSLNetyPYYeQnkDFZZEew2ADDFMo=.90ecbdce-e0ae-4377-b775-e0ebb03d5bf3@github.com>
Message-ID: <UpLsirm8DOdjavx25Rkuqfv-QE7P6pxAaoHQxgcU47Q=.268c08f8-3b44-4a81-af74-506755f47094@github.com>

On Wed, 1 Mar 2023 10:12:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> The OpenJDK build is using a Plugin called Depend to avoid building Java code unnecessarily. It has two parts, one is checking module APIs (and forces rebuild of dependent modules if a dependency changes), and second takes modified files in a module, and attempts to detect whether it is enough to recompile these files, or if the whole module must be rebuilt.
> 
> There's a bug in the second part, it does not track changes in primitive types, so e.g. a change of a type of a public field form `int` to `long` does not cause recompile.
> 
> This patch fixes that by visiting the primitive types, and including them in the hash computed for the given file.
> 
> There's also another problem - if a module is being recompiled from scratch due to a change in a file hash, the new/updated file hashes are written immediately. And if the compilation consequently fails, the state is not compared to the original hash, but to the hash from the broken compilation, which may lead to missing compilation of some files.
> 
> This patch moves the code to write the new hashes to the end of compilation, and only do that when there were no compile-time errors during the compilation.

This pull request has now been integrated.

Changeset: dbb562d3
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbb562d3b128094cb5bca55237e1331e83526adb
Stats:     113 lines in 2 files changed: 77 ins; 23 del; 13 mod

8303355: The Depend plugin does fully recompile when primitive type changes

Reviewed-by: erikj, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12801

From jlaskey at openjdk.org  Thu Mar  2 11:14:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 2 Mar 2023 11:14:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <vTJqNaX9fjbIH3HI8trEPzWajVLisZxpt3VH3yzcu1c=.dc19b7bf-aa94-4bc8-8035-6b47490fa6bc@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ?

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From prappo at openjdk.org  Thu Mar  2 12:13:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 2 Mar 2023 12:13:14 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
Message-ID: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>

Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.

The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:


    diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
    --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
    +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
    @@ -17084,7 +17084,7 @@
                      throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
     <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
     <div class="block"><code>readObject</code> is called to restore the state of the
    - (@code BasicPermission} from a stream.</div>
    + <code>BasicPermission</code> from a stream.</div>
     <dl class="notes">
     <dt>Parameters:</dt>
     <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>

Notes
-----

* I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
* I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
* I will update copyright years after (and if) the fix had been approved, as required.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/12826/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303480
  Stats: 75 lines in 39 files changed: 0 ins; 0 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

PR: https://git.openjdk.org/jdk/pull/12826

From mullan at openjdk.org  Thu Mar  2 13:24:07 2023
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 2 Mar 2023 13:24:07 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <GCwAXDcnMpAJDHxB9QMEP9UmwTYemW62F7RUdNaEVk8=.8b73051d-d3a8-4fac-ac48-efc3864d33bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

security related changes look fine.

-------------

Marked as reviewed by mullan (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From alex.buckley at oracle.com  Thu Mar  2 17:04:30 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Thu, 2 Mar 2023 09:04:30 -0800
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <vTJqNaX9fjbIH3HI8trEPzWajVLisZxpt3VH3yzcu1c=.dc19b7bf-aa94-4bc8-8035-6b47490fa6bc@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <vTJqNaX9fjbIH3HI8trEPzWajVLisZxpt3VH3yzcu1c=.dc19b7bf-aa94-4bc8-8035-6b47490fa6bc@github.com>
Message-ID: <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com>

On 3/2/2023 3:14 AM, Jim Laskey wrote:
> Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ?

I added remarks to the CSR about the static field STR that is 
automatically imported into every Java program. (Only when preview 
features are enabled, right?)

Alex

From james.laskey at oracle.com  Thu Mar  2 17:14:13 2023
From: james.laskey at oracle.com (Jim Laskey)
Date: Thu, 2 Mar 2023 17:14:13 +0000
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <vTJqNaX9fjbIH3HI8trEPzWajVLisZxpt3VH3yzcu1c=.dc19b7bf-aa94-4bc8-8035-6b47490fa6bc@github.com>
 <78f03eda-ea1d-40f2-2a57-1ec805aa1d3e@oracle.com>
Message-ID: <12FF7F62-040D-4F2D-B68F-BA5AC0DA5EE2@oracle.com>

Correct and thank you. 

?

> On Mar 2, 2023, at 1:04 PM, Alex Buckley <alex.buckley at oracle.com> wrote:
> 
> ?On 3/2/2023 3:14 AM, Jim Laskey wrote:
>> Can I get some signing reviewers of the CSR https://bugs.openjdk.org/browse/JDK-8286021 ?
> 
> I added remarks to the CSR about the static field STR that is automatically imported into every Java program. (Only when preview features are enabled, right?)
> 
> Alex

From prr at openjdk.org  Thu Mar  2 21:29:04 2023
From: prr at openjdk.org (Phil Race)
Date: Thu, 2 Mar 2023 21:29:04 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <LDJs1K7coRg4R4EWiETtoqjNIaZchHUjyKAg2madLSM=.11763787-9322-4863-8ca9-242447a9c6de@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

java.desktop changes are fine

-------------

Marked as reviewed by prr (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From cjplummer at openjdk.org  Thu Mar  2 22:18:08 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 2 Mar 2023 22:18:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <63UHTjtrUOVGBTwRt_M4QJ7aqBnuAGqekNTTTl3GM74=.ddedac04-ff87-40b9-9ea7-6b6d26d9d202@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

The SA changes (jdk.hotspot.agent) look fine.

-------------

Marked as reviewed by cjplummer (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From archie.cobbs at gmail.com  Thu Mar  2 23:32:15 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 2 Mar 2023 17:32:15 -0600
Subject: JDK-8268622 - Performance issues in javac `Name` class
In-Reply-To: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
Message-ID: <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>

On Tue, Feb 28, 2023 at 9:30 AM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> Jon and I have been discussing JDK-8268622
> <https://bugs.openjdk.org/browse/JDK-8268622> via JBS comments, but it's
> better off being discussed on compiler-dev, so we're moving the discussion
> here...
>

Jon (and anyone else interested),

Please take a look at https://github.com/openjdk/jdk/pull/12843 and let me
know what you think.

Thanks,
-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230302/71fdc57a/attachment.htm>

From vromero at openjdk.org  Fri Mar  3 04:18:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Mar 2023 04:18:58 GMT
Subject: RFR: 8303539: javadoc typos in Attr
Message-ID: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>

Very minimal fix changing only the javadoc of method: `Attr.ResultInfo::needsArgumentAttr`, the fix is basically doing:


{@ArgumentAttr} -> {@code ArgumentAttr}

TIA

-------------

Commit messages:
 - 8303539: javadoc typos in Attr

Changes: https://git.openjdk.org/jdk/pull/12846/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303539
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12846.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12846/head:pull/12846

PR: https://git.openjdk.org/jdk/pull/12846

From iris at openjdk.org  Fri Mar  3 04:34:12 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 3 Mar 2023 04:34:12 GMT
Subject: RFR: 8303539: javadoc typos in Attr
In-Reply-To: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
References: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
Message-ID: <CDMeO_CD2O2ga2zzLpYXg3GD8wgZvvTIAi8XT9wOu6c=.9b097c66-5951-4490-b54f-713f9a4196f9@github.com>

On Fri, 3 Mar 2023 04:11:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very minimal fix changing only the javadoc of method: `Attr.ResultInfo::needsArgumentAttr`, the fix is basically doing:
> 
> 
> {@ArgumentAttr} -> {@code ArgumentAttr}
> 
> TIA

Marked as reviewed by iris (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12846

From jjg at openjdk.org  Fri Mar  3 05:10:12 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 3 Mar 2023 05:10:12 GMT
Subject: RFR: 8303539: javadoc typos in Attr
In-Reply-To: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
References: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
Message-ID: <aq4CO-Zr1MmchRkzOYS-jmS9DH5ATz6MieCRAa2QAOU=.f01322a1-ceba-4954-864a-b1dffbb777f2@github.com>

On Fri, 3 Mar 2023 04:11:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very minimal fix changing only the javadoc of method: `Attr.ResultInfo::needsArgumentAttr`, the fix is basically doing:
> 
> 
> {@ArgumentAttr} -> {@code ArgumentAttr}
> 
> TIA

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12846

From aivanov at openjdk.org  Fri Mar  3 08:28:19 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 08:28:19 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Looks good to me.

I looked through all the changes, paying more attention to the client area.

src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:

> 255: 
> 256:     /**
> 257:      * @return true iff the BSM method type exactly matches

I assume ?iff? should ?if??

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:

> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged

Is it ??has a {@code throws} clause???

-------------

Marked as reviewed by aivanov (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Fri Mar  3 09:41:06 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:41:06 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>

On Thu, 2 Mar 2023 16:23:17 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
> 
>> 255: 
>> 256:     /**
>> 257:      * @return true iff the BSM method type exactly matches
> 
> I assume ?iff? should ?if??

Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)

@cl4es (Claes Redestad), as the author of those lines would you like to chime in?

Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`

While there's a similarly-name method with slightly different parameters, I refrained from using it:
`java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Fri Mar  3 09:44:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 3 Mar 2023 09:44:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
Message-ID: <5TgKeBVz0u1hCa1qOiC7Y46DJvUtDIsDa1wv2I4tAX8=.8575f968-0685-450d-8d77-16523cd7531a@github.com>

On Fri, 3 Mar 2023 08:15:49 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java line 2866:
> 
>> 2864:      * Merge multiple abstract methods. The preferred method is a method that is a subsignature
>> 2865:      * of all the other signatures and whose return type is more specific {@link MostSpecificReturnCheck}.
>> 2866:      * The resulting preferred method has a thrown clause that is the intersection of the merged
> 
> Is it ??has a {@code throws} clause???

Thanks! I'll add this to a separate PR.

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From redestad at openjdk.org  Fri Mar  3 10:12:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 3 Mar 2023 10:12:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
Message-ID: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>

On Fri, 3 Mar 2023 09:38:13 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/BootstrapMethodInvoker.java line 257:
>> 
>>> 255: 
>>> 256:     /**
>>> 257:      * @return true iff the BSM method type exactly matches
>> 
>> I assume ?iff? should ?if??
>
> Here and elsewhere in this file "iff" might mean [if and only if](https://en.wikipedia.org/wiki/If_and_only_if), which would make sense. (FWIW, there are a few hundred occurrences of the word "iff" in src.)
> 
> @cl4es (Claes Redestad), as the author of those lines would you like to chime in?
> 
> Since Claes might read this, I note that when I changed unsupported `{@see}` to `{@link}` thoughtout this file, my IDE could not resolve one of the links: `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,Class,MethodType,MethodHandle,MethodType)`
> 
> While there's a similarly-name method with slightly different parameters, I refrained from using it:
> `java.lang.invoke.LambdaMetafactory#metafactory(MethodHandles.Lookup,String,MethodType,MethodType,MethodHandle,MethodType)`.

Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".

The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From vromero at openjdk.org  Fri Mar  3 10:36:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Mar 2023 10:36:21 GMT
Subject: RFR: 8303539: javadoc typos in Attr
In-Reply-To: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
References: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
Message-ID: <9Vv0r7KjnM19kL4LBe16RhrxLUilg8wFmuLAqEoMVwE=.6fc21b00-bf65-4b96-a792-b3e72f069ef9@github.com>

On Fri, 3 Mar 2023 04:11:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very minimal fix changing only the javadoc of method: `Attr.ResultInfo::needsArgumentAttr`, the fix is basically doing:
> 
> 
> {@ArgumentAttr} -> {@code ArgumentAttr}
> 
> TIA

thanks for the review

-------------

PR: https://git.openjdk.org/jdk/pull/12846

From vromero at openjdk.org  Fri Mar  3 10:36:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 3 Mar 2023 10:36:22 GMT
Subject: Integrated: 8303539: javadoc typos in Attr
In-Reply-To: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
References: <WMbR6lGs2OBTchb7fbZGBmZ6J9uviwk091xkilnVv5w=.f6e42d2c-7fde-4fd6-b184-6618272cb6a5@github.com>
Message-ID: <KOim8jULEVjRtApF1IEc0rRUKVxo_HCbvHxCXXB3hiw=.ba34a00f-8f7a-495a-b385-b744d8ea3700@github.com>

On Fri, 3 Mar 2023 04:11:56 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Very minimal fix changing only the javadoc of method: `Attr.ResultInfo::needsArgumentAttr`, the fix is basically doing:
> 
> 
> {@ArgumentAttr} -> {@code ArgumentAttr}
> 
> TIA

This pull request has now been integrated.

Changeset: 339ca887
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/339ca887835d6456da9fcccdc32fb7716cbc60bb
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8303539: javadoc typos in Attr

Reviewed-by: iris, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/12846

From aivanov at openjdk.org  Fri Mar  3 11:34:16 2023
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 3 Mar 2023 11:34:16 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
In-Reply-To: <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
Message-ID: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>

On Fri, 3 Mar 2023 10:09:27 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.

I've never come across it before. With your explanations, it makes perfect sense.

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From archie.cobbs at gmail.com  Fri Mar  3 14:23:09 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 3 Mar 2023 08:23:09 -0600
Subject: JDK-8268622 - Performance issues in javac `Name` class
In-Reply-To: <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
Message-ID: <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>

On Thu, Mar 2, 2023 at 5:32 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Tue, Feb 28, 2023 at 9:30 AM Archie Cobbs <archie.cobbs at gmail.com>
> wrote:
>
>> Jon and I have been discussing JDK-8268622
>> <https://bugs.openjdk.org/browse/JDK-8268622> via JBS comments, but it's
>> better off being discussed on compiler-dev, so we're moving the discussion
>> here...
>>
>
> Jon (and anyone else interested),
>
> Please take a look at https://github.com/openjdk/jdk/pull/12843 and let
> me know what you think.
>

Also here's a "sketch" of a refactoring along the lines of JDK-8269957
<https://bugs.openjdk.org/browse/JDK-8269957> "facilitate alternate impls
of NameTable and Name".


https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8269957

Let me know if this is the kind of thing you had in mind. Note, this
includes the above patch as well.

Overview of changes...

   - Remove any byte-oriented methods from Name and NameTable API's, except
   for those that "import" or "export" as UTF-8.
   - Refactor SharedNameTable & UnsharedNameTable to have a new common
   superclass Utf8NameTable
   - Fix bug in PoolReader, in that it was not doing any validation when
   decoding "Modified UTF-8". For example, this bug could result in duplicate
   Names if a classfile contained the same name encoded two different ways.
   - Eliminated an unnecessary extra array allocation in Convert.utf2chars()
   - Rename Name.lastIndexOf() -> Name.lastIndexOfAscii() for safety

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230303/e940c8a1/attachment.htm>

From rriggs at openjdk.org  Fri Mar  3 20:27:53 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Mar 2023 20:27:53 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37:

> 35: 
> 36: /**
> 37:  * Policies using this additional interface have the flexibility to specialize

Since it is 'sealed' it may clarify the use to say "Builtin policies"...

src/java.base/share/classes/java/lang/template/StringProcessor.java line 49:

> 47:  * @implNote Implementations using {@link StringProcessor} are equivalent to implementations using
> 48:  * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>},
> 49:  * however, StringProcessor is cleaner and easier to understand.

Split into two sentences.

Suggestion:

 * {@code TemplateProcessor<String>} or {@code ValidatingProcessor<String, RuntimeException>}.
 * However, StringProcessor is cleaner and easier to understand.

src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:

> 56:     /**
> 57:      * Constructs a {@link String} based on the template fragments and values in the
> 58:      * supplied {@link StringTemplate} object.

Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type.
(As compared to TemplateProcessor.process(stringTemplate))
Suggestion:

     * supplied {@link StringTemplate} object.

src/java.base/share/classes/java/util/FormatProcessor.java line 42:

> 40:  * {@link Formatter} specifications and values found in the {@link StringTemplate}.
> 41:  * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the
> 42:  * embedded expression that immediately follows, no whitespace, after the

Suggestion:

 * embedded expression that immediately follows, without whitespace, the

src/java.base/share/classes/java/util/FormatProcessor.java line 66:

> 64:  * <p>
> 65:  * {@link FormatProcessor}  format specification uses and exceptions are the same as
> 66:  * those of {@link Formatter}.

Suggestion:

 * The {@link FormatProcessor} format specification uses and exceptions are the same as
 * those of {@link Formatter}.

src/java.base/share/classes/java/util/FormatProcessor.java line 80:

> 78:  * int x = 10;
> 79:  * int y = 20;
> 80:  * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}";

The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary.
Can the examples, show customized output.

Suggestion:

 * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}";

src/java.base/share/classes/java/util/FormatProcessor.java line 134:

> 132:      * format string from the fragments, gathers up the values and
> 133:      * evaluates the expression
> 134:      * {@code new Formatter(locale).format(format, values).toString()}.

Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible?

src/java.base/share/classes/java/util/FormatProcessor.java line 175:

> 173:      * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}).
> 174:      * <p>
> 175:      * Other {@link FormatProcessor} can be specialized if stored as static final.

Suggestion:

     * Other {@link FormatProcessor}s can be specialized if stored as a static final.

src/java.base/share/classes/java/util/FormatProcessor.java line 187:

> 185:      * @throws  IllegalFormatException
> 186:      *          If a format specifier contains an illegal syntax, a format
> 187:      *          specifier that is incompatible with the given arguments,

Suggestion:

     *          specifier is incompatible with the given arguments,

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jonathan.gibbons at oracle.com  Fri Mar  3 23:07:09 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 3 Mar 2023 15:07:09 -0800
Subject: JDK-8268622 - Performance issues in javac `Name` class
In-Reply-To: <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
Message-ID: <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>


On 3/3/23 6:23 AM, Archie Cobbs wrote:
> On Thu, Mar 2, 2023 at 5:32 PM Archie Cobbs <archie.cobbs at gmail.com> 
> wrote:
>
>     On Tue, Feb 28, 2023 at 9:30 AM Archie Cobbs
>     <archie.cobbs at gmail.com> wrote:
>
>         Jon and I have been discussing JDK-8268622
>         <https://bugs.openjdk.org/browse/JDK-8268622> via JBS
>         comments, but it's better off being discussed on compiler-dev,
>         so we're moving the discussion here...
>
>
>     Jon (and anyone else interested),
>
>     Please take a look at https://github.com/openjdk/jdk/pull/12843
>     and let me know what you think.
>
>
> Also here's a "sketch" of a refactoring along the lines of JDK-8269957 
> <https://bugs.openjdk.org/browse/JDK-8269957> "facilitate alternate 
> impls of NameTable and Name".
>
> https://github.com/openjdk/jdk/compare/master...archiecobbs:jdk:JDK-8269957
>
> Let me know if this is the kind of thing you had in mind. Note, this 
> includes the above patch as well.
>
> Overview of changes...
>
>   * Remove any byte-oriented methods from Name and NameTable API's,
>     except for those that "import" or "export" as UTF-8.
>   * Refactor SharedNameTable & UnsharedNameTable to have a new common
>     superclass Utf8NameTable
>   * Fix bug in PoolReader, in that it was not doing any validation
>     when decoding "Modified UTF-8". For example, this bug could result
>     in duplicate Names if a classfile contained the same name encoded
>     two different ways.
>   * Eliminated an unnecessary extra array allocation in
>     Convert.utf2chars()
>   * Rename Name.lastIndexOf() -> Name.lastIndexOfAscii() for safety
>
> -Archie
>
> -- 
> Archie L. Cobbs


Archie,

This is certainly along the lines I imagined, especially your first 
bullet, albeit much more thorough and in depth than I had previously 
considered.

I would give you inline code comments, except that it's not a PR yet.? I 
note that I generally distrust the `getMessage` for any exception for 
which the message is not formally specified in some way ... in other 
words, don't assume that `e.getMessage()` by itself is interesting.

Is it possible to write a test for the bug fix in PoolReader? What is an 
example of a name encoded in two different ways?

Although conceptually simple, this is a significant change for a very 
low level data type. It would be worth doing more testing than just the 
usual langtools tests.? For example, if you build JDK before and after 
this change, are the generated class files the same?

-- Jon




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230303/7e40662d/attachment-0001.htm>

From duke at openjdk.org  Sat Mar  4 16:56:00 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 4 Mar 2023 16:56:00 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering breaks
 the regression suite
Message-ID: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>

This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).

The method `Name.compareTo()` looks like this:

/** An arbitrary but consistent complete order among all Names.
 */
public int compareTo(Name other) {
    return other.getIndex() - this.getIndex();
}

Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.

For example, if you apply this patch:

--- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
+++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
@@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
     /** An arbitrary but consistent complete order among all Names.
      */
     public int compareTo(Name other) {
-        return other.getIndex() - this.getIndex();
+        return this.getIndex() - other.getIndex();
     }

     /** Return true if this is the empty name.

then the following tests will fail:
```TEST: tools/javac/8203436/T8203436b.java
TEST: tools/javac/generics/7034019/T7034019c.java
TEST: tools/javac/generics/7034019/T7034019d.java
TEST: tools/javac/generics/diamond/neg/Neg21.java
TEST: tools/javac/generics/diamond/neg/Neg22.java
TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
TEST: tools/javac/patterns/InferenceUnitTest.java
TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
TEST: tools/javac/varargs/6806876/T6806876.java

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
==============================

The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.

It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:

/**
 * A partial ordering between type symbols that refines the
 * class inheritance graph.
 *
 * Type variables always precede other kinds of symbols.
 */
public final boolean precedes(TypeSymbol that, Types types) {
    if (this == that)
        return false;
    if (type.hasTag(that.type.getTag())) {
        if (type.hasTag(CLASS)) {
            return
                types.rank(that.type) < types.rank(this.type) ||
                types.rank(that.type) == types.rank(this.type) &&
                that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
        } else if (type.hasTag(TYPEVAR)) {
            return types.isSubtype(this.type, that.type);
        }
    }
    return type.hasTag(TYPEVAR);
}

If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.

An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.

Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.

When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.

So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.

That's what this patch does.

-------------

Commit messages:
 - Require Name.compareTo() to produce a lexicographic ordering.

Changes: https://git.openjdk.org/jdk/pull/12843/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12843&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303526
  Stats: 36 lines in 2 files changed: 31 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12843.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12843/head:pull/12843

PR: https://git.openjdk.org/jdk/pull/12843

From jjg at openjdk.org  Sat Mar  4 16:56:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sat, 4 Mar 2023 16:56:02 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite
In-Reply-To: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
Message-ID: <ZWscRdidtdBNWjMj7JbIFv-RPorWnqn_Uvgp-YNV9pQ=.f1fb1352-4e3d-44b4-9105-06eba621f34f@github.com>

On Thu, 2 Mar 2023 23:29:42 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).
> 
> The method `Name.compareTo()` looks like this:
> 
> /** An arbitrary but consistent complete order among all Names.
>  */
> public int compareTo(Name other) {
>     return other.getIndex() - this.getIndex();
> }
> 
> Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.
> 
> For example, if you apply this patch:
> 
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> @@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
>      /** An arbitrary but consistent complete order among all Names.
>       */
>      public int compareTo(Name other) {
> -        return other.getIndex() - this.getIndex();
> +        return this.getIndex() - other.getIndex();
>      }
> 
>      /** Return true if this is the empty name.
> 
> then the following tests will fail:
> ```TEST: tools/javac/8203436/T8203436b.java
> TEST: tools/javac/generics/7034019/T7034019c.java
> TEST: tools/javac/generics/7034019/T7034019d.java
> TEST: tools/javac/generics/diamond/neg/Neg21.java
> TEST: tools/javac/generics/diamond/neg/Neg22.java
> TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
> TEST: tools/javac/patterns/InferenceUnitTest.java
> TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
> TEST: tools/javac/varargs/6806876/T6806876.java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
> ==============================
> 
> The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.
> 
> It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:
> 
> /**
>  * A partial ordering between type symbols that refines the
>  * class inheritance graph.
>  *
>  * Type variables always precede other kinds of symbols.
>  */
> public final boolean precedes(TypeSymbol that, Types types) {
>     if (this == that)
>         return false;
>     if (type.hasTag(that.type.getTag())) {
>         if (type.hasTag(CLASS)) {
>             return
>                 types.rank(that.type) < types.rank(this.type) ||
>                 types.rank(that.type) == types.rank(this.type) &&
>                 that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>         } else if (type.hasTag(TYPEVAR)) {
>             return types.isSubtype(this.type, that.type);
>         }
>     }
>     return type.hasTag(TYPEVAR);
> }
> 
> If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.
> 
> An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.
> 
> Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.
> 
> When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.
> 
> So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.
> 
> That's what this patch does.

Looks OK to me, but I'll stop short of the "A" word so that someone on the javac team can review it as well.

The old code was for sure much simpler/faster, but maybe it was not called often enough for the change to be noticeable.
In a world with a String-based implementation of Name, I presume we would delegate to String.compareTo, although we might need to push the implementation to the enclosing NameTable.

`Name` is an abstract class, with two `NameImpl` implementations. While I might have suggested to test both, I guess the edits are in the common code and should not vary between the two.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java line 41:

> 39:  *  deletion without notice.</b>
> 40:  */
> 41: public abstract class Name implements javax.lang.model.element.Name, PoolConstant, Comparable<Name> {

It's disappointing that we can't easily make `javax.lang.model.element.Name` implement `Comparable` as well.

-------------

PR: https://git.openjdk.org/jdk/pull/12843

From duke at openjdk.org  Sat Mar  4 16:56:03 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 4 Mar 2023 16:56:03 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite
In-Reply-To: <ZWscRdidtdBNWjMj7JbIFv-RPorWnqn_Uvgp-YNV9pQ=.f1fb1352-4e3d-44b4-9105-06eba621f34f@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
 <ZWscRdidtdBNWjMj7JbIFv-RPorWnqn_Uvgp-YNV9pQ=.f1fb1352-4e3d-44b4-9105-06eba621f34f@github.com>
Message-ID: <R_pI6dG3sUj8i3CZfIzP5iAuEoq5JEMa6A-iBI5kDHE=.208d43c5-5ff1-43f7-b688-9267799de518@github.com>

On Fri, 3 Mar 2023 23:12:37 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Looks OK to me, but I'll stop short of the "A" word so that someone on the javac team can review it as well.

Thanks for taking a look. I'll promote from draft & we'll see what other folks think.

-------------

PR: https://git.openjdk.org/jdk/pull/12843

From archie.cobbs at gmail.com  Sun Mar  5 23:12:38 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Sun, 5 Mar 2023 17:12:38 -0600
Subject: JDK-8268622 - Performance issues in javac `Name` class
In-Reply-To: <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
Message-ID: <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>

Hi Jon,

Thanks for taking a look at the patch.

On Fri, Mar 3, 2023 at 5:07 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> I would give you inline code comments, except that it's not a PR yet.  I
> note that I generally distrust the `getMessage` for any exception for which
> the message is not formally specified in some way ... in other words, don't
> assume that `e.getMessage()` by itself is interesting.
>

 That makes sense, and is easy to fix - thanks for the suggestion.

> Is it possible to write a test for the bug fix in PoolReader?   What is an
> example of a name encoded in two different ways?
>
In any multi-byte UTF-8 sequence, the bytes after the first are supposed to
all look like 0x10xxxxxx. But the code is not checking that, so e.g., you
could have 0x11xxxxxx instead and it would encode the same character but
not match byte-for-byte. For example, ? = c3 a8, but Convert.java would
also accept c3 e8 or c3 28 for "?".

Because the Name hash tables store UTF-8 byte sequences, if the same Name
were encoded two different ways, it would get added to the hash table twice.

Another way this can happen is e.g. encoding a character as a 3-byte
sequence when the character is actually small enough to fit in a 2-byte
sequence. For example, e0 84 80 encodes character 0x0100, but it should
really be encoded as c4 80.

Thinking more about this, I think I should create a separate bug and patch
for this particular problem. So, expect a digression on that next...

Although conceptually simple, this is a significant change for a very low
> level data type. It would be worth doing more testing than just the usual
> langtools tests.  For example, if you build JDK before and after this
> change, are the generated class files the same?
>
Definitely a test worth doing.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230305/b0b096d7/attachment.htm>

From duke at openjdk.org  Sun Mar  5 23:21:57 2023
From: duke at openjdk.org (Marius Volkhart)
Date: Sun, 5 Mar 2023 23:21:57 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
Message-ID: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>

On Mon, 27 Feb 2023 12:47:03 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Tighten up reporting of string template errors (fewer messages)

src/java.base/share/classes/java/lang/template/Carriers.java line 396:

> 394: 
> 395:     /**
> 396:      * Wrapper object for carrier data. Instances types are stored in the {@code objects}

Suggestion:

     * Wrapper object for carrier data. Instance types are stored in the {@code objects}

src/java.base/share/classes/java/lang/template/StringTemplate.java line 76:

> 74:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
> 75:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
> 76:  * processor uses these lists to yield an interpolated string. the value of {@code s} will

Suggestion:

 * processor uses these lists to yield an interpolated string. The value of {@code s} will

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:11:55 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:11:55 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
Message-ID: <rZpmZXi7OSqOON9_-Z33gBv_M3nRoFL-dHqdWwPI6-o=.0350abc4-144f-49aa-bab8-b954e2bc2ec1@github.com>

On Fri, 3 Mar 2023 19:42:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 66:
> 
>> 64:  * <p>
>> 65:  * {@link FormatProcessor}  format specification uses and exceptions are the same as
>> 66:  * those of {@link Formatter}.
> 
> Suggestion:
> 
>  * The {@link FormatProcessor} format specification uses and exceptions are the same as
>  * those of {@link Formatter}.

Changing.

> src/java.base/share/classes/java/util/FormatProcessor.java line 134:
> 
>> 132:      * format string from the fragments, gathers up the values and
>> 133:      * evaluates the expression
>> 134:      * {@code new Formatter(locale).format(format, values).toString()}.
> 
> Should this be described using the "as if"... phrasing to avoid a literal requirement in the spec that is inflexible?

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 175:
> 
>> 173:      * {@link FormatProcessor#FMT} ({@code static final FormatProcessor}).
>> 174:      * <p>
>> 175:      * Other {@link FormatProcessor} can be specialized if stored as static final.
> 
> Suggestion:
> 
>      * Other {@link FormatProcessor}s can be specialized if stored as a static final.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 187:
> 
>> 185:      * @throws  IllegalFormatException
>> 186:      *          If a format specifier contains an illegal syntax, a format
>> 187:      *          specifier that is incompatible with the given arguments,
> 
> Suggestion:
> 
>      *          specifier is incompatible with the given arguments,

Existing statement is consistent with those in Formatter. Reads more correctly as is.

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:24:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:24:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <5YvuMA0QcACRyYG3hYiE9A5K2m0TB40R3OPzzAuoqRo=.27359ff9-1ce3-45df-a9bf-5674d57a333d@github.com>
Message-ID: <zVyfERYFLGsagsRz660qFFH0FzpZkVBUA1dhlVULPkM=.374fe8fc-56a1-4cc9-9419-599e23a0796f@github.com>

On Sat, 4 Mar 2023 19:34:36 GMT, Marius Volkhart <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/lang/template/Carriers.java line 396:
> 
>> 394: 
>> 395:     /**
>> 396:      * Wrapper object for carrier data. Instances types are stored in the {@code objects}
> 
> Suggestion:
> 
>      * Wrapper object for carrier data. Instance types are stored in the {@code objects}

Changing

> src/java.base/share/classes/java/lang/template/StringTemplate.java line 76:
> 
>> 74:  * produced that returns the same lists from {@link StringTemplate#fragments()} and
>> 75:  * {@link StringTemplate#values()} as shown above. The {@link StringTemplate#STR} template
>> 76:  * processor uses these lists to yield an interpolated string. the value of {@code s} will
> 
> Suggestion:
> 
>  * processor uses these lists to yield an interpolated string. The value of {@code s} will

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 14:24:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 14:24:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v42]
In-Reply-To: <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <9XP497xudeRhZKkIpxIgpbqT24eG8SCbfG6TelYtM3M=.f1ad5a76-798c-4e3d-b43b-a25a20210154@github.com>
 <LFpFtorAvnMYHexzMw6m2rfwJIF1iyO0AKWXnHXCFC8=.ab00ddf8-fa65-4f7b-ae14-71eef4ec7cdb@github.com>
Message-ID: <1o1R5JiEv0hfQDksNEHsYwPv0BmLwKlK81xeqx_0arI=.5663b84d-5273-44ee-9ab4-f28400b1441a@github.com>

On Fri, 3 Mar 2023 20:17:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Tighten up reporting of string template errors (fewer messages)
>
> src/java.base/share/classes/java/lang/template/ProcessorLinkage.java line 37:
> 
>> 35: 
>> 36: /**
>> 37:  * Policies using this additional interface have the flexibility to specialize
> 
> Since it is 'sealed' it may clarify the use to say "Builtin policies"...

Changing

> src/java.base/share/classes/java/lang/template/StringProcessor.java line 58:
> 
>> 56:     /**
>> 57:      * Constructs a {@link String} based on the template fragments and values in the
>> 58:      * supplied {@link StringTemplate} object.
> 
> Some inconsistency in the use of link/linkplain and the capitalization of stringTemplate, the instance or the type.
> (As compared to TemplateProcessor.process(stringTemplate))
> Suggestion:
> 
>      * supplied {@link StringTemplate} object.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 42:
> 
>> 40:  * {@link Formatter} specifications and values found in the {@link StringTemplate}.
>> 41:  * Unlike {@link Formatter}, {@link FormatProcessor} uses the value from the
>> 42:  * embedded expression that immediately follows, no whitespace, after the
> 
> Suggestion:
> 
>  * embedded expression that immediately follows, without whitespace, the

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 80:
> 
>> 78:  * int x = 10;
>> 79:  * int y = 20;
>> 80:  * String result = thaiFMT."%d\{x} + %d\{y} = %d\{x + y}";
> 
> The inclusion of format specifiers that yield the same results as the default (%s) may mislead developers into thinking they need the format specifier. Making the examples look more complicated than necessary.
> Can the examples, show customized output.
> 
> Suggestion:
> 
>  * String result = thaiFMT."%d{x} + %d{y} = %d{x + y}";

Changing

-------------

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Mon Mar  6 19:16:31 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Mar 2023 19:16:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v43]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_G-pacG_MK2x2hRQogujTpfZ7w5xT1Ep0ekHgs1w1-s=.fc5cf7fa-fa65-4256-aaa6-7ac036fb47ec@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 59 commits:

 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - Bring up to date
 - Merge branch 'master' into 8285932
 - ... and 49 more: https://git.openjdk.org/jdk/compare/cfb0a25a...5d79f650

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=42
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From prappo at openjdk.org  Mon Mar  6 20:22:48 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 6 Mar 2023 20:22:48 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into 8303480
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12826/files
  - new: https://git.openjdk.org/jdk/pull/12826/files/d2f4a553..87166408

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12826&range=00-01

  Stats: 13433 lines in 415 files changed: 9003 ins; 2610 del; 1820 mod
  Patch: https://git.openjdk.org/jdk/pull/12826.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12826/head:pull/12826

PR: https://git.openjdk.org/jdk/pull/12826

From jjg at openjdk.org  Mon Mar  6 20:31:18 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:31:18 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <zGeNBZ-3vU9GABEYOeUorRTJAMzyQzN-97Rx6qKisaY=.87335367-efc7-4c48-b866-de39a9d9c9e2@github.com>
 <Bzi35xfPH43Jupv65o86ErKvkPYaJdNV7cDIX7BBorc=.34e6522f-ec1e-41ee-b254-32713288bc79@github.com>
 <-U8YFFuXm_hMf-bY1AVCRauRrE-fRYRxrx_yf38ZL1A=.d50884c5-cc4b-489a-b817-828faf876c76@github.com>
 <GIf5QraCfE1MexPnWsXUMEWFPYoWpu-80I1N7bB6ffk=.728f82a3-fe8f-40d3-8dbd-c6a9fa5e031a@github.com>
Message-ID: <ZXfrODW3U49MwVjsf7erqcN1x3lsi5dyU5SSaETKruY=.616faeb3-663f-4191-8bec-8fc0c9eba48d@github.com>

On Fri, 3 Mar 2023 11:31:04 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics. As @pavelrappo points out it's a relatively common occurrence in the OpenJDK sources, though perhaps not in the public javadocs. Perhaps a bit pretentious, but mostly a terse way to say "return true if the BSM method type exactly matches X, otherwise false".
>> 
>> The broken link stems from the fact that the method I was targeting (a way to use condy for lambda proxy singletons rather than a `MethodHandle.constant`) was never integrated. We'll look at either getting that done (@briangoetz suggested the time might be ready for it) or remove this currently pointless static bootstrap specialization test.
>
>> Yes, iff means if-and-only-if and is used for extra precision in formal logic, mathematics.
> 
> I've never come across it before. With your explanations, it makes perfect sense.

I would recommend (separately) changing `iff` to the expanded form `if and only if`

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From jjg at openjdk.org  Mon Mar  6 20:36:13 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 20:36:13 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <ztCzFqlAYLpzLdZY0K_GgKPNNOvqF9FNTbDh5ZEg-lk=.3aa6a92b-a286-4760-bdc4-425f48e53a6f@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by jjg (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From lancea at openjdk.org  Mon Mar  6 20:39:17 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 6 Mar 2023 20:39:17 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <RWgaYiwcqLzeKKbnHxAAnPlwk1ndum8VkwVOnvJAbMM=.e0a4507f-dd64-41c8-89c6-70ceb8d34995@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by lancea (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From jonathan.gibbons at oracle.com  Mon Mar  6 20:46:19 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 12:46:19 -0800
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
Message-ID: <3155a848-b4b1-2dbb-a7b2-f6ee0911ac0e@oracle.com>


On 3/5/23 3:12 PM, Archie Cobbs wrote:
> Hi Jon,
>
> Thanks for taking a look at the patch.
>
> On Fri, Mar 3, 2023 at 5:07 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     I would give you inline code comments, except that it's not a PR
>     yet.? I note that I generally distrust the `getMessage` for any
>     exception for which the message is not formally specified in some
>     way ... in other words, don't assume that `e.getMessage()` by
>     itself is interesting.
>
>
> ?That makes sense, and is easy to fix - thanks for the suggestion.
>
>     Is it possible to write a test for the bug fix in PoolReader???
>     What is an example of a name encoded in two different ways?
>
> In any multi-byte UTF-8 sequence, the bytes after the first are 
> supposed to all look like 0x10xxxxxx. But the code is not checking 
> that, so e.g., you could have 0x11xxxxxx instead and it would encode 
> the same character but not match byte-for-byte. For example, ? = c3 
> a8, but Convert.java would also accept c3 e8 or c3 28 for "?".
>
> Because the Name hash tables store UTF-8 byte sequences, if the same 
> Name were encoded two different ways, it would get added to the hash 
> table twice.
>
> Another way this can happen is e.g. encoding a character as a 3-byte 
> sequence when the character is actually small enough to fit in a 
> 2-byte sequence. For example, e0 84 80 encodes character 0x0100, but 
> it should really be encoded as c4 80.
>
> Thinking more about this, I think I should create a separate bug and 
> patch for this particular problem. So, expect a digression on that next...

Thanks for all the preceding explanations, and yes, it seems you are 
addressing a different problem than just the Name abstraction.


>
>     Although conceptually simple, this is a significant change for a
>     very low level data type. It would be worth doing more testing
>     than just the usual langtools tests. For example, if you build JDK
>     before and after this change, are the generated class files the same?
>
> Definitely a test worth doing.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/83b0decb/attachment-0001.htm>

From jonathan.gibbons at oracle.com  Mon Mar  6 20:50:05 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 12:50:05 -0800
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
Message-ID: <412bda6f-13b9-e81e-5a74-b56112482d30@oracle.com>

See also this:
https://en.wikipedia.org/wiki/Unicode_equivalence

-- Jon


On 3/5/23 3:12 PM, Archie Cobbs wrote:
> Hi Jon,
>
> Thanks for taking a look at the patch.
>
> On Fri, Mar 3, 2023 at 5:07 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     I would give you inline code comments, except that it's not a PR
>     yet.? I note that I generally distrust the `getMessage` for any
>     exception for which the message is not formally specified in some
>     way ... in other words, don't assume that `e.getMessage()` by
>     itself is interesting.
>
>
> ?That makes sense, and is easy to fix - thanks for the suggestion.
>
>     Is it possible to write a test for the bug fix in PoolReader???
>     What is an example of a name encoded in two different ways?
>
> In any multi-byte UTF-8 sequence, the bytes after the first are 
> supposed to all look like 0x10xxxxxx. But the code is not checking 
> that, so e.g., you could have 0x11xxxxxx instead and it would encode 
> the same character but not match byte-for-byte. For example, ? = c3 
> a8, but Convert.java would also accept c3 e8 or c3 28 for "?".
>
> Because the Name hash tables store UTF-8 byte sequences, if the same 
> Name were encoded two different ways, it would get added to the hash 
> table twice.
>
> Another way this can happen is e.g. encoding a character as a 3-byte 
> sequence when the character is actually small enough to fit in a 
> 2-byte sequence. For example, e0 84 80 encodes character 0x0100, but 
> it should really be encoded as c4 80.
>
> Thinking more about this, I think I should create a separate bug and 
> patch for this particular problem. So, expect a digression on that next...
>
>     Although conceptually simple, this is a significant change for a
>     very low level data type. It would be worth doing more testing
>     than just the usual langtools tests. For example, if you build JDK
>     before and after this change, are the generated class files the same?
>
> Definitely a test worth doing.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/af4a588f/attachment.htm>

From rriggs at openjdk.org  Mon Mar  6 21:29:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 6 Mar 2023 21:29:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <xJn3JEoOJduXQZ9MF4uueB3KdIC4T_3roLNAWSQ8mZM=.4d80d353-a5e3-4cc4-87b3-320643f8cc36@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by rriggs (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From jonathan.gibbons at oracle.com  Mon Mar  6 23:01:14 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 15:01:14 -0800
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
Message-ID: <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>

More on changing PoolReader ... ideally, this should be tied back to 
details in JVMS, and/or the spec updated to define the expected behavior 
of the VM and javac for similar but different equivalent names.

-- Jon

On 3/5/23 3:12 PM, Archie Cobbs wrote:
> Hi Jon,
>
> Thanks for taking a look at the patch.
>
> On Fri, Mar 3, 2023 at 5:07 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     I would give you inline code comments, except that it's not a PR
>     yet.? I note that I generally distrust the `getMessage` for any
>     exception for which the message is not formally specified in some
>     way ... in other words, don't assume that `e.getMessage()` by
>     itself is interesting.
>
>
> ?That makes sense, and is easy to fix - thanks for the suggestion.
>
>     Is it possible to write a test for the bug fix in PoolReader???
>     What is an example of a name encoded in two different ways?
>
> In any multi-byte UTF-8 sequence, the bytes after the first are 
> supposed to all look like 0x10xxxxxx. But the code is not checking 
> that, so e.g., you could have 0x11xxxxxx instead and it would encode 
> the same character but not match byte-for-byte. For example, ? = c3 
> a8, but Convert.java would also accept c3 e8 or c3 28 for "?".
>
> Because the Name hash tables store UTF-8 byte sequences, if the same 
> Name were encoded two different ways, it would get added to the hash 
> table twice.
>
> Another way this can happen is e.g. encoding a character as a 3-byte 
> sequence when the character is actually small enough to fit in a 
> 2-byte sequence. For example, e0 84 80 encodes character 0x0100, but 
> it should really be encoded as c4 80.
>
> Thinking more about this, I think I should create a separate bug and 
> patch for this particular problem. So, expect a digression on that next...
>
>     Although conceptually simple, this is a significant change for a
>     very low level data type. It would be worth doing more testing
>     than just the usual langtools tests. For example, if you build JDK
>     before and after this change, are the generated class files the same?
>
> Definitely a test worth doing.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/56f332a2/attachment-0001.htm>

From archie.cobbs at gmail.com  Mon Mar  6 23:07:19 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 6 Mar 2023 16:07:19 -0700
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
 <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>
Message-ID: <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>

On Mon, Mar 6, 2023 at 4:01 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> More on changing PoolReader ... ideally, this should be tied back to
> details in JVMS, and/or the spec updated to define the expected behavior of
> the VM and javac for similar but different equivalent names.
>
Funny you should mention it :) See the PR I just filed (link
<https://github.com/openjdk/jdk/pull/12893>), quoting:

> JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does
> not allow for non-standard encodings. Instead, you'll get something like
> this:
>
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>
> So the compiler should also reject any invalid classfiles containing them.
>
-Archie
-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/b649fdd6/attachment.htm>

From duke at openjdk.org  Mon Mar  6 23:08:17 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 6 Mar 2023 23:08:17 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings
Message-ID: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>

This patch is a precursor to upcoming refactoring to address these related bugs:
* [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
* [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class

In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.

This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).

But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:

$ java Test
Error: LinkageError occurred while loading main class Test
	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test

So the compiler should also reject any invalid classfiles containing them.

This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

-------------

Commit messages:
 - Disallow non-standard UTF-8 string encodings.

Changes: https://git.openjdk.org/jdk/pull/12893/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303623
  Stats: 458 lines in 17 files changed: 374 ins; 9 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From archie.cobbs at gmail.com  Mon Mar  6 23:14:44 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 6 Mar 2023 16:14:44 -0700
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
 <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>
 <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>
Message-ID: <CANSoFxuZon8PvFHF_b23z0bm70duD9zjipaWkg=XOyS2ZheUcg@mail.gmail.com>

Actually, it appears what the JVMS allows changed (i.e., got stricter) in
classfile version 47.

Here's the relevant hotspot code.
<https://github.com/openjdk/jdk/blob/f64ed09e9a674a38f03f1e27e56fb19d72939ba1/src/hotspot/share/utilities/utf8.cpp#L332-L392>

So the compiler should probably mirror that logic.

-Archie

On Mon, Mar 6, 2023 at 4:07 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Mon, Mar 6, 2023 at 4:01 PM Jonathan Gibbons <
> jonathan.gibbons at oracle.com> wrote:
>
>> More on changing PoolReader ... ideally, this should be tied back to
>> details in JVMS, and/or the spec updated to define the expected behavior of
>> the VM and javac for similar but different equivalent names.
>>
> Funny you should mention it :) See the PR I just filed (link
> <https://github.com/openjdk/jdk/pull/12893>), quoting:
>
>> JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does
>> not allow for non-standard encodings. Instead, you'll get something like
>> this:
>>
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>>
>> So the compiler should also reject any invalid classfiles containing them.
>>
> -Archie
> --
> Archie L. Cobbs
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/aacdeb52/attachment.htm>

From jonathan.gibbons at oracle.com  Mon Mar  6 23:15:08 2023
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 6 Mar 2023 15:15:08 -0800
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
 <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>
 <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>
Message-ID: <639276cb-87aa-d78c-7d97-b6b924872963@oracle.com>

Yes, as a general rule, the compiler and runtime should be mutually 
consistent.

This discussion probably also applies to javac reading names in source 
files and having those names propagate to class files.

-- Jon


On 3/6/23 3:07 PM, Archie Cobbs wrote:
> On Mon, Mar 6, 2023 at 4:01 PM Jonathan Gibbons 
> <jonathan.gibbons at oracle.com> wrote:
>
>     More on changing PoolReader ... ideally, this should be tied back
>     to details in JVMS, and/or the spec updated to define the expected
>     behavior of the VM and javac for similar but different equivalent
>     names.
>
> Funny you should mention it :) See the PR I just filed (link 
> <https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/12893__;!!ACWV5N9M2RV99hQ!ISI9uy1X6lKTbsrTk8a0Y6vFyGFZc8MWhHsrhGsOhQycEB5EfevTYiXZlgu7BiSlFArVXPkX-JOfD6APKlBPht6Yo9g$>), 
> quoting:
>
>     JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it
>     does not allow for non-standard encodings. Instead, you'll get
>     something like this:
>
>     |$ java Test Error: LinkageError occurred while loading main class
>     Test java.lang.ClassFormatError: Illegal UTF8 string in constant
>     pool in class file Test |
>
>     So the compiler should also reject any invalid classfiles
>     containing them.
>
> -Archie
>
> -- 
> Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/4c7d5b09/attachment-0001.htm>

From darcy at openjdk.org  Tue Mar  7 00:16:12 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 7 Mar 2023 00:16:12 GMT
Subject: RFR: JDK-8042981: Strip type annotations in Types' utility methods
 [v2]
In-Reply-To: <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
References: <ZJlqgOUvn3O38WxHRYb9AqOtE34HS1tWpINrbxjfi5I=.d914bc42-e221-4f93-a2a4-712c997fe23c@github.com>
 <NXxHdBeoY6jAEeswG1eSyvX51SpllGufCa6_C-Dx41o=.142d5c64-6158-4d24-b98a-6834a6f7a204@github.com>
Message-ID: <Q2SaBfbZ4kAI8l4XBLB0s8XD4pL35_-6yci4PiwopEU=.853f29f8-781e-446f-9e5b-90f527a45d54@github.com>

On Sun, 26 Jun 2022 22:52:43 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Early review for JDK-8042981: "Strip type annotations in Types' utility methods". I work more often in the Element world rather than the Type word of the annotation processing APIs.
>> 
>> The type annotations on primitive types are *not* cleared by the existing annotation clearing mechanisms. I suspect Type.Visitor is missing a case for primitive types. Someone with familiarity with javac's type modeling should take a look; thanks.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Update visitor; all langtools regression tests pass.
>  - Merge branch 'master' into JDK-8042981
>  - JDK-8042981: Strip type annotations in Types' utility methods

keep-alive

-------------

PR: https://git.openjdk.org/jdk/pull/8984

From duke at openjdk.org  Tue Mar  7 00:44:47 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 7 Mar 2023 00:44:47 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/1d17de6b..94dd3db3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=00-01

  Stats: 72 lines in 10 files changed: 23 ins; 18 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From archie.cobbs at gmail.com  Tue Mar  7 00:57:08 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Mon, 6 Mar 2023 17:57:08 -0700
Subject: [External] : Re: JDK-8268622 - Performance issues in javac `Name`
 class
In-Reply-To: <639276cb-87aa-d78c-7d97-b6b924872963@oracle.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
 <98bc2795-ce8f-21c4-3a15-ead24c103a94@oracle.com>
 <CANSoFxvrO7zG_OPDBNrhQJuMsAj3_Fo4k__xTiYDQC5+8bVQAA@mail.gmail.com>
 <639276cb-87aa-d78c-7d97-b6b924872963@oracle.com>
Message-ID: <CANSoFxvmcwv+r5m_ohe0=R9A5Drrfxkqa8dmoq3ccwR20=PzYg@mail.gmail.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Mon, Mar 6, 2023 at 4:15 PM Jonathan Gibbons <jonathan.gibbons at oracle.com>
wrote:

> Yes, as a general rule, the compiler and runtime should be mutually
> consistent.
>
I've updated the PR to check for classfile major version < 48. In that case
longer-than-necessary encodings are allowed.

> This discussion probably also applies to javac reading names in source
> files and having those names propagate to class files.
>
Agreed. Though I think we're good here because the Lexer/Scanner uses a
CharsetDecoder that detects errors on malformed input. As a simple test I
verified that StandardCharsets.UTF_8 returns "MALFORMED" on input with "?"
encoded as c3 e8.

And after the lexer step, you're going from char[] to byte[], and those
conversions are already being done correctly in the compiler code.

It's the byte[] to char[] step in which "non-standard" encodings can creep
in.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230306/74ba61c0/attachment.htm>

From ihse at openjdk.org  Tue Mar  7 11:19:08 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 7 Mar 2023 11:19:08 GMT
Subject: RFR: 8303480: Miscellaneous fixes to mostly invisible doc comments
 [v2]
In-Reply-To: <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
 <cwRZFQxyddrtPWS__nVK0l1Lu-dL3lnlR3rODiLfncA=.2f5b214e-9ae7-492a-b09a-81ef4077a26e@github.com>
Message-ID: <jtMAFBGGsxnmsPk8rzwnle3YNCoW9AMBfy69IAW5jT0=.2980eb41-64af-4b4b-8826-86f5a6ea6477@github.com>

On Mon, 6 Mar 2023 20:22:48 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
>> 
>> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
>> 
>> 
>>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>>     @@ -17084,7 +17084,7 @@
>>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>>      <div class="block"><code>readObject</code> is called to restore the state of the
>>     - (@code BasicPermission} from a stream.</div>
>>     + <code>BasicPermission</code> from a stream.</div>
>>      <dl class="notes">
>>      <dt>Parameters:</dt>
>>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
>> 
>> Notes
>> -----
>> 
>> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
>> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
>> * I will update copyright years after (and if) the fix had been approved, as required.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into 8303480
>  - Initial commit

Marked as reviewed by ihse (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From prappo at openjdk.org  Tue Mar  7 15:29:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:29:08 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers
Message-ID: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
Please review this cleanup which consists of commentary changes and code simplifications.

-------------

Commit messages:
 - Improve CompoundIterator
 - Improve Iterators.createFilterIterator
 - Fix typos and improve consistency
 - Avoid unnecessary recomputation
 - Fix typos and {@inheritDoc} that stands out

Changes: https://git.openjdk.org/jdk/pull/12904/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303755
  Stats: 51 lines in 6 files changed: 9 ins; 20 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 15:35:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 15:35:51 GMT
Subject: Integrated: 8303480: Miscellaneous fixes to mostly invisible doc
 comments
In-Reply-To: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
References: <qBda_vNvFz2TKSb8wHPWmqAcdWIC3eao_UdPQkf0jro=.280c1677-def5-4c99-97c4-6bd30c8a9183@github.com>
Message-ID: <bX8VasBimwapkC8a4jdbxSSzCrgVWVZmukOp-odUBTs=.afe4dd0d-9ed0-4cd8-8b8d-92285c7d58bc@github.com>

On Thu, 2 Mar 2023 12:03:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this superficial documentation cleanup that was triggered by unrelated analysis of doc comments in JDK API.
> 
> The only effect that this multi-area PR has on the JDK API Documentation (i.e. the observable effect on the generated HTML pages) can be summarized as follows:
> 
> 
>     diff -ur build/macosx-aarch64/images/docs-before/api/serialized-form.html build/macosx-aarch64/images/docs-after/api/serialized-form.html
>     --- build/macosx-aarch64/images/docs-before/api/serialized-form.html	2023-03-02 11:47:44
>     +++ build/macosx-aarch64/images/docs-after/api/serialized-form.html	2023-03-02 11:48:45
>     @@ -17084,7 +17084,7 @@
>                       throws <span class="exceptions"><a href="java.base/java/io/IOException.html" title="class in java.io">IOException</a>,
>      <a href="java.base/java/lang/ClassNotFoundException.html" title="class in java.lang">ClassNotFoundException</a></span></div>
>      <div class="block"><code>readObject</code> is called to restore the state of the
>     - (@code BasicPermission} from a stream.</div>
>     + <code>BasicPermission</code> from a stream.</div>
>      <dl class="notes">
>      <dt>Parameters:</dt>
>      <dd><code>s</code> - the <code>ObjectInputStream</code> from which data is read</dd>
> 
> Notes
> -----
> 
> * I'm not an expert in any of the affected areas, except for jdk.javadoc, and I was merely after misused tags. Because of that, I would appreciate reviews from experts in other areas.
> * I discovered many more issues than I included in this PR. The excluded issues seem to occur in infrequently updated third-party code (e.g. javax.xml), which I assume we shouldn't touch unless necessary.
> * I will update copyright years after (and if) the fix had been approved, as required.

This pull request has now been integrated.

Changeset: 45a616a8
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45a616a891e4a4b0e77b1f2fa040522f4a99d172
Stats:     75 lines in 39 files changed: 0 ins; 0 del; 75 mod

8303480: Miscellaneous fixes to mostly invisible doc comments

Reviewed-by: mullan, prr, cjplummer, aivanov, jjg, lancea, rriggs, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/12826

From jjg at openjdk.org  Tue Mar  7 15:47:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Mar 2023 15:47:22 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>

On Tue, 7 Mar 2023 15:20:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup which consists of commentary changes and code simplifications.

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 844:

> 842:                     return
> 843:                         thatRank < thisRank ||
> 844:                         thatRank == thisRank &&

(minor).  both before and after, the formulation is confusing and could benefit from parentheses or better indentation

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 89:

> 87:                 while (input.hasNext()) {
> 88:                     E sym = input.next();
> 89:                     assert sym != null; // otherwise, false positive EOF

javac coding style is to use the `Assert` class, not `assert` statement

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 16:13:47 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 16:13:47 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <BzcjYRClwSncW4DukXtDFQ0qcwOPUQeTol1QT0djWPM=.4b92a8ee-9a34-42dd-80ef-62f1b3eee21a@github.com>

> Please review this cleanup which consists of commentary changes and code simplifications.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into 8303755
   
   # Conflicts:
   #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
 - Improve CompoundIterator
   
   - it could be improved even further, but kept as is to retain its
     laziness
   - `remove` is deleted as it now is a default Iterator method
 - Improve Iterators.createFilterIterator
   
   Assert that the mechanics relies on iterator being filtered never
   to return null.
 - Fix typos and improve consistency
 - Avoid unnecessary recomputation
 - Fix typos and {@inheritDoc} that stands out

-------------

Changes: https://git.openjdk.org/jdk/pull/12904/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=01
  Stats: 49 lines in 6 files changed: 9 ins; 20 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 16:41:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 16:41:14 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
In-Reply-To: <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
Message-ID: <wcjLPw8MqaZpNp6EHB9LKDyBXzCw2kxgLj8TUmpy_GA=.3021074c-c658-43c5-9883-34157194cb6a@github.com>

On Tue, 7 Mar 2023 15:44:28 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8303755
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>  - Improve CompoundIterator
>>    
>>    - it could be improved even further, but kept as is to retain its
>>      laziness
>>    - `remove` is deleted as it now is a default Iterator method
>>  - Improve Iterators.createFilterIterator
>>    
>>    Assert that the mechanics relies on iterator being filtered never
>>    to return null.
>>  - Fix typos and improve consistency
>>  - Avoid unnecessary recomputation
>>  - Fix typos and {@inheritDoc} that stands out
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 89:
> 
>> 87:                 while (input.hasNext()) {
>> 88:                     E sym = input.next();
>> 89:                     assert sym != null; // otherwise, false positive EOF
> 
> javac coding style is to use the `Assert` class, not `assert` statement

If you are considering an unconditional null check here, then you might want to consider a dedicated EOF flag instead. Alternatively, I can remove the `assert`, but leave the comment; for the next reader.

It's probably the case that iteration elements are never `null`. If they were `null`, we would either notice false positive EOF or see NPEs thrown from predicates.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 17:28:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 17:28:03 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
In-Reply-To: <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
Message-ID: <25vofmq8AmDTmtcZKxwbMj1ftxhqLYB7pAT95dE7AZs=.d1ea6867-0df5-4f8c-9f4b-05d7dd52756c@github.com>

On Tue, 7 Mar 2023 15:42:01 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into 8303755
>>    
>>    # Conflicts:
>>    #	src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java
>>  - Improve CompoundIterator
>>    
>>    - it could be improved even further, but kept as is to retain its
>>      laziness
>>    - `remove` is deleted as it now is a default Iterator method
>>  - Improve Iterators.createFilterIterator
>>    
>>    Assert that the mechanics relies on iterator being filtered never
>>    to return null.
>>  - Fix typos and improve consistency
>>  - Avoid unnecessary recomputation
>>  - Fix typos and {@inheritDoc} that stands out
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 844:
> 
>> 842:                     return
>> 843:                         thatRank < thisRank ||
>> 844:                         thatRank == thisRank &&
> 
> (minor).  both before and after, the formulation is confusing and could benefit from parentheses or better indentation

Would it be even more clear if we introduced an explicit if-else?

    int thatRank = types.rank(that.type);
    int thisRank = types.rank(this.type);
    if (thatRank < thisRank) {
        return true;
    } else if (thatRank == thisRank) {
        return that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
    }

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From jjg at openjdk.org  Tue Mar  7 19:29:02 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Mar 2023 19:29:02 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
In-Reply-To: <25vofmq8AmDTmtcZKxwbMj1ftxhqLYB7pAT95dE7AZs=.d1ea6867-0df5-4f8c-9f4b-05d7dd52756c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
 <25vofmq8AmDTmtcZKxwbMj1ftxhqLYB7pAT95dE7AZs=.d1ea6867-0df5-4f8c-9f4b-05d7dd52756c@github.com>
Message-ID: <1WAS8e5R3ZIrBO9J6lXfe-tMyezzkQlXVagelxtBL0I=.3ba86f4c-87e5-4ecf-949c-63d1fef46c4c@github.com>

On Tue, 7 Mar 2023 17:24:43 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Symbol.java line 844:
>> 
>>> 842:                     return
>>> 843:                         thatRank < thisRank ||
>>> 844:                         thatRank == thisRank &&
>> 
>> (minor).  both before and after, the formulation is confusing and could benefit from parentheses or better indentation
>
> Would it be even more clear if we introduced an explicit if-else?
> 
>     int thatRank = types.rank(that.type);
>     int thisRank = types.rank(this.type);
>     if (thatRank < thisRank) {
>         return true;
>     } else if (thatRank == thisRank) {
>         return that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>     }

IMO, that's not an improvement.

Generally, style guides suggest to break before binary operators, so I'd suggest one of

int thatRank = types.rank(that.type);
int thisRank = types.rank(this.type);
return thatRank < thisRank
    || (thatRank == thisRank
        && that.getQualifiedName().compareTo(this.getQualifiedName()) < 0);


But this is now down to a more subjective opinion.   Either way is OK.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From jjg at openjdk.org  Tue Mar  7 19:37:34 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 7 Mar 2023 19:37:34 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v2]
In-Reply-To: <wcjLPw8MqaZpNp6EHB9LKDyBXzCw2kxgLj8TUmpy_GA=.3021074c-c658-43c5-9883-34157194cb6a@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
 <wcjLPw8MqaZpNp6EHB9LKDyBXzCw2kxgLj8TUmpy_GA=.3021074c-c658-43c5-9883-34157194cb6a@github.com>
Message-ID: <2WeuOwvMoM8RtgRngCuKbgxGXXnxvDPJ9xX9OaKCz0k=.0619289b-e090-4c84-a83d-efccd332817d@github.com>

On Tue, 7 Mar 2023 16:37:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 89:
>> 
>>> 87:                 while (input.hasNext()) {
>>> 88:                     E sym = input.next();
>>> 89:                     assert sym != null; // otherwise, false positive EOF
>> 
>> javac coding style is to use the `Assert` class, not `assert` statement
>
> If you are considering an unconditional null check here, then you might want to consider a dedicated EOF flag instead. Alternatively, I can remove the `assert`, but leave the comment; for the next reader.
> 
> It's probably the case that iteration elements are never `null`. If they were `null`, we would either notice false positive EOF or see NPEs thrown from predicates.

You were the one to add the `assert` ;-) 
I just made a statement that overall, the coding style in javac has been to use `Assert` instead of `assert`, at least in those cases where it is appropriate to make an assertion.
Looking at the code in more detail, it's not clear to me that either an assertion or a comment (here) is required. If you want a comment, I'd suggest a more declarative comment on the class itself.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 19:52:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 19:52:12 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>

> Please review this cleanup which consists of commentary changes and code simplifications.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Respond to feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12904/files
  - new: https://git.openjdk.org/jdk/pull/12904/files/6515bf76..140afc8a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=01-02

  Stats: 6 lines in 2 files changed: 1 ins; 2 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Tue Mar  7 19:52:14 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 7 Mar 2023 19:52:14 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <1WAS8e5R3ZIrBO9J6lXfe-tMyezzkQlXVagelxtBL0I=.3ba86f4c-87e5-4ecf-949c-63d1fef46c4c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <Q19Udb1CIhBs09FxNgsiozfIkaEbyJbdNJQl7zZOTXE=.77b74a2a-7081-4389-8ba2-b6d75e002d76@github.com>
 <25vofmq8AmDTmtcZKxwbMj1ftxhqLYB7pAT95dE7AZs=.d1ea6867-0df5-4f8c-9f4b-05d7dd52756c@github.com>
 <1WAS8e5R3ZIrBO9J6lXfe-tMyezzkQlXVagelxtBL0I=.3ba86f4c-87e5-4ecf-949c-63d1fef46c4c@github.com>
Message-ID: <OBC6z5peCMjE2s3h_-QZrqmkrGRK-jit1ixFTAX3_J0=.1b2badc6-2274-4745-9895-b81773c45426@github.com>

On Tue, 7 Mar 2023 19:26:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Would it be even more clear if we introduced an explicit if-else?
>> 
>>     int thatRank = types.rank(that.type);
>>     int thisRank = types.rank(this.type);
>>     if (thatRank < thisRank) {
>>         return true;
>>     } else if (thatRank == thisRank) {
>>         return that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>>     }
>
> IMO, that's not an improvement.
> 
> Generally, style guides suggest to break before binary operators, so I'd suggest one of
> 
> int thatRank = types.rank(that.type);
> int thisRank = types.rank(this.type);
> return thatRank < thisRank
>     || (thatRank == thisRank
>         && that.getQualifiedName().compareTo(this.getQualifiedName()) < 0);
> 
> 
> But this is now down to a more subjective opinion.   Either way is OK.

Addressed in 140afc8.

>> If you are considering an unconditional null check here, then you might want to consider a dedicated EOF flag instead. Alternatively, I can remove the `assert`, but leave the comment; for the next reader.
>> 
>> It's probably the case that iteration elements are never `null`. If they were `null`, we would either notice false positive EOF or see NPEs thrown from predicates.
>
> You were the one to add the `assert` ;-) 
> I just made a statement that overall, the coding style in javac has been to use `Assert` instead of `assert`, at least in those cases where it is appropriate to make an assertion.
> Looking at the code in more detail, it's not clear to me that either an assertion or a comment (here) is required. If you want a comment, I'd suggest a more declarative comment on the class itself.

Addressed in 140afc8.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From ljnelson at gmail.com  Tue Mar  7 23:52:47 2023
From: ljnelson at gmail.com (Laird Nelson)
Date: Tue, 7 Mar 2023 15:52:47 -0800
Subject: Can a @Target-less (runtime-retained) annotation be applied on a type
 parameter declaration?
Message-ID: <CAHNdxuko1D824Mbg4AmyXBRX0=1Uw50itnx6Sh04QhOAjauEUw@mail.gmail.com>

Using Java 19:

@Retention(RetentionPolicy.RUNTIME)
public @interface A {}

public class B<@A C> {}

Why does javac say that A is "not applicable in this type context"?  (I
understand that things have changed here in various versions of the JLS and
related @Target javadocs over the years so I'm probably misreading
something.)

(Originally asked on StackOverflow with more detail:
https://stackoverflow.com/questions/75667924/a-target-less-annotation-cannot-be-applied-to-a-type-parameter-declaration-in-j

Thanks,
Laird
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230307/de8a3937/attachment.htm>

From cushon at google.com  Wed Mar  8 00:06:46 2023
From: cushon at google.com (Liam Miller-Cushon)
Date: Tue, 7 Mar 2023 16:06:46 -0800
Subject: Can a @Target-less (runtime-retained) annotation be applied on a
 type parameter declaration?
In-Reply-To: <CAHNdxuko1D824Mbg4AmyXBRX0=1Uw50itnx6Sh04QhOAjauEUw@mail.gmail.com>
References: <CAHNdxuko1D824Mbg4AmyXBRX0=1Uw50itnx6Sh04QhOAjauEUw@mail.gmail.com>
Message-ID: <CAL4QsgsMpYWdSSa1ujgUPvQrXAG0pQe3tAbnzW_2KA+NkDyvkg@mail.gmail.com>

Hi Laird,

Nice find. I'm curious whether anyone on the list is remembering details
I'm not, but this looks like a bug to me too.

I went ahead and filed: https://bugs.openjdk.org/browse/JDK-8303784

On Tue, Mar 7, 2023 at 3:53?PM Laird Nelson <ljnelson at gmail.com> wrote:

> Using Java 19:
>
> @Retention(RetentionPolicy.RUNTIME)
> public @interface A {}
>
> public class B<@A C> {}
>
> Why does javac say that A is "not applicable in this type context"?  (I
> understand that things have changed here in various versions of the JLS and
> related @Target javadocs over the years so I'm probably misreading
> something.)
>
> (Originally asked on StackOverflow with more detail:
> https://stackoverflow.com/questions/75667924/a-target-less-annotation-cannot-be-applied-to-a-type-parameter-declaration-in-j
>
> Thanks,
> Laird
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230307/4eec26d5/attachment-0001.htm>

From cushon at openjdk.org  Wed Mar  8 00:16:06 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Wed, 8 Mar 2023 00:16:06 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations
Message-ID: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>

Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.

`@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

-------------

Commit messages:
 - 8303784: no- at Target annotations should be applicable to type parameter declarations

Changes: https://git.openjdk.org/jdk/pull/12914/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303784
  Stats: 43 lines in 2 files changed: 42 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12914/head:pull/12914

PR: https://git.openjdk.org/jdk/pull/12914

From archie.cobbs at gmail.com  Wed Mar  8 05:00:12 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Tue, 7 Mar 2023 22:00:12 -0700
Subject: JDK-8268622 - Performance issues in javac `Name` class
In-Reply-To: <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
References: <CANSoFxsO3FTZ5MXSRXcTAPMUgwJThoJ7XVTkXbkv12i=BE6ZFg@mail.gmail.com>
 <CANSoFxtmVgjsbM26J79WCucq81UGE-aEE_wPckjEPmztQE4pWg@mail.gmail.com>
 <CANSoFxt-3g+QmhNLk0W3e2SBqDPxjjbqRoB06x7=Z4vQnW4Axg@mail.gmail.com>
 <6d651d73-2df5-af4a-5738-bb6e7a705614@oracle.com>
 <CANSoFxv+uqaMuZUCKjnFzZ_vWw5XaUAKjcT9NrjR3KFw8-_4xA@mail.gmail.com>
Message-ID: <CANSoFxtTDBeJsdkN_4Kkf5PeK2bSkP=kKwEWKbdtar3O3S-=MA@mail.gmail.com>

On Sun, Mar 5, 2023 at 4:12?PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

>
> Although conceptually simple, this is a significant change for a very low
>> level data type. It would be worth doing more testing than just the usual
>> langtools tests.  For example, if you build JDK before and after this
>> change, are the generated class files the same?
>>
> Definitely a test worth doing.
>

Just following up on the above question... I did run this test and there
was no difference in the generated bytecode.

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230307/d3dcef0d/attachment.htm>

From jlahoda at openjdk.org  Wed Mar  8 08:46:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 8 Mar 2023 08:46:45 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
Message-ID: <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>

On Tue, 7 Mar 2023 19:52:12 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this cleanup which consists of commentary changes and code simplifications.
>
> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to feedback

Overall, looks fine to me. I've left some inline comments in Iterators.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 47:

> 45:     }
> 46: 
> 47:     private static final class CompoundIterator<I, O> implements Iterator<O> {

Nit: why final? Seems quite unnecessary for a private class?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 68:

> 66:         @Override
> 67:         public O next() {
> 68:             if (!hasNext()) {

I was looking into the history, and the reason for the current code is JDK-8167070 (performance). So, I'd suggest to try how this new code performs. The pre-JDK-8167070 did two calls to nested Iterator's hasNext for each call to hasNext (so for deeper hierarchies, the number of invocations grew very fast), while the code here only does one, so it quite probably may be OK.

I wonder if it is time to write a (unit) test for this class?

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 83:

> 81:     }
> 82: 
> 83:     // Iterator is assumed to never return null from next()

Not sure about this comment - it seems to explain what is wrong in the code that is removed?

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:08:10 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:08:10 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
Message-ID: <XQ_twDRBPSvs-2UMrddRhei8S_0kr7UWCTnpXKjMCfQ=.9ab07d82-fc0d-4aac-af21-5c13c0876ce0@github.com>

On Wed, 8 Mar 2023 08:37:54 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to feedback
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 83:
> 
>> 81:     }
>> 82: 
>> 83:     // Iterator is assumed to never return null from next()
> 
> Not sure about this comment - it seems to explain what is wrong in the code that is removed?

It's a coincidence: it just happens so that the removed code also implements Iterator.next() by returning null unconditionally. But that comment and the removed code are unrelated.

That comment captures the fact that the filter iterator _below_ that comment relies on the input iterator never to return null from input.next().

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:18:28 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:18:28 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
Message-ID: <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>

On Wed, 8 Mar 2023 08:35:27 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to feedback
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 68:
> 
>> 66:         @Override
>> 67:         public O next() {
>> 68:             if (!hasNext()) {
> 
> I was looking into the history, and the reason for the current code is JDK-8167070 (performance). So, I'd suggest to try how this new code performs. The pre-JDK-8167070 did two calls to nested Iterator's hasNext for each call to hasNext (so for deeper hierarchies, the number of invocations grew very fast), while the code here only does one, so it quite probably may be OK.
> 
> I wonder if it is time to write a (unit) test for this class?

When I saw a _custom_ empty iterator, my first reaction was to ask myself why it was needed when Collections.emptyIterator had been long available. So yes, I also saw JDK-8167070.

I think, I was careful enough to preserve the good behavior and remove the bad behavior as well as unneeded code. When developing this PR, I used throwaway unit tests to satisfy myself that the iterator behaves as expected. I'm not sure that we need to integrate those tests. But if we do, then please suggest how it should look like, infrastructure-wise that is.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:25:51 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:25:51 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v4]
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <KcXdZbrJwWf4rhReln71XK60EPheZ7zNlDXibXUVYS8=.366e7d80-840a-47a9-ab28-267b66af5e5e@github.com>

> Please review this cleanup which consists of commentary changes and code simplifications.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Clarify an iterator comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12904/files
  - new: https://git.openjdk.org/jdk/pull/12904/files/140afc8a..cf908193

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:25:55 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:25:55 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <XQ_twDRBPSvs-2UMrddRhei8S_0kr7UWCTnpXKjMCfQ=.9ab07d82-fc0d-4aac-af21-5c13c0876ce0@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
 <XQ_twDRBPSvs-2UMrddRhei8S_0kr7UWCTnpXKjMCfQ=.9ab07d82-fc0d-4aac-af21-5c13c0876ce0@github.com>
Message-ID: <4G4sNEA3SOSeSq8tFk4b5mEmi_M0crkV3ObdrTkvZsk=.3b696534-7936-4c78-9f25-5fc33a872327@github.com>

On Wed, 8 Mar 2023 10:05:03 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 83:
>> 
>>> 81:     }
>>> 82: 
>>> 83:     // Iterator is assumed to never return null from next()
>> 
>> Not sure about this comment - it seems to explain what is wrong in the code that is removed?
>
> It's a coincidence: it just happens so that the removed code also implements Iterator.next() by returning null unconditionally. But that comment and the removed code are unrelated.
> 
> That comment captures the fact that the filter iterator _below_ that comment relies on the input iterator never to return null from input.next().

I clarified that comment in cf90819.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:31:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:31:02 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v5]
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <P24Ph6RSwGwHaFZYLY7e6nM3oUfXqyx0jFK-bk1QPD8=.e5e1f65e-f919-4a00-a22d-3b84e45aea2e@github.com>

> Please review this cleanup which consists of commentary changes and code simplifications.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Revert (unneeded) final on CompoundIterator

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12904/files
  - new: https://git.openjdk.org/jdk/pull/12904/files/cf908193..6cda4b37

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 10:31:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 10:31:07 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
Message-ID: <mkTXvzGgS0fyRkqjs22Y1r8TFYbUAuXrFcyxyTKdrjo=.2cd502b5-632f-4fc0-8fcf-c81d1f6df774@github.com>

On Wed, 8 Mar 2023 08:12:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to feedback
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 47:
> 
>> 45:     }
>> 46: 
>> 47:     private static final class CompoundIterator<I, O> implements Iterator<O> {
> 
> Nit: why final? Seems quite unnecessary for a private class?

Reverted in 6cda4b3.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Wed Mar  8 13:08:44 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 8 Mar 2023 13:08:44 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v6]
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>

> Please review this cleanup which consists of commentary changes and code simplifications.

Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:

 - Drop recomputation improvements
   
   This reverts e18c0444cbe9f325d7122b97531869d2b8fedc56. Both `rank`
   and `supertype` are _cached_ anyway, so the performance is not
   a concern here. As for readability, while it's not really better,
   it stands out from the rest of the file where everything is
   recomputed on demand rather than cached and reused.
   
   However, this adds clarifying parentheses for `rank` in `precedes`.
 - Repair botched merge
   
   6515bf762a0ffb4a8686e07ae37611507cf2b1be

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12904/files
  - new: https://git.openjdk.org/jdk/pull/12904/files/6cda4b37..fb550f7f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12904&range=04-05

  Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12904.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12904/head:pull/12904

PR: https://git.openjdk.org/jdk/pull/12904

From mcimadamore at openjdk.org  Wed Mar  8 14:08:15 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Mar 2023 14:08:15 GMT
Subject: RFR: 8303820: Simplify type metadata
Message-ID: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>

This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).

While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.

The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.

This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).

A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.

The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).

-------------

Commit messages:
 - Add duplicate check on addMetadata
 - Add more javadoc
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/12924/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12924&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303820
  Stats: 398 lines in 8 files changed: 75 ins; 252 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/12924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12924/head:pull/12924

PR: https://git.openjdk.org/jdk/pull/12924

From mcimadamore at openjdk.org  Wed Mar  8 14:32:37 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Mar 2023 14:32:37 GMT
Subject: RFR: 8303820: Simplify type metadata [v2]
In-Reply-To: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
Message-ID: <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>

> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
> 
> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
> 
> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
> 
> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
> 
> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
> 
> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Further simplify code

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12924/files
  - new: https://git.openjdk.org/jdk/pull/12924/files/77a83a06..1083a70b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12924&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12924&range=00-01

  Stats: 26 lines in 3 files changed: 2 ins; 13 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/12924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12924/head:pull/12924

PR: https://git.openjdk.org/jdk/pull/12924

From vromero at openjdk.org  Wed Mar  8 15:50:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 8 Mar 2023 15:50:17 GMT
Subject: RFR: 8303820: Simplify type metadata [v2]
In-Reply-To: <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
 <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
Message-ID: <qK1ZnRsP96gFqIWJCLULhH79KuLe5a90ydsyax-ncm8=.f9f03d6c-9494-4daa-9d4d-5ec6827bf24d@github.com>

On Wed, 8 Mar 2023 14:32:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
>> 
>> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
>> 
>> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
>> 
>> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
>> 
>> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
>> 
>> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further simplify code

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 325:

> 323:      *  and with given constant value
> 324:      */
> 325:     public Type constType(Object constValue) {

so now any type can have a constant value? shouldn't this be restricted to primitives and Strings?

-------------

PR: https://git.openjdk.org/jdk/pull/12924

From mcimadamore at openjdk.org  Wed Mar  8 16:11:57 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Mar 2023 16:11:57 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v6]
In-Reply-To: <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
Message-ID: <5J7u3EF52_lV9Ji8jLC4QM3pdUb00_N0H4WH8mSDRk8=.166da63a-a9d5-49df-8697-8242a5a3e1d9@github.com>

On Wed, 8 Mar 2023 13:08:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this cleanup which consists of commentary changes and code simplifications.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Drop recomputation improvements
>    
>    This reverts e18c0444cbe9f325d7122b97531869d2b8fedc56. Both `rank`
>    and `supertype` are _cached_ anyway, so the performance is not
>    a concern here. As for readability, while it's not really better,
>    it stands out from the rest of the file where everything is
>    recomputed on demand rather than cached and reused.
>    
>    However, this adds clarifying parentheses for `rank` in `precedes`.
>  - Repair botched merge
>    
>    6515bf762a0ffb4a8686e07ae37611507cf2b1be

Generally it looks good, however the PR does two rather different things. One is to fix some typos and minor stylistic issues in the code (e.g. lack of parenthesized expression). The changes on `Iterators` are a bit more delicate as already outlined in the review - and should, in principle be benchmarked before/after to make sure no performance regression is introduced. For these reasons, it would be perhaps cleaner if this PR was split into two parts.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From vromero at openjdk.org  Wed Mar  8 16:17:05 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 8 Mar 2023 16:17:05 GMT
Subject: RFR: 8303820: Simplify type metadata [v2]
In-Reply-To: <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
 <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
Message-ID: <z8fHzQ4aTD7LPSEc0EKkR_U1cFpvGi9LLYpwZn4Tqp0=.d4586766-19c2-42d7-b473-c42663f3ee4a@github.com>

On Wed, 8 Mar 2023 14:32:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
>> 
>> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
>> 
>> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
>> 
>> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
>> 
>> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
>> 
>> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further simplify code

nice patch, nice simplification, just added a question

-------------

PR: https://git.openjdk.org/jdk/pull/12924

From jlahoda at openjdk.org  Wed Mar  8 17:08:34 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 8 Mar 2023 17:08:34 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
 <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>
Message-ID: <us2754fcWMfPeJRY4FJQF8vZQj8SV51TwEYl0r7J1uE=.456d780a-e399-4beb-9690-ad4c5502676e@github.com>

On Wed, 8 Mar 2023 10:14:21 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Iterators.java line 68:
>> 
>>> 66:         @Override
>>> 67:         public O next() {
>>> 68:             if (!hasNext()) {
>> 
>> I was looking into the history, and the reason for the current code is JDK-8167070 (performance). So, I'd suggest to try how this new code performs. The pre-JDK-8167070 did two calls to nested Iterator's hasNext for each call to hasNext (so for deeper hierarchies, the number of invocations grew very fast), while the code here only does one, so it quite probably may be OK.
>> 
>> I wonder if it is time to write a (unit) test for this class?
>
> When I saw a _custom_ empty iterator, my first reaction was to ask myself why it was needed when Collections.emptyIterator had been long available. So yes, I also saw JDK-8167070.
> 
> I think, I was careful enough to preserve the good behavior and remove the bad behavior as well as unneeded code. When developing this PR, I used throwaway unit tests to satisfy myself that the iterator behaves as expected. I'm not sure that we need to integrate those tests. But if we do, then please suggest how it should look like, infrastructure-wise that is.

A test could be something like this:

/*
 * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
 * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
 *
 * This code is free software; you can redistribute it and/or modify it
 * under the terms of the GNU General Public License version 2 only, as
 * published by the Free Software Foundation.
 *
 * This code is distributed in the hope that it will be useful, but WITHOUT
 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
 * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
 * version 2 for more details (a copy is included in the LICENSE file that
 * accompanied this code).
 *
 * You should have received a copy of the GNU General Public License version
 * 2 along with this work; if not, write to the Free Software Foundation,
 * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
 *
 * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
 * or visit www.oracle.com if you need additional information or have any
 * questions.
 */

/**
 * @test
 * @bug 8303755
 * @summary Verify that Iterators method work as expected
 * @modules jdk.compiler/com.sun.tools.javac.util
 * @run junit IteratorsTest
 */

import com.sun.tools.javac.util.Iterators;
import java.util.Iterator;
import java.util.List;
import java.util.function.Function;
import org.junit.jupiter.api.*;

public class IteratorsTest {

    @Test
    public void compoundIterator() {
        TestConverter<TestIterator<String>, String> c = new TestConverter<>(it -> it);
        TestIterator<String> test1 = new TestIterator<>(List.of("1").iterator());
        TestIterator<String> test2 = new TestIterator<>(List.of("2").iterator());
        Iterator<String> compound = Iterators.createCompoundIterator(List.of(test1, test2), c);

        //nothing should be called before the hasNext or next is called:
        assertMaxCalls(c, 0);
        assertMaxCalls(test1, 0, 0);
        assertMaxCalls(test2, 0, 0);

        //when hasNext is called, should invoke the hasNext delegate once:
        Assertions.assertTrue(compound.hasNext());

        assertMaxCalls(c, 1);
        assertMaxCalls(test1, 1, 0);
        assertMaxCalls(test2, 0, 0);

        Assertions.assertTrue(compound.hasNext());

        assertMaxCalls(c, 0);
        assertMaxCalls(test1, 1, 0);
        assertMaxCalls(test2, 0, 0);

        //next may invoke hasNext once:
        Assertions.assertEquals("1", compound.next());

        assertMaxCalls(c, 0);
        assertMaxCalls(test1, 1, 1);
        assertMaxCalls(test2, 0, 0);
    }

    private void assertMaxCalls(TestIterator<?> test, int maxExpectedHasNextCalls, int maxExpectedNextCalls) {
        if (test.hasNextCalls > maxExpectedHasNextCalls) {
            Assertions.fail("too many hasNext invocations: " + test.hasNextCalls +
                            ", expected: " + maxExpectedHasNextCalls);
        }
        test.hasNextCalls = 0;
        if (test.nextCalls > maxExpectedNextCalls) {
            Assertions.fail("too many next invocations: " + test.nextCalls +
                            ", expected: " + maxExpectedNextCalls);
        }
        test.nextCalls = 0;
    }

    private void assertMaxCalls(TestConverter<?, ?> test, int maxExpectedApplyCalls) {
        if (test.applyCalls > maxExpectedApplyCalls) {
            Assertions.fail("too many apply invocations: " + test.applyCalls +
                            ", expected: " + maxExpectedApplyCalls);
        }
        test.applyCalls = 0;
    }

    class TestIterator<T> implements Iterator<T> {
        int hasNextCalls;
        int nextCalls;
        final Iterator<T> delegate;

        public TestIterator(Iterator<T> delegate) {
            this.delegate = delegate;
        }

        @Override
        public boolean hasNext() {
            hasNextCalls++;
            return delegate.hasNext();
        }

        @Override
        public T next() {
            nextCalls++;
            return delegate.next();
        }
    }
    class TestConverter<I, O>  implements Function<I, Iterator<O>> {
        int applyCalls;
        final Function<I, Iterator<O>> delegate;

        public TestConverter(Function<I, Iterator<O>> delegate) {
            this.delegate = delegate;
        }

        @Override
        public Iterator<O> apply(I t) {
            applyCalls++;
            return delegate.apply(t);
        }
    }
}


I might be able to improve it later, if needed.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From alex.buckley at oracle.com  Wed Mar  8 18:00:14 2023
From: alex.buckley at oracle.com (Alex Buckley)
Date: Wed, 8 Mar 2023 10:00:14 -0800
Subject: Can a @Target-less (runtime-retained) annotation be applied on a
 type parameter declaration?
In-Reply-To: <CAL4QsgsMpYWdSSa1ujgUPvQrXAG0pQe3tAbnzW_2KA+NkDyvkg@mail.gmail.com>
References: <CAHNdxuko1D824Mbg4AmyXBRX0=1Uw50itnx6Sh04QhOAjauEUw@mail.gmail.com>
 <CAL4QsgsMpYWdSSa1ujgUPvQrXAG0pQe3tAbnzW_2KA+NkDyvkg@mail.gmail.com>
Message-ID: <d1ae21fa-60dd-bd0f-96ef-37ae243127db@oracle.com>

Thanks Laird and Liam.

In Java 19, this is a javac bug, because JLS19 is clear that a 
@Target-less annotation can be applied to a type parameter declaration:

"If an annotation of type java.lang.annotation.Target is not present on 
the declaration of an annotation interface A, then A is applicable in 
all declaration contexts and in no type contexts."

- 
https://docs.oracle.com/javase/specs/jls/se19/html/jls-9.html#jls-9.6.4.1-400


As Liam implies, there has been some shimmer in this rule. When type 
annotations were introduced in Java 8, an @Target-less annotation could 
not be applied to a type parameter declaration, but this changed in Java 
14. Compare JLS13 with JLS14:

- 
https://docs.oracle.com/javase/specs/jls/se13/html/jls-9.html#jls-9.6.4.1-400

- 
https://docs.oracle.com/javase/specs/jls/se14/html/jls-9.html#jls-9.6.4.1-400

Alex

On 3/7/2023 4:06 PM, Liam Miller-Cushon wrote:
> Hi Laird,
> 
> Nice find. I'm curious whether anyone on the list is remembering details 
> I'm not, but this looks like a bug to me too.
> 
> I went ahead and filed: https://bugs.openjdk.org/browse/JDK-8303784 
> <https://bugs.openjdk.org/browse/JDK-8303784>
> 
> On Tue, Mar 7, 2023 at 3:53?PM Laird Nelson <ljnelson at gmail.com 
> <mailto:ljnelson at gmail.com>> wrote:
> 
>     Using Java 19:
> 
>     @Retention(RetentionPolicy.RUNTIME)
>     public @interface A {}
> 
>     public class B<@A C> {}
> 
>     Why does javac say that A is "not applicable in this type context"? 
>     (I understand that things have changed?here in various versions of
>     the JLS and related?@Target javadocs over the years so I'm probably
>     misreading something.)
> 
>     (Originally asked on StackOverflow with more detail:
>     https://stackoverflow.com/questions/75667924/a-target-less-annotation-cannot-be-applied-to-a-type-parameter-declaration-in-j <https://stackoverflow.com/questions/75667924/a-target-less-annotation-cannot-be-applied-to-a-type-parameter-declaration-in-j>
> 
>     Thanks,
>     Laird
> 

From mcimadamore at openjdk.org  Wed Mar  8 23:43:12 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 8 Mar 2023 23:43:12 GMT
Subject: RFR: 8303820: Simplify type metadata [v2]
In-Reply-To: <qK1ZnRsP96gFqIWJCLULhH79KuLe5a90ydsyax-ncm8=.f9f03d6c-9494-4daa-9d4d-5ec6827bf24d@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
 <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
 <qK1ZnRsP96gFqIWJCLULhH79KuLe5a90ydsyax-ncm8=.f9f03d6c-9494-4daa-9d4d-5ec6827bf24d@github.com>
Message-ID: <sA4kRZPkl7E09vRZy2kmv71rabc5yGEKlEhGd8UOs8k=.3a632d56-dec5-4d00-94d7-fecf53bcc124@github.com>

On Wed, 8 Mar 2023 15:47:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further simplify code
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 325:
> 
>> 323:      *  and with given constant value
>> 324:      */
>> 325:     public Type constType(Object constValue) {
> 
> so now any type can have a constant value? shouldn't this be restricted to primitives and Strings?

Yeah - not sure which way to go - in reality we have a also a couple of types which implement this method and just return `this`. Only the toplevel `Type` declaration throws. I'm happy to revert to the old ways if that is preferred - it was mostly a way not to duplicate the method body twice (but that's not a big deal).

-------------

PR: https://git.openjdk.org/jdk/pull/12924

From vromero at openjdk.org  Thu Mar  9 02:10:13 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Mar 2023 02:10:13 GMT
Subject: RFR: 8303820: Simplify type metadata [v2]
In-Reply-To: <sA4kRZPkl7E09vRZy2kmv71rabc5yGEKlEhGd8UOs8k=.3a632d56-dec5-4d00-94d7-fecf53bcc124@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
 <AhYPOSwe9Mf0HXbY5LNyVNw4I-_ro19wTxCBdW2DTIU=.2cc87d19-8933-4f60-a58e-f178ecd34497@github.com>
 <qK1ZnRsP96gFqIWJCLULhH79KuLe5a90ydsyax-ncm8=.f9f03d6c-9494-4daa-9d4d-5ec6827bf24d@github.com>
 <sA4kRZPkl7E09vRZy2kmv71rabc5yGEKlEhGd8UOs8k=.3a632d56-dec5-4d00-94d7-fecf53bcc124@github.com>
Message-ID: <YpvzjHm9Q7LRkRvAqATmz52--fUEcWNkyxJKY0RwIlc=.f6f413ce-5a34-4469-aee2-5556b418a805@github.com>

On Wed, 8 Mar 2023 23:40:20 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 325:
>> 
>>> 323:      *  and with given constant value
>>> 324:      */
>>> 325:     public Type constType(Object constValue) {
>> 
>> so now any type can have a constant value? shouldn't this be restricted to primitives and Strings?
>
> Yeah - not sure which way to go - in reality we have a also a couple of types which implement this method and just return `this`. Only the toplevel `Type` declaration throws. I'm happy to revert to the old ways if that is preferred - it was mostly a way not to duplicate the method body twice (but that's not a big deal).

I would keep the original semantics and we can relax it later if needed, but I don't have a strong preference tbh

-------------

PR: https://git.openjdk.org/jdk/pull/12924

From jlahoda at openjdk.org  Thu Mar  9 07:33:27 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 9 Mar 2023 07:33:27 GMT
Subject: Withdrawn: 8299902: Support for MarkDown javadoc in JShell
In-Reply-To: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
References: <KuNsxDHHZPIsM0BeE6Au2Bc82b5OJEbC0UREsEYNFsE=.c7467a58-b510-464d-97a9-173510a85e2f@github.com>
Message-ID: <LQU2g7E-8_iMX53uV_YErHqTmu169sQQ10dyO3-QSpg=.59b5c8cd-82ac-46a1-8c28-45366b0490b9@github.com>

On Wed, 11 Jan 2023 07:17:09 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Adding support for MarkDown javadoc in the JShell

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/11936

From prappo at openjdk.org  Thu Mar  9 09:45:36 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 09:45:36 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v6]
In-Reply-To: <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
Message-ID: <PJaCDhhAFodlk2gOzNxOFBtu_TboiY42N_gHlOuMQ6o=.a244de40-d2af-4ad1-9089-66370005a827@github.com>

On Wed, 8 Mar 2023 13:08:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this cleanup which consists of commentary changes and code simplifications.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Drop recomputation improvements
>    
>    This reverts e18c0444cbe9f325d7122b97531869d2b8fedc56. Both `rank`
>    and `supertype` are _cached_ anyway, so the performance is not
>    a concern here. As for readability, while it's not really better,
>    it stands out from the rest of the file where everything is
>    recomputed on demand rather than cached and reused.
>    
>    However, this adds clarifying parentheses for `rank` in `precedes`.
>  - Repair botched merge
>    
>    6515bf762a0ffb4a8686e07ae37611507cf2b1be

I'll split this PR in two PRs, as suggested: I'm closing this PR and will create two new PRs, for tidyness.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Thu Mar  9 09:45:37 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 09:45:37 GMT
Subject: Withdrawn: 8303755: Clean up around JavacElements.getAllMembers
In-Reply-To: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
Message-ID: <zdaf7uId9rCeMAsc0avn7lwHKeIW0fhdK2mQBBCr6Bw=.a59c02e1-2389-493e-a49d-56fe0c322102@github.com>

On Tue, 7 Mar 2023 15:20:29 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this cleanup which consists of commentary changes and code simplifications.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Thu Mar  9 10:14:19 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 10:14:19 GMT
Subject: RFR: 8303881: Mixed, minor cleanup in jdk.compiler
Message-ID: <xXbkuTLzQ41CDf1OSE9xOQG4qCw6LD0ED47DWWdy4AE=.1c846cd9-deab-486e-af16-30733df633a8@github.com>

Please review trivial changes mostly to comments.

-------------

Commit messages:
 - Extra fixes
 - Initial commit from 8303755

Changes: https://git.openjdk.org/jdk/pull/12937/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12937&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303881
  Stats: 25 lines in 8 files changed: 0 ins; 3 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/12937.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12937/head:pull/12937

PR: https://git.openjdk.org/jdk/pull/12937

From mcimadamore at openjdk.org  Thu Mar  9 10:36:41 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Mar 2023 10:36:41 GMT
Subject: RFR: 8303881: Mixed, minor cleanup in jdk.compiler
In-Reply-To: <xXbkuTLzQ41CDf1OSE9xOQG4qCw6LD0ED47DWWdy4AE=.1c846cd9-deab-486e-af16-30733df633a8@github.com>
References: <xXbkuTLzQ41CDf1OSE9xOQG4qCw6LD0ED47DWWdy4AE=.1c846cd9-deab-486e-af16-30733df633a8@github.com>
Message-ID: <8xOcu2KXm7HK8q2ZcAM7uv3m9t-Cl0XWsV13i4_sUhs=.8cab893e-c4e5-4b44-9e70-7bd3ed8888a9@github.com>

On Thu, 9 Mar 2023 10:06:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review trivial changes mostly to comments.

Thanks for taking care of this!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12937

From prappo at openjdk.org  Thu Mar  9 10:42:13 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 10:42:13 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <us2754fcWMfPeJRY4FJQF8vZQj8SV51TwEYl0r7J1uE=.456d780a-e399-4beb-9690-ad4c5502676e@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
 <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>
 <us2754fcWMfPeJRY4FJQF8vZQj8SV51TwEYl0r7J1uE=.456d780a-e399-4beb-9690-ad4c5502676e@github.com>
Message-ID: <MH_gX3a2iW_yp7itU1AO7YZ53jwSb9nXP6iO54bmPK8=.f0fb6989-ec55-4625-97f2-e019e7cee832@github.com>

On Wed, 8 Mar 2023 17:06:05 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> When I saw a _custom_ empty iterator, my first reaction was to ask myself why it was needed when Collections.emptyIterator had been long available. So yes, I also saw JDK-8167070.
>> 
>> I think, I was careful enough to preserve the good behavior and remove the bad behavior as well as unneeded code. When developing this PR, I used throwaway unit tests to satisfy myself that the iterator behaves as expected. I'm not sure that we need to integrate those tests. But if we do, then please suggest how it should look like, infrastructure-wise that is.
>
> A test could be something like this:
> 
> /*
>  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>  *
>  * This code is free software; you can redistribute it and/or modify it
>  * under the terms of the GNU General Public License version 2 only, as
>  * published by the Free Software Foundation.
>  *
>  * This code is distributed in the hope that it will be useful, but WITHOUT
>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>  * version 2 for more details (a copy is included in the LICENSE file that
>  * accompanied this code).
>  *
>  * You should have received a copy of the GNU General Public License version
>  * 2 along with this work; if not, write to the Free Software Foundation,
>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>  *
>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>  * or visit www.oracle.com if you need additional information or have any
>  * questions.
>  */
> 
> /**
>  * @test
>  * @bug 8303755
>  * @summary Verify that Iterators method work as expected
>  * @modules jdk.compiler/com.sun.tools.javac.util
>  * @run junit IteratorsTest
>  */
> 
> import com.sun.tools.javac.util.Iterators;
> import java.util.Iterator;
> import java.util.List;
> import java.util.function.Function;
> import org.junit.jupiter.api.*;
> 
> public class IteratorsTest {
> 
>     @Test
>     public void compoundIterator() {
>         TestConverter<TestIterator<String>, String> c = new TestConverter<>(it -> it);
>         TestIterator<String> test1 = new TestIterator<>(List.of("1").iterator());
>         TestIterator<String> test2 = new TestIterator<>(List.of("2").iterator());
>         Iterator<String> compound = Iterators.createCompoundIterator(List.of(test1, test2), c);
> 
>         //nothing should be called before the hasNext or next is called:
>         assertMaxCalls(c, 0);
>         assertMaxCalls(test1, 0, 0);
>         assertMaxCalls(test2, 0, 0);
> 
>         //when hasNext is called, should invoke the hasNext delegate once:
>         Assertions.assertTrue(compound.hasNext());
> 
>         assertMaxCalls(c, 1);
>         assertMaxCalls(test1, 1, 0);
>         assertMaxCalls(test2, 0, 0);
> 
>         Assertions.assertTrue(compound.hasNext());
> 
>         assertMaxCalls(c, 0);
>         assertMaxCalls(test1, 1, 0);
>         assertMaxCalls(test2, 0, 0);
> 
>         //next may invoke hasNext once:
>         Assertions.assertEquals("1", compound.next());
> 
>         assertMaxCalls(c, 0);
>         assertMaxCalls(test1, 1, 1);
>         assertMaxCalls(test2, 0, 0);
>     }
> 
>     private void assertMaxCalls(TestIterator<?> test, int maxExpectedHasNextCalls, int maxExpectedNextCalls) {
>         if (test.hasNextCalls > maxExpectedHasNextCalls) {
>             Assertions.fail("too many hasNext invocations: " + test.hasNextCalls +
>                             ", expected: " + maxExpectedHasNextCalls);
>         }
>         test.hasNextCalls = 0;
>         if (test.nextCalls > maxExpectedNextCalls) {
>             Assertions.fail("too many next invocations: " + test.nextCalls +
>                             ", expected: " + maxExpectedNextCalls);
>         }
>         test.nextCalls = 0;
>     }
> 
>     private void assertMaxCalls(TestConverter<?, ?> test, int maxExpectedApplyCalls) {
>         if (test.applyCalls > maxExpectedApplyCalls) {
>             Assertions.fail("too many apply invocations: " + test.applyCalls +
>                             ", expected: " + maxExpectedApplyCalls);
>         }
>         test.applyCalls = 0;
>     }
> 
>     class TestIterator<T> implements Iterator<T> {
>         int hasNextCalls;
>         int nextCalls;
>         final Iterator<T> delegate;
> 
>         public TestIterator(Iterator<T> delegate) {
>             this.delegate = delegate;
>         }
> 
>         @Override
>         public boolean hasNext() {
>             hasNextCalls++;
>             return delegate.hasNext();
>         }
> 
>         @Override
>         public T next() {
>             nextCalls++;
>             return delegate.next();
>         }
>     }
>     class TestConverter<I, O>  implements Function<I, Iterator<O>> {
>         int applyCalls;
>         final Function<I, Iterator<O>> delegate;
> 
>         public TestConverter(Function<I, Iterator<O>> delegate) {
>             this.delegate = delegate;
>         }
> 
>         @Override
>         public Iterator<O> apply(I t) {
>             applyCalls++;
>             return delegate.apply(t);
>         }
>     }
> }
> 
> 
> I might be able to improve it later, if needed.

Where in the test tree would you normally put such a unit test?

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Thu Mar  9 10:47:03 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 10:47:03 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <MH_gX3a2iW_yp7itU1AO7YZ53jwSb9nXP6iO54bmPK8=.f0fb6989-ec55-4625-97f2-e019e7cee832@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
 <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>
 <us2754fcWMfPeJRY4FJQF8vZQj8SV51TwEYl0r7J1uE=.456d780a-e399-4beb-9690-ad4c5502676e@github.com>
 <MH_gX3a2iW_yp7itU1AO7YZ53jwSb9nXP6iO54bmPK8=.f0fb6989-ec55-4625-97f2-e019e7cee832@github.com>
Message-ID: <eHjGTKp-4YPWT4h6IL2jn6Hjc2kaDay0DKJnjqLqcek=.e1062b6a-e9bc-4618-9a03-be7cd78671b6@github.com>

On Thu, 9 Mar 2023 10:39:33 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> A test could be something like this:
>> 
>> /*
>>  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
>>  * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER.
>>  *
>>  * This code is free software; you can redistribute it and/or modify it
>>  * under the terms of the GNU General Public License version 2 only, as
>>  * published by the Free Software Foundation.
>>  *
>>  * This code is distributed in the hope that it will be useful, but WITHOUT
>>  * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
>>  * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
>>  * version 2 for more details (a copy is included in the LICENSE file that
>>  * accompanied this code).
>>  *
>>  * You should have received a copy of the GNU General Public License version
>>  * 2 along with this work; if not, write to the Free Software Foundation,
>>  * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA.
>>  *
>>  * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA
>>  * or visit www.oracle.com if you need additional information or have any
>>  * questions.
>>  */
>> 
>> /**
>>  * @test
>>  * @bug 8303755
>>  * @summary Verify that Iterators method work as expected
>>  * @modules jdk.compiler/com.sun.tools.javac.util
>>  * @run junit IteratorsTest
>>  */
>> 
>> import com.sun.tools.javac.util.Iterators;
>> import java.util.Iterator;
>> import java.util.List;
>> import java.util.function.Function;
>> import org.junit.jupiter.api.*;
>> 
>> public class IteratorsTest {
>> 
>>     @Test
>>     public void compoundIterator() {
>>         TestConverter<TestIterator<String>, String> c = new TestConverter<>(it -> it);
>>         TestIterator<String> test1 = new TestIterator<>(List.of("1").iterator());
>>         TestIterator<String> test2 = new TestIterator<>(List.of("2").iterator());
>>         Iterator<String> compound = Iterators.createCompoundIterator(List.of(test1, test2), c);
>> 
>>         //nothing should be called before the hasNext or next is called:
>>         assertMaxCalls(c, 0);
>>         assertMaxCalls(test1, 0, 0);
>>         assertMaxCalls(test2, 0, 0);
>> 
>>         //when hasNext is called, should invoke the hasNext delegate once:
>>         Assertions.assertTrue(compound.hasNext());
>> 
>>         assertMaxCalls(c, 1);
>>         assertMaxCalls(test1, 1, 0);
>>         assertMaxCalls(test2, 0, 0);
>> 
>>         Assertions.assertTrue(compound.hasNext());
>> 
>>         assertMaxCalls(c, 0);
>>         assertMaxCalls(test1, 1, 0);
>>         assertMaxCalls(test2, 0, 0);
>> 
>>         //next may invoke hasNext once:
>>         Assertions.assertEquals("1", compound.next());
>> 
>>         assertMaxCalls(c, 0);
>>         assertMaxCalls(test1, 1, 1);
>>         assertMaxCalls(test2, 0, 0);
>>     }
>> 
>>     private void assertMaxCalls(TestIterator<?> test, int maxExpectedHasNextCalls, int maxExpectedNextCalls) {
>>         if (test.hasNextCalls > maxExpectedHasNextCalls) {
>>             Assertions.fail("too many hasNext invocations: " + test.hasNextCalls +
>>                             ", expected: " + maxExpectedHasNextCalls);
>>         }
>>         test.hasNextCalls = 0;
>>         if (test.nextCalls > maxExpectedNextCalls) {
>>             Assertions.fail("too many next invocations: " + test.nextCalls +
>>                             ", expected: " + maxExpectedNextCalls);
>>         }
>>         test.nextCalls = 0;
>>     }
>> 
>>     private void assertMaxCalls(TestConverter<?, ?> test, int maxExpectedApplyCalls) {
>>         if (test.applyCalls > maxExpectedApplyCalls) {
>>             Assertions.fail("too many apply invocations: " + test.applyCalls +
>>                             ", expected: " + maxExpectedApplyCalls);
>>         }
>>         test.applyCalls = 0;
>>     }
>> 
>>     class TestIterator<T> implements Iterator<T> {
>>         int hasNextCalls;
>>         int nextCalls;
>>         final Iterator<T> delegate;
>> 
>>         public TestIterator(Iterator<T> delegate) {
>>             this.delegate = delegate;
>>         }
>> 
>>         @Override
>>         public boolean hasNext() {
>>             hasNextCalls++;
>>             return delegate.hasNext();
>>         }
>> 
>>         @Override
>>         public T next() {
>>             nextCalls++;
>>             return delegate.next();
>>         }
>>     }
>>     class TestConverter<I, O>  implements Function<I, Iterator<O>> {
>>         int applyCalls;
>>         final Function<I, Iterator<O>> delegate;
>> 
>>         public TestConverter(Function<I, Iterator<O>> delegate) {
>>             this.delegate = delegate;
>>         }
>> 
>>         @Override
>>         public Iterator<O> apply(I t) {
>>             applyCalls++;
>>             return delegate.apply(t);
>>         }
>>     }
>> }
>> 
>> 
>> I might be able to improve it later, if needed.
>
> Where in the test tree would you normally put such a unit test?

My guess would be to create a directory test/langtools/tools/javac/util/iterators, or some such.

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From jlahoda at openjdk.org  Thu Mar  9 10:50:45 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 9 Mar 2023 10:50:45 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v3]
In-Reply-To: <eHjGTKp-4YPWT4h6IL2jn6Hjc2kaDay0DKJnjqLqcek=.e1062b6a-e9bc-4618-9a03-be7cd78671b6@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <hPGfCYaSfZmNQOIdweZI8gBMo0TVZuQsDDNLoH46JB8=.b472e2ad-0dfd-451b-abd7-e5d051797c14@github.com>
 <php9WenUZc2RrILsKPyGdqvCsp8-8_ea46_4_3k35Zw=.fc23bbd7-350e-4ea7-8bc3-ce98042cf03b@github.com>
 <eaezx12NqSirDEC-Rse0VfsRn70_EqLJhyAWiFxwO0o=.4ca897a4-9856-486f-8463-a16aa40dbdb0@github.com>
 <us2754fcWMfPeJRY4FJQF8vZQj8SV51TwEYl0r7J1uE=.456d780a-e399-4beb-9690-ad4c5502676e@github.com>
 <MH_gX3a2iW_yp7itU1AO7YZ53jwSb9nXP6iO54bmPK8=.f0fb6989-ec55-4625-97f2-e019e7cee832@github.com>
 <eHjGTKp-4YPWT4h6IL2jn6Hjc2kaDay0DKJnjqLqcek=.e1062b6a-e9bc-4618-9a03-be7cd78671b6@github.com>
Message-ID: <mcYJw5adG0PdVn6vurj5v5DrwR_S8vQusrPTtEfJktU=.8dda9b7d-7978-4d8c-8c26-c85dcb1ea483@github.com>

On Thu, 9 Mar 2023 10:43:45 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Where in the test tree would you normally put such a unit test?
>
> My guess would be to create a directory test/langtools/tools/javac/util/iterators, or some such.

I'd use `test/langtools/tools/javac/util`, as I don't think we'll have so many tests for iterators. (Although even the `iterators` subdirectory would not be bad/problematic, subdirectories should be cheap, AFAIK.)

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From mcimadamore at openjdk.org  Thu Mar  9 12:32:01 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 9 Mar 2023 12:32:01 GMT
Subject: RFR: 8303820: Simplify type metadata [v3]
In-Reply-To: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
Message-ID: <3iNonEHJi0qIbxNp6YZrVO5MhdgxeGWAetyCwc1sUwk=.cae36c32-7407-4d97-a05c-215c48599bcc@github.com>

> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
> 
> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
> 
> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
> 
> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
> 
> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
> 
> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).

Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:

  Revert `constType` to only be implemented for primitive/class types

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12924/files
  - new: https://git.openjdk.org/jdk/pull/12924/files/1083a70b..7293495b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12924&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12924&range=01-02

  Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12924.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12924/head:pull/12924

PR: https://git.openjdk.org/jdk/pull/12924

From prappo at openjdk.org  Thu Mar  9 13:21:23 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 13:21:23 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler
Message-ID: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>

Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, @Override annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augment from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).

I'll add a comment here once I have benchmarked the change formally.

-------------

Commit messages:
 - Add a correctness test
 - Refactor the test
 - Add a test that the unfixed version fails
 - Change the test bug id and comment style
 - Add the test suggest by Jan Lahoda
 - Unify empty iterator in List and Iterators
 - Remove bespoke empty iterator in List
 - Initial commit from 8303755

Changes: https://git.openjdk.org/jdk/pull/12949/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303882
  Stats: 219 lines in 3 files changed: 179 ins; 33 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12949.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12949/head:pull/12949

PR: https://git.openjdk.org/jdk/pull/12949

From prappo at openjdk.org  Thu Mar  9 13:22:25 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 13:22:25 GMT
Subject: RFR: 8303755: Clean up around JavacElements.getAllMembers [v6]
In-Reply-To: <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
References: <krcDVb5jJS-CyVAEZ_0Y_3AF2S_vgQv-kui5hDJCo14=.6d48b093-6984-4279-afb7-a6265756b42c@github.com>
 <-svDyqMm2YPAfofJJK6bLvAgLF9-q9q8RW3EfAvHBqg=.7128625e-a19b-449d-8b15-819616827b95@github.com>
Message-ID: <_Dn9Oe3oDF7rTreNML7MmfuWtHRgP7l6mP3DzBz3ew8=.811e5268-06b2-48e3-82f2-5de05f99d023@github.com>

On Wed, 8 Mar 2023 13:08:44 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this cleanup which consists of commentary changes and code simplifications.
>
> Pavel Rappo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Drop recomputation improvements
>    
>    This reverts e18c0444cbe9f325d7122b97531869d2b8fedc56. Both `rank`
>    and `supertype` are _cached_ anyway, so the performance is not
>    a concern here. As for readability, while it's not really better,
>    it stands out from the rest of the file where everything is
>    recomputed on demand rather than cached and reused.
>    
>    However, this adds clarifying parentheses for `rank` in `precedes`.
>  - Repair botched merge
>    
>    6515bf762a0ffb4a8686e07ae37611507cf2b1be

Two PRs that supersede this one are:

  * https://github.com/openjdk/jdk/pull/12937
  * https://github.com/openjdk/jdk/pull/12949

-------------

PR: https://git.openjdk.org/jdk/pull/12904

From prappo at openjdk.org  Thu Mar  9 13:47:29 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 9 Mar 2023 13:47:29 GMT
Subject: Integrated: 8303881: Mixed, minor cleanup in jdk.compiler
In-Reply-To: <xXbkuTLzQ41CDf1OSE9xOQG4qCw6LD0ED47DWWdy4AE=.1c846cd9-deab-486e-af16-30733df633a8@github.com>
References: <xXbkuTLzQ41CDf1OSE9xOQG4qCw6LD0ED47DWWdy4AE=.1c846cd9-deab-486e-af16-30733df633a8@github.com>
Message-ID: <T8f_fgwsMfkIgMf3pDn3R4HOxhB5siy0AbvH6x3JupM=.2e357a61-e80e-4c7c-9cb1-4f0ae9026e21@github.com>

On Thu, 9 Mar 2023 10:06:20 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review trivial changes mostly to comments.

This pull request has now been integrated.

Changeset: 1e9942aa
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e9942aa112edca33f964db127df6c9ce41e86ff
Stats:     25 lines in 8 files changed: 0 ins; 3 del; 22 mod

8303881: Mixed, minor cleanup in jdk.compiler

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/12937

From vromero at openjdk.org  Thu Mar  9 15:40:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Mar 2023 15:40:06 GMT
Subject: RFR: 8303820: Simplify type metadata [v3]
In-Reply-To: <3iNonEHJi0qIbxNp6YZrVO5MhdgxeGWAetyCwc1sUwk=.cae36c32-7407-4d97-a05c-215c48599bcc@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
 <3iNonEHJi0qIbxNp6YZrVO5MhdgxeGWAetyCwc1sUwk=.cae36c32-7407-4d97-a05c-215c48599bcc@github.com>
Message-ID: <UWea-GqX1Sz2roAoyM3qxSzVcddgeipx2M1XwWPr1Z4=.fae1a011-123e-4f87-9d49-bd64e002cabc@github.com>

On Thu, 9 Mar 2023 12:32:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
>> 
>> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
>> 
>> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
>> 
>> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
>> 
>> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
>> 
>> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert `constType` to only be implemented for primitive/class types

looks good thanks

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12924

From asotona at openjdk.org  Thu Mar  9 17:41:29 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Mar 2023 17:41:29 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse
 class jar entries
Message-ID: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>

8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
This patch converts it to use Classfile API.

Please review.
Thanks,
Adam

-------------

Commit messages:
 - Merge branch 'master' into JDK-8294966-jartool
 - FingerPrint fixes
 - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
 - Merge branch 'JDK-8294982' into JDK-8294966
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
 - Merge branch 'master' into JDK-8294982
 - fixed new lines at end of file
 - ... and 186 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...3a835539

Changes: https://git.openjdk.org/jdk/pull/11694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294966
  Stats: 123 lines in 4 files changed: 49 ins; 40 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11694.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694

PR: https://git.openjdk.org/jdk/pull/11694

From mchung at openjdk.org  Thu Mar  9 17:41:36 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 9 Mar 2023 17:41:36 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <eLwmTi1U8k6ckWLMv7c1CYce-zFXVPgHRN6gg4_gq14=.c3fe99e4-1ff2-49b9-b897-d0ce5b627f36@github.com>

On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 42:

> 40: import jdk.internal.classfile.FieldModel;
> 41: import jdk.internal.classfile.MethodModel;
> 42: import jdk.internal.classfile.attribute.EnclosingMethodAttribute;

this import is unused.

src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 282:

> 280:                         fields.add(new Field(fm.flags().flagsMask(),
> 281:                                 fm.fieldName().stringValue(),
> 282:                                 fm.fieldType().stringValue()));

I find it more readable if the parameters to the Field constructor is aligned:

Suggestion:

                        fields.add(new Field(fm.flags().flagsMask(),
                                             fm.fieldName().stringValue(),
                                             fm.fieldType().stringValue()));

src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 313:

> 311:         @Override
> 312:         public void visitEnd() {
> 313:             this.nestedClass = this.outerClassName != null;

`this.nestedClass` is updated after the attributes are visited.   Suggest to rename `nestedClass` to `maybeNestedClass` and change `isNestedClass` to:

    public boolean isNestedClass() {
        return attrs.maybeNestedClass && attrs.outerClassName != null;
    }

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Thu Mar  9 17:41:37 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Mar 2023 17:41:37 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries
In-Reply-To: <eLwmTi1U8k6ckWLMv7c1CYce-zFXVPgHRN6gg4_gq14=.c3fe99e4-1ff2-49b9-b897-d0ce5b627f36@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
 <eLwmTi1U8k6ckWLMv7c1CYce-zFXVPgHRN6gg4_gq14=.c3fe99e4-1ff2-49b9-b897-d0ce5b627f36@github.com>
Message-ID: <BatwpfoLFIO021cEIxoU_-ZcYQXPNHyNiznIdyZGWIQ=.a1937dfd-4f15-428c-b81f-28ef58b14a29@github.com>

The message from this sender included one or more files
which could not be scanned for virus detection; do not
open these files unless you are certain of the sender's intent.

----------------------------------------------------------------------
On Tue, 7 Mar 2023 20:47:31 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
>> This patch converts it to use Classfile API.
>> 
>> Please review.
>> Thanks,
>> Adam
>
> src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 42:
> 
>> 40: import jdk.internal.classfile.FieldModel;
>> 41: import jdk.internal.classfile.MethodModel;
>> 42: import jdk.internal.classfile.attribute.EnclosingMethodAttribute;
> 
> this import is unused.

fixed, thanks.

> src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 313:
> 
>> 311:         @Override
>> 312:         public void visitEnd() {
>> 313:             this.nestedClass = this.outerClassName != null;
> 
> `this.nestedClass` is updated after the attributes are visited.   Suggest to rename `nestedClass` to `maybeNestedClass` and change `isNestedClass` to:
> 
>     public boolean isNestedClass() {
>         return attrs.maybeNestedClass && attrs.outerClassName != null;
>     }

I've changed `nestedClass` according to the suggestion, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From jlaskey at openjdk.org  Thu Mar  9 17:52:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 9 Mar 2023 17:52:26 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer
Message-ID: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>

Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

-------------

Commit messages:
 - Clean up JavadocTokenizer

Changes: https://git.openjdk.org/jdk/pull/12953/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8303912
  Stats: 378 lines in 3 files changed: 132 ins; 151 del; 95 mod
  Patch: https://git.openjdk.org/jdk/pull/12953.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12953/head:pull/12953

PR: https://git.openjdk.org/jdk/pull/12953

From mchung at openjdk.org  Thu Mar  9 18:23:12 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 9 Mar 2023 18:23:12 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>

On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

make/modules/jdk.jartool/Java.gmk line 28:

> 26: DISABLED_WARNINGS_java += missing-explicit-ctor
> 27: JAVAC_FLAGS += -XDstringConcat=inline
> 28: JAVAC_FLAGS += --enable-preview

This change is no longer needed.  It's not a preview API.

src/java.base/share/classes/module-info.java line 155:

> 153:         jdk.incubator.concurrent, // participates in preview features
> 154:         jdk.incubator.vector, // participates in preview features
> 155:         jdk.jartool, // participates in preview features

This is no longer needed.

src/jdk.jartool/share/classes/module-info.java line 52:

> 50:  * @since 9
> 51:  */
> 52: @ParticipatesInPreview

Same here.  No needed.

src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 252:

> 250:         private final int access;
> 251:         private final boolean publicClass;
> 252:         private boolean maybeNestedClass;

should be final since this is no longer updated.

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Fri Mar 10 07:56:18 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 07:56:18 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v2]
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <FJpgfba4D5oYxRV3xeE7ESTfCA3RxP_D4rt2DhVq3-M=.77dd9016-a277-41b3-9c34-199e819310a2@github.com>

> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 197 commits:

 - Merge branch 'master' into JDK-8294966-jartool
 - Merge branch 'master' into JDK-8294966-jartool
 - FingerPrint fixes
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge branch 'JDK-8294982' into JDK-8294966
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
 - Merge branch 'master' into JDK-8294982
 - ... and 187 more: https://git.openjdk.org/jdk/compare/e26cc526...f595a905

-------------

Changes: https://git.openjdk.org/jdk/pull/11694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=01
  Stats: 123 lines in 4 files changed: 49 ins; 40 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11694.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Fri Mar 10 07:56:20 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 07:56:20 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v2]
In-Reply-To: <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
 <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>
Message-ID: <VBgHR8mwFDf2bjlWa3MHNrZcsNucbmOf6XmkOnvFTnI=.b78f0689-a274-459d-8e74-77a6019d877c@github.com>

On Thu, 9 Mar 2023 18:16:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 197 commits:
>> 
>>  - Merge branch 'master' into JDK-8294966-jartool
>>  - Merge branch 'master' into JDK-8294966-jartool
>>  - FingerPrint fixes
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
>>    
>>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>>  - Merge branch 'JDK-8294982' into JDK-8294966
>>  - removed obsolete javadoc from implementation classes
>>  - minor fix in CodeBuilder and added test cases to LDCTest
>>  - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
>>  - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
>>  - Merge branch 'master' into JDK-8294982
>>  - ... and 187 more: https://git.openjdk.org/jdk/compare/e26cc526...f595a905
>
> make/modules/jdk.jartool/Java.gmk line 28:
> 
>> 26: DISABLED_WARNINGS_java += missing-explicit-ctor
>> 27: JAVAC_FLAGS += -XDstringConcat=inline
>> 28: JAVAC_FLAGS += --enable-preview
> 
> This change is no longer needed.  It's not a preview API.

Unfortunately patterns in switch statements are still in preview. This flag and participation in preview can be removed once they are finalised.

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Fri Mar 10 09:09:11 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 09:09:11 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v3]
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <uUr19WNHVkr3RB7gVgPW_Q-Jq1GMw5Qi4ml8LfCu80E=.42330b6e-b1f0-4a1a-9444-cd9b33f57f27@github.com>

> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  FingerPrint.maybeNestedClass set final

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/11694/files
  - new: https://git.openjdk.org/jdk/pull/11694/files/f595a905..f2131215

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/11694.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Fri Mar 10 09:09:15 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 09:09:15 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v3]
In-Reply-To: <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
 <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>
Message-ID: <AWyOG7wR0lMnST3kVFqXmsqyndqSJp2MKte8PMm1Nbg=.beeb6254-4c8a-40e7-9d4e-580058880158@github.com>

On Thu, 9 Mar 2023 18:19:17 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   FingerPrint.maybeNestedClass set final
>
> src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java line 252:
> 
>> 250:         private final int access;
>> 251:         private final boolean publicClass;
>> 252:         private boolean maybeNestedClass;
> 
> should be final since this is no longer updated.

fixed, thanks.

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From asotona at openjdk.org  Fri Mar 10 12:31:22 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 12:31:22 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v4]
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com>

> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:

 - Merge branch 'master' into JDK-8294966-jartool
 - FingerPrint.maybeNestedClass set final
 - Merge branch 'master' into JDK-8294966-jartool
 - Merge branch 'master' into JDK-8294966-jartool
 - FingerPrint fixes
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
   
   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
 - Merge branch 'JDK-8294982' into JDK-8294966
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - ... and 189 more: https://git.openjdk.org/jdk/compare/b1d89f30...240c0bfc

-------------

Changes: https://git.openjdk.org/jdk/pull/11694/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11694&range=03
  Stats: 122 lines in 4 files changed: 48 ins; 40 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/11694.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11694/head:pull/11694

PR: https://git.openjdk.org/jdk/pull/11694

From mcimadamore at openjdk.org  Fri Mar 10 13:16:19 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 10 Mar 2023 13:16:19 GMT
Subject: Integrated: 8303820: Simplify type metadata
In-Reply-To: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
References: <id1mA80zcPpAN1WhCgvGlnqS_R-vfFxYnMAu7NGGWCM=.37b766a5-91cb-4165-a868-9dfdb3f2c80f@github.com>
Message-ID: <9UU2pvZCzK-iVwkR48VbCDQ7XxwZVB24gWu1eh_kPdo=.2c573c59-2134-4f67-a9ed-ab5d1adb7d02@github.com>

On Wed, 8 Mar 2023 13:57:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch simplifies the TypeMetadata API. TypeMetadata can be used as a side-channel, to attach extra information to a javac type (type annotations, constant values).
> 
> While TypeMetadata provides the right knobs to compare types (see `Type::equalsIgnoreMetadata`), which is used uniformly across the type-system related routines (e.g. subtyping, type equality and type containment), the TypeMetadata API is also rather cumbersome to use.
> 
> The only way to add a new metadata to a type is to "combine" the metadata into an existing one, which feels odd, and probably too biased by the type annotations requirements.
> 
> This patch simplifies this: now TypeMetadata is a simple marker interface. There can be many implementations - one is `Annotations` (used to store type annotations), another is `ConstantValue` (used to store a type's constant value).
> 
> A type is then associated with a `List<TypeMetadata>`, and there are methods to add/drop/get metadata. These methods are used to provide support for annotated and constant types.
> 
> The resulting code feels simpler: to add a new metadata, one only has to define a new class/record inside TypeMetadata, and that's pretty much it. Javac will truck the metadata around in the correct way (as it did before).

This pull request has now been integrated.

Changeset: b9951dd6
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b9951dd63997b6330001311c925e171f4645a28b
Stats:     376 lines in 8 files changed: 59 ins; 235 del; 82 mod

8303820: Simplify type metadata

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12924

From jlaskey at openjdk.org  Fri Mar 10 13:35:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 10 Mar 2023 13:35:50 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v44]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <_ts4xtDO0xFOvi6L7tZeqYzVuC3Nx5zq6JgFu-pazWM=.4b432013-5cd6-4f9b-9086-3608f3ec339b@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Correction
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - CSR review
 - ... and 51 more: https://git.openjdk.org/jdk/compare/68b5eef4...50456b32

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=43
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From mchung at openjdk.org  Fri Mar 10 17:52:25 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 10 Mar 2023 17:52:25 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v4]
In-Reply-To: <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
 <28ICelV3yP7v0UEv3mCaFfCV5emQizFQbypc2Im8_EI=.2dbb5126-cbd2-4c23-b5c8-c656572e2182@github.com>
Message-ID: <N87x6mJwqgWj9W5PdSsUUEjJ6smmjNgs5DYaXvJF1dw=.84a514cc-47d4-4571-9718-a8965dbb429c@github.com>

On Fri, 10 Mar 2023 12:31:22 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to parse class jar entries
>> This patch converts it to use Classfile API.
>> 
>> Please review.
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 199 commits:
> 
>  - Merge branch 'master' into JDK-8294966-jartool
>  - FingerPrint.maybeNestedClass set final
>  - Merge branch 'master' into JDK-8294966-jartool
>  - Merge branch 'master' into JDK-8294966-jartool
>  - FingerPrint fixes
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Update src/jdk.jartool/share/classes/sun/tools/jar/FingerPrint.java
>    
>    Co-authored-by: Mandy Chung <mandy.chung at oracle.com>
>  - Merge branch 'JDK-8294982' into JDK-8294966
>  - removed obsolete javadoc from implementation classes
>  - minor fix in CodeBuilder and added test cases to LDCTest
>  - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
>  - ... and 189 more: https://git.openjdk.org/jdk/compare/b1d89f30...240c0bfc

Marked as reviewed by mchung (Reviewer).

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From mchung at openjdk.org  Fri Mar 10 17:52:26 2023
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 10 Mar 2023 17:52:26 GMT
Subject: RFR: 8294966: jdk.jartool sun.tools.jar.FingerPrint uses ASM to
 parse class jar entries [v4]
In-Reply-To: <VBgHR8mwFDf2bjlWa3MHNrZcsNucbmOf6XmkOnvFTnI=.b78f0689-a274-459d-8e74-77a6019d877c@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
 <zoVMtksso0hNXNPV2uEXKEY2chrg_gqpDg8sJCFOktc=.b3c1ed1a-fe28-431b-9b24-3b41e1f7f2c6@github.com>
 <VBgHR8mwFDf2bjlWa3MHNrZcsNucbmOf6XmkOnvFTnI=.b78f0689-a274-459d-8e74-77a6019d877c@github.com>
Message-ID: <rmDYkuhG5-ME1wq47HvbXsLHYV_XCE7Hj4TlFzb0c5U=.ce9b7085-3fbb-4f42-95dd-c9ecfe9dbf0b@github.com>

On Fri, 10 Mar 2023 07:51:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> make/modules/jdk.jartool/Java.gmk line 28:
>> 
>>> 26: DISABLED_WARNINGS_java += missing-explicit-ctor
>>> 27: JAVAC_FLAGS += -XDstringConcat=inline
>>> 28: JAVAC_FLAGS += --enable-preview
>> 
>> This change is no longer needed.  It's not a preview API.
>
> Unfortunately patterns in switch statements are still in preview. This flag and participation in preview can be removed once they are finalised.

Thanks for the clarification.   I forgot about that.

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From aturbanov at openjdk.org  Sat Mar 11 07:51:20 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sat, 11 Mar 2023 07:51:20 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler
In-Reply-To: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
Message-ID: <Yf91t2f1yZ_k3TEvfe9KJIlc8IZYO_2cZKHcaetmTQk=.d6ed5bf2-1be0-4e43-8010-02349f7f31ae@github.com>

On Thu, 9 Mar 2023 13:14:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
> 
> I'll add a comment here once I have benchmarked the change formally.

test/langtools/tools/javac/util/IteratorsTest.java line 150:

> 148:     }
> 149: 
> 150:     static class TestConverter<I, O>  implements Function<I, Iterator<O>> {

Suggestion:

    static class TestConverter<I, O> implements Function<I, Iterator<O>> {

-------------

PR: https://git.openjdk.org/jdk/pull/12949

From prappo at openjdk.org  Sat Mar 11 22:16:12 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Sat, 11 Mar 2023 22:16:12 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v2]
In-Reply-To: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
Message-ID: <PH-rYgurBuAipuDGcYOHngullfvP1w0PbD8pTlg3mRE=.996d4b6b-b50d-49cf-8633-77c391b029d4@github.com>

> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
> 
> I'll add a comment here once I have benchmarked the change formally.

Pavel Rappo has updated the pull request incrementally with one additional commit since the last revision:

  Update test/langtools/tools/javac/util/IteratorsTest.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12949/files
  - new: https://git.openjdk.org/jdk/pull/12949/files/6c3eeb13..8df4ed07

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12949.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12949/head:pull/12949

PR: https://git.openjdk.org/jdk/pull/12949

From cstein at openjdk.org  Mon Mar 13 08:24:05 2023
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 13 Mar 2023 08:24:05 GMT
Subject: RFR: JDK-8304036: Use CommandLine class from shared module
Message-ID: <zWRWNQDHkY7HiPHdCdb6JHcOKf_pwXHyfV1C7r3evbA=.71e123f1-ac6c-4dde-b423-55192cd3da9c@github.com>

This pull request addresses the open ends left by [JDK-8236919](https://bugs.openjdk.org/browse/JDK-8236919):
- #11272

Changes:
- [x] Extend list of targeted exports of `jdk.internal.opt/jdk.internal.opt` to `jdk.compiler` and `jdk.javadoc`
- [x] Use shared `CommandLine.java` in `jdk.compiler` module
- [x] Use shared `CommandLine.java` in `jdk.javadoc` module
- [x] Remove `CommandLine.java` from `jdk.compiler` module

-------------

Commit messages:
 - Add missing import
 - JDK-8304036: Use CommandLine class from shared module

Changes: https://git.openjdk.org/jdk/pull/12997/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304036
  Stats: 310 lines in 6 files changed: 7 ins; 297 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/12997.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12997/head:pull/12997

PR: https://git.openjdk.org/jdk/pull/12997

From prappo at openjdk.org  Mon Mar 13 09:55:02 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 Mar 2023 09:55:02 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v3]
In-Reply-To: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
Message-ID: <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>

> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
> 
> I'll add a comment here once I have benchmarked the change formally.

Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:

 - Merge remote-tracking branch 'myjdk/8303882' into 8303882
 - Squeeze a few extra drops of perf
 - Add a recursive test
 - Try squeeze more performance

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12949/files
  - new: https://git.openjdk.org/jdk/pull/12949/files/8df4ed07..04596f39

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=01-02

  Stats: 28 lines in 2 files changed: 15 ins; 6 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/12949.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12949/head:pull/12949

PR: https://git.openjdk.org/jdk/pull/12949

From asotona at openjdk.org  Mon Mar 13 10:17:59 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Mar 2023 10:17:59 GMT
Subject: Integrated: 8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to
 use the ClassFile API to parse JAR entries
In-Reply-To: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
References: <tfwqfOjtLt7JxZtOZSkuyUfRlp7S8x7T9E5qdr1k-5c=.c5a84756-ae21-40fa-820d-ee50ccfe9020@github.com>
Message-ID: <HxjC771KZbbWVvnQJeLUeCIsXhi1NZTxt6313Sf6MAI=.2a293dbf-1516-42a4-a423-9cc094872b61@github.com>

On Thu, 15 Dec 2022 14:56:03 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to use the ClassFile API to parse JAR entries
> 
> Please review.
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 25e7ac22
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/25e7ac226a3be9c064c0a65c398a8165596150f7
Stats:     122 lines in 4 files changed: 48 ins; 40 del; 34 mod

8294966: Convert jdk.jartool/sun.tools.jar.FingerPrint to use the ClassFile API to parse JAR entries

Reviewed-by: mchung

-------------

PR: https://git.openjdk.org/jdk/pull/11694

From prappo at openjdk.org  Mon Mar 13 10:27:24 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 Mar 2023 10:27:24 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v3]
In-Reply-To: <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
 <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
Message-ID: <yOvUMymqPQxlukuX2gMTreGruLJkjRiCoos0c2Ogbhk=.9cc2ec13-0c03-411d-86eb-a5e1114095d4@github.com>

On Mon, 13 Mar 2023 09:55:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
>> 
>> I'll add a comment here once I have benchmarked the change formally.
>
> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'myjdk/8303882' into 8303882
>  - Squeeze a few extra drops of perf
>  - Add a recursive test
>  - Try squeeze more performance

I've run a relevant performance test suit on this PR: the results were noisy and inconclusive. That said, there was no gross degradation. I think it's time to make a choice: either let this PR in or drop it because it has already burned too much review cycles.

>From my perspective, this PR improves code reuse while also retaining characteristics of the compound iterator: the iterator is still lazy with the minimum number of calls to constituent iterators.

-------------

PR: https://git.openjdk.org/jdk/pull/12949

From mcimadamore at openjdk.org  Mon Mar 13 10:52:34 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Mar 2023 10:52:34 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v3]
In-Reply-To: <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
 <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
Message-ID: <ViCe2CDDNWz3q7T_i_xhZg1-mk0OA0lKsX8O_UPXVEA=.a54703c6-8b82-4bb3-8f52-6ca28ab58718@github.com>

On Mon, 13 Mar 2023 09:55:02 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
>> 
>> I'll add a comment here once I have benchmarked the change formally.
>
> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'myjdk/8303882' into 8303882
>  - Squeeze a few extra drops of perf
>  - Add a recursive test
>  - Try squeeze more performance

Looks good - some minor (optional) comments on the test

test/langtools/tools/javac/util/IteratorsTest.java line 112:

> 110:         assertAndResetMaxCalls(c, 0);
> 111:         assertAndResetMaxCalls(test1, 1, 1);
> 112:         assertAndResetMaxCalls(test2, 0, 0);

Should the test continue, and check that we end up with calls to the second iterator?

test/langtools/tools/javac/util/IteratorsTest.java line 163:

> 161: 
> 162:         public TestConverter(Function<I, Iterator<O>> delegate) {
> 163:             this.delegate = delegate;

This parameter doesn't really seem to be used in the test?

test/langtools/tools/javac/util/IteratorsTest.java line 172:

> 170:         }
> 171:     }
> 172: }

Missing newline here

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12949

From mcimadamore at openjdk.org  Mon Mar 13 10:52:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 13 Mar 2023 10:52:36 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v3]
In-Reply-To: <ViCe2CDDNWz3q7T_i_xhZg1-mk0OA0lKsX8O_UPXVEA=.a54703c6-8b82-4bb3-8f52-6ca28ab58718@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
 <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
 <ViCe2CDDNWz3q7T_i_xhZg1-mk0OA0lKsX8O_UPXVEA=.a54703c6-8b82-4bb3-8f52-6ca28ab58718@github.com>
Message-ID: <0GpVHKy3am3qa2JpRp6yrcb3W_xZqs17OLN7-rND9CI=.44af02a9-f4d8-4577-9e33-28f8257e23a1@github.com>

On Mon, 13 Mar 2023 10:43:04 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'myjdk/8303882' into 8303882
>>  - Squeeze a few extra drops of perf
>>  - Add a recursive test
>>  - Try squeeze more performance
>
> test/langtools/tools/javac/util/IteratorsTest.java line 163:
> 
>> 161: 
>> 162:         public TestConverter(Function<I, Iterator<O>> delegate) {
>> 163:             this.delegate = delegate;
> 
> This parameter doesn't really seem to be used in the test?

I suggest this TestConverter to take a single type parameter `T` and implement `Function<TestIterator<S>, Iterator<S>>`

-------------

PR: https://git.openjdk.org/jdk/pull/12949

From prappo at openjdk.org  Mon Mar 13 16:01:34 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 Mar 2023 16:01:34 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v4]
In-Reply-To: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
Message-ID: <Cu9eXZZ5UNw1vcN287LCKkREG-E7cVtz_Sxl3XXiSp8=.9b7ef2a1-69e0-4ced-9ac8-e09aca7d5d12@github.com>

> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
> 
> I'll add a comment here once I have benchmarked the change formally.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Address feedback
   
   Continues compound iterator test until the very end.
 - Merge branch 'master' into 8303882
 - Address feedback
   
   Changes generic parameters and adds trailing newline.
 - Merge remote-tracking branch 'myjdk/8303882' into 8303882
 - Update test/langtools/tools/javac/util/IteratorsTest.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Squeeze a few extra drops of perf
 - Add a recursive test
 - Try squeeze more performance
 - Add a correctness test
 - Refactor the test
 - ... and 6 more: https://git.openjdk.org/jdk/compare/361befb5...360b4a96

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12949/files
  - new: https://git.openjdk.org/jdk/pull/12949/files/04596f39..360b4a96

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12949&range=02-03

  Stats: 65407 lines in 655 files changed: 55620 ins; 3219 del; 6568 mod
  Patch: https://git.openjdk.org/jdk/pull/12949.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12949/head:pull/12949

PR: https://git.openjdk.org/jdk/pull/12949

From prappo at openjdk.org  Mon Mar 13 16:01:35 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Mon, 13 Mar 2023 16:01:35 GMT
Subject: RFR: 8303882: Refactor some iterators in jdk.compiler [v3]
In-Reply-To: <ViCe2CDDNWz3q7T_i_xhZg1-mk0OA0lKsX8O_UPXVEA=.a54703c6-8b82-4bb3-8f52-6ca28ab58718@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
 <8AYqq4EwxH6-KCGaG3oUX1TH6lBXeYUzirg7GELzJ_E=.0da384dd-e2a2-4c3b-b69d-16c483e6cc65@github.com>
 <ViCe2CDDNWz3q7T_i_xhZg1-mk0OA0lKsX8O_UPXVEA=.a54703c6-8b82-4bb3-8f52-6ca28ab58718@github.com>
Message-ID: <8O-CVlUPLH6QgXcdyn63KoNZEwF3lSnE4_LxvRBvXbE=.2b8fe00c-3091-4e35-a929-17dd05b24e52@github.com>

On Mon, 13 Mar 2023 10:49:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Pavel Rappo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'myjdk/8303882' into 8303882
>>  - Squeeze a few extra drops of perf
>>  - Add a recursive test
>>  - Try squeeze more performance
>
> Looks good - some minor (optional) comments on the test

@mcimadamore, I have updated the test. Please check if that's what you had in mind.

-------------

PR: https://git.openjdk.org/jdk/pull/12949

From vromero at openjdk.org  Tue Mar 14 15:31:58 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Mar 2023 15:31:58 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <LqLfK0dP3g8BTaaeFBu_WccQnZ9DlrWQbFme3ZrMgZk=.d104cab5-58a8-4f49-9c41-3e4325ab5ddf@github.com>

On Thu, 9 Mar 2023 17:44:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

looks good to me

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1228:

> 1226:          * Constructor.
> 1227:          *
> 1228:          * @param cs      comment style

it seems like javadoc for parameter `cs` should be restored as it is still part of the parameter list

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12953

From cushon at openjdk.org  Tue Mar 14 15:52:28 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 14 Mar 2023 15:52:28 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Move test under `test/langtools/tools/javac/annotations/typeAnnotations`

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12914/files
  - new: https://git.openjdk.org/jdk/pull/12914/files/5be37a46..d88c6d1e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=00-01

  Stats: 0 lines in 1 file changed: 0 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12914/head:pull/12914

PR: https://git.openjdk.org/jdk/pull/12914

From vromero at openjdk.org  Tue Mar 14 15:52:29 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Mar 2023 15:52:29 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
Message-ID: <rXA23ZKOzKKMCoE32S-CGxwbvocgPZYsQ5dAcC7Shx8=.82d247f9-18aa-4196-a685-6e583f68e6f6@github.com>

On Tue, 14 Mar 2023 15:47:40 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test under `test/langtools/tools/javac/annotations/typeAnnotations`

looks sensible

test/langtools/tools/javac/annotations/NoTargetOnTypeParameterDeclaration.java line 1:

> 1: /*

I would place this file under: `test/langtools/tools/javac/annotations/typeAnnotations`

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/12914

From cushon at openjdk.org  Tue Mar 14 15:52:29 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 14 Mar 2023 15:52:29 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <rXA23ZKOzKKMCoE32S-CGxwbvocgPZYsQ5dAcC7Shx8=.82d247f9-18aa-4196-a685-6e583f68e6f6@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
 <rXA23ZKOzKKMCoE32S-CGxwbvocgPZYsQ5dAcC7Shx8=.82d247f9-18aa-4196-a685-6e583f68e6f6@github.com>
Message-ID: <HMgLlkTm3kzlmvj-m6RpWtbi2GBmCbUz88DGns43zaM=.c4de6934-5b28-4320-9b05-fac6f21e3378@github.com>

On Tue, 14 Mar 2023 15:43:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move test under `test/langtools/tools/javac/annotations/typeAnnotations`
>
> test/langtools/tools/javac/annotations/NoTargetOnTypeParameterDeclaration.java line 1:
> 
>> 1: /*
> 
> I would place this file under: `test/langtools/tools/javac/annotations/typeAnnotations`

Done, thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12914

From vromero at openjdk.org  Tue Mar 14 17:53:44 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 14 Mar 2023 17:53:44 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
Message-ID: <CUKokmQ1BhBZHQsKj1BDKstKU7VzOa_AjVFPD6faaTo=.ca1f74a4-da61-400d-ada2-319e7c4c3874@github.com>

On Tue, 14 Mar 2023 15:52:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test under `test/langtools/tools/javac/annotations/typeAnnotations`

Marked as reviewed by vromero (Reviewer).

test/langtools/tools/javac/annotations/typeAnnotations/NoTargetOnTypeParameterDeclaration.java line 1:

> 1: /*

thanks!

-------------

PR: https://git.openjdk.org/jdk/pull/12914

From darcy at openjdk.org  Tue Mar 14 18:34:45 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 14 Mar 2023 18:34:45 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
Message-ID: <SmfCZaJn-nhfIemyKNk8wQcmNSWBlV0gBtfuqjaF6TY=.33041d71-0281-4550-8f94-066472ec87c1@github.com>

On Tue, 14 Mar 2023 15:52:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test under `test/langtools/tools/javac/annotations/typeAnnotations`

Please file a CSR to review the change in behavior of javac to conform with the spec.

-------------

PR: https://git.openjdk.org/jdk/pull/12914

From prappo at openjdk.org  Tue Mar 14 18:40:07 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Tue, 14 Mar 2023 18:40:07 GMT
Subject: Integrated: 8303882: Refactor some iterators in jdk.compiler
In-Reply-To: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
References: <IgQp-ow7Y1LjvfZ_rISQM2vHcHuXymuVDA9digO6Q9w=.a59621b4-4354-462c-9f6c-776147d523df@github.com>
Message-ID: <VCFNzvVH4kkAmTN-kVDsK7uUQB2FWBpfhQg2xD8vsXY=.29ad6db8-31ef-4ff3-886d-505d6199f18e@github.com>

On Thu, 9 Mar 2023 13:14:27 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this refactoring to iterators in jdk.compiler. The refactoring delegates more to collections framework, while retaining the performance characteristics of bespoke iterators. The refactoring also adds inline comments, `@Override` annotations, and fixes some trivial bugs (as can be seen in the added test, which is slightly augmented from that suggested by Jan Lahoda here https://github.com/openjdk/jdk/pull/12904#discussion_r1129777660).
> 
> I'll add a comment here once I have benchmarked the change formally.

This pull request has now been integrated.

Changeset: f81e1def
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f81e1def8f74e91dcf7fa3bf54531a85956dc5e4
Stats:     269 lines in 3 files changed: 218 ins; 39 del; 12 mod

8303882: Refactor some iterators in jdk.compiler

Co-authored-by: Jan Lahoda <jlahoda at openjdk.org>
Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/12949

From jlu at openjdk.org  Wed Mar 15 16:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:03 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
Message-ID: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.

In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

-------------

Commit messages:
 - Write to ASCII
 - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1
 - Compile class with ascii (Not ready to make system wide change)
 - Toggle UTF-8 for javac option in JavaCompilation.gmk
 - CompileProperties converts in UTF-8
 - Convert .properties from ISO-8859-1 to UTF-8

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8301991
  Stats: 29093 lines in 490 files changed: 6 ins; 0 del; 29087 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Wed Mar 15 16:08:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:07 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
Message-ID: <_dP9N3UNWa82tfLVEapoSFJjbvMmlyP21ZbuL0NjTDU=.3685af0b-31a0-42aa-86b0-5098bda72766@github.com>

On Tue, 7 Mar 2023 23:15:14 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
> 
>> 250:             try {
>> 251:                 writer = new BufferedWriter(
>> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
> 
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.
> 
> Or else just stay with ascii; no one should be looking at these files!

Will stick with your latter solution, as since the .properties files were converted via native2ascii, it makes sense to write out via ascii.

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From jjg at openjdk.org  Wed Mar 15 16:08:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 15 Mar 2023 16:08:06 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

make/langtools/tools/compileproperties/CompileProperties.java line 252:

> 250:             try {
> 251:                 writer = new BufferedWriter(
> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));

Using ISO_8859_1 seems strange.
Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.

Or else just stay with ascii; no one should be looking at these files!

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Wed Mar 15 16:21:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Mar 2023 16:21:33 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:

> 1: #

This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From liach at openjdk.org  Wed Mar 15 18:47:35 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 15 Mar 2023 18:47:35 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v6]
In-Reply-To: <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
Message-ID: <FHnDYc3xVariTzDIzfLMr966WQmTrKD8_UhTjVg_TxE=.171e907e-058b-4b4e-bea4-0a38f83c6cd2@github.com>

On Mon, 9 Jan 2023 07:34:41 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Update copyright year
>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>  - address comments
>  - cleanup
>  - add annotation processing test
>  - fix line breaks
>  - add access flag based test
>  - remove spaces from empty lines in text block
>  - add bug number to test
>  - copyright
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/aed3ea90...43780935

Just checking on this. the CSR [has a response](https://bugs.openjdk.org/browse/JDK-8292467?focusedCommentId=14562384&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14562384):

> Please refine the discussion in "Solution" to explicitly state which --release/-target versions are intended to be impacted by the change. Presumably, at a minimum the synthetic and mandated information would only be written to class file formats where those bits are defined.
>
> A more conservative form of this change would be to only change the behavior for --release/-target 21. However, given the low expected impact of making the change, I'd expect it would be fine to make the change in behavior for all class file versions where that information is supported.

Our current implementation applies the change of behavior to all `--release/-target` versions. And as far as I see, `MethodParameters` attribute has been properly supported by the Reflection API to filter out synthetic and mandated parameters since 1c54a00f752a54a7a68b09d3df5d3a6081f4fcc8 (Java 8, when `MethodParameters` is introduced). So I suggest to move along by specifying that this change applies to all release/target versions, which will fix the reflection issue on all versions.

It ultimately depends on @SirYwell to decide what to do here. I can help you update the CSR's Solution Section as you desire, as I am eager to see this bug fixed on javac's end as well.

-------------

PR: https://git.openjdk.org/jdk/pull/9862

From naoto at openjdk.org  Wed Mar 15 20:23:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 20:23:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:

> 154: zh=\u00A4
> 155: zh_CN=\uFFE5
> 156: zh_HK=HK$

Why are they not encoded into UTF-8 native?

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From amaembo at gmail.com  Thu Mar 16 10:01:06 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 16 Mar 2023 11:01:06 +0100
Subject: Incompilable instanceof with super-bound
Message-ID: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>

Hello!

We've stumbled with the following code sample:

class Test {
    public static boolean isSub(Super<? super Box<?>> next) {
        return next instanceof Sub<?>;
    }

    static class Super<T> {}

    static class Sub<T> extends Super<Box<T>> { }

    static class Box<T> {}

    public static void main(String[] args) {
System.out.println(isSub(new Sub<>()));
}
}

javac 21-ea+12-971 reports an error here:

Test.java:3: error: incompatible types: Super<CAP#1> cannot be converted to
Sub<?>
        return next instanceof Sub<?>;
               ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object super: Box<?> from capture of ? super Box<?>
1 error

On the other hand, Eclipse compiler compiles this correctly. From my
understanding of the specification, this code should be accepted. Could you
please take a look?

Thank you in advance,
Tagir Valeev.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230316/9bc9048f/attachment.htm>

From maurizio.cimadamore at oracle.com  Thu Mar 16 10:21:37 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Mar 2023 10:21:37 +0000
Subject: Incompilable instanceof with super-bound
In-Reply-To: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
References: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
Message-ID: <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>

It seems an issue with cast conversion? E.g. the following:

|Sub<?> ss = (Sub<?>)next; |

Also fails (with same error). Now, there are two questions here:

 1. should the cast be statically rejected - this means asking whether
    |Sub<?>| and |Super<? super Box<?>>| are provably distinct
    parameterized types;
 2. should the cast be allowed without warnings - this means proving
    that there is only one possible way to go from a |Super<? super
    Box<?>>| down to a |Sub<?>|;

But, before I try to reply any of this questions - can you please 
confirm me that there is another error in this program - namely with 
|isSub(new Sub<>())| (I seem to get an inference failure here for the 
diamond expression).

Maurizio

On 16/03/2023 10:01, Tagir Valeev wrote:

> Hello!
>
> We've stumbled with the following code sample:
>
> class Test {
> ? ? public static boolean isSub(Super<? super Box<?>> next) {
> ? ? ? ? return next instanceof Sub<?>;
> ? ? }
>
> ? ? static class Super<T> {}
>
> ? ? static class Sub<T> extends Super<Box<T>> { }
>
> ? ? static class Box<T> {}
>
> ? ? public static void main(String[] args) {
> System.out.println(isSub(new Sub<>()));
> }
> }
>
> javac 21-ea+12-971 reports an error here:
>
> Test.java:3: error: incompatible types: Super<CAP#1> cannot be 
> converted to Sub<?>
> ? ? ? ? return next instanceof Sub<?>;
> ? ? ? ? ? ? ? ?^
> ? where CAP#1 is a fresh type-variable:
> ? ? CAP#1 extends Object super: Box<?> from capture of ? super Box<?>
> 1 error
>
> On the other hand, Eclipse compiler compiles this correctly. From my 
> understanding of the specification, this code should be accepted. 
> Could you please take a look?
>
> Thank you in advance,
> Tagir Valeev.

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230316/e683d1d0/attachment-0001.htm>

From amaembo at gmail.com  Thu Mar 16 11:13:30 2023
From: amaembo at gmail.com (Tagir Valeev)
Date: Thu, 16 Mar 2023 12:13:30 +0100
Subject: Incompilable instanceof with super-bound
In-Reply-To: <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>
References: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
 <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>
Message-ID: <CAE+3fjbp_EkGzreciDYk6w_47LR2ZH5D=pzG1DQR8-XYk4bHkg@mail.gmail.com>

Hello, Maurizio!

Thank you for the quick response.

I added the main() method just to check whether the resulting program is
actually compilable and runnable by Eclipse compiler (and it is). If
there's another problem there, then probably it requires separate
investigation, so let's put it aside for now. For this particular issue,
let's replace the main method with

System.out.println(isSub(null));

With best regards,
Tagir Valeev.

On Thu, Mar 16, 2023 at 11:21?AM Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> It seems an issue with cast conversion? E.g. the following:
>
> Sub<?> ss = (Sub<?>)next;
>
> Also fails (with same error). Now, there are two questions here:
>
>    1. should the cast be statically rejected - this means asking whether
>    Sub<?> and Super<? super Box<?>> are provably distinct parameterized
>    types;
>    2. should the cast be allowed without warnings - this means proving
>    that there is only one possible way to go from a Super<? super Box<?>>
>    down to a Sub<?>;
>
> But, before I try to reply any of this questions - can you please confirm
> me that there is another error in this program - namely with isSub(new
> Sub<>()) (I seem to get an inference failure here for the diamond
> expression).
>
> Maurizio
>
> On 16/03/2023 10:01, Tagir Valeev wrote:
>
> Hello!
>
> We've stumbled with the following code sample:
>
> class Test {
>     public static boolean isSub(Super<? super Box<?>> next) {
>         return next instanceof Sub<?>;
>     }
>
>     static class Super<T> {}
>
>     static class Sub<T> extends Super<Box<T>> { }
>
>     static class Box<T> {}
>
>     public static void main(String[] args) {
> System.out.println(isSub(new Sub<>()));
> }
> }
>
> javac 21-ea+12-971 reports an error here:
>
> Test.java:3: error: incompatible types: Super<CAP#1> cannot be converted
> to Sub<?>
>         return next instanceof Sub<?>;
>                ^
>   where CAP#1 is a fresh type-variable:
>     CAP#1 extends Object super: Box<?> from capture of ? super Box<?>
> 1 error
>
> On the other hand, Eclipse compiler compiles this correctly. From my
> understanding of the specification, this code should be accepted. Could you
> please take a look?
>
> Thank you in advance,
> Tagir Valeev.
>
> ?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230316/c865974d/attachment.htm>

From jlaskey at openjdk.org  Thu Mar 16 12:07:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 16 Mar 2023 12:07:57 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v45]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <sh500oB5itOA9tw-xJ8Nc8TwUJevtYbTjkieBnPeaLs=.744931f5-a5a6-4dfb-ba37-77f613ac1d24@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 62 commits:

 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - ... and 52 more: https://git.openjdk.org/jdk/compare/7277bb19...d6947fd4

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44
  Stats: 9552 lines in 81 files changed: 9452 ins; 24 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From maurizio.cimadamore at oracle.com  Thu Mar 16 14:54:08 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Mar 2023 14:54:08 +0000
Subject: Incompilable instanceof with super-bound
In-Reply-To: <CAE+3fjbp_EkGzreciDYk6w_47LR2ZH5D=pzG1DQR8-XYk4bHkg@mail.gmail.com>
References: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
 <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>
 <CAE+3fjbp_EkGzreciDYk6w_47LR2ZH5D=pzG1DQR8-XYk4bHkg@mail.gmail.com>
Message-ID: <6a18271d-a9df-9412-bb28-1bebd4ddb72e@oracle.com>

On 16/03/2023 11:13, Tagir Valeev wrote:

> Also fails (with same error). Now, there are two questions here:
>
>  1. should the cast be statically rejected - this means asking whether
>     |Sub<?>| and |Super<? super Box<?>>| are provably distinct
>     parameterized types;
>  2. should the cast be allowed without warnings - this means proving
>     that there is only one possible way to go from a |Super<? super
>     Box<?>>| down to a |Sub<?>|;
>
Before I dive into the actual rules, I must pause for a second, and 
tackle the elephant in the room: there is a long-standing discrepancy 
between javac and Eclipse - in that javac static checks around casts go 
beyond what is specified by the JLS. This can result in some casts being 
/rejected/, rather than simply flagged with an unchecked warning. We are 
in one such case here.

Back to the example, we have to prove that there exists a narrowing 
reference conversion (5.1.6.1) between |Super<#CAP1>|, where |#CAP1 :> 
Box<?>| (note the capture conversion here) and |Sub<?>|. To do that we 
have to prove that there is /no/ supertype X of |Super<#CAP1>| and Y of 
|Sub<?>| such that X and Y are provably distinct (4.5). To establish 
that, we need to first find a supertype of |Sub<?>| that can be 
compared? against |Super<#CAP1>|. That supertype is |Super<#CAP2>| where 
|#CAP1 <: Object| (that's the direct supertype of |Sub<?>|). So, are 
|Super<#CAP1>| and |Super<#CAP2>| provably distinct? From the definition:

> Two type arguments are provably distinct if one of the following is true:
>
> ??? Neither argument is a type variable or wildcard, and the two 
> arguments are not the same type.
>
> ??? One type argument is a type variable or wildcard, with an upper 
> bound (from capture conversion (?5.1.10), if necessary) of S; and the 
> other type argument T is not a type variable or wildcard; and neither 
> |S| <: |T| nor |T| <: |S| (?4.8, ?4.10).
>
> ??? Each type argument is a type variable or wildcard, with upper 
> bounds (from capture conversion, if necessary) of S and T; and neither 
> |S| <: |T| nor |T| <: |S|.
>
Since the upper bounds of |#CAP1| and |#CAP2| are compatible (after all, 
|Box<?> <: Object| ), we can conclude that, from a JLS perspective, 
|Super<#CAP1>| and |Super<#CAP2>| are /not/ provably distinct. So a 
narrowing reference conversion exists, and the cast should be allowed.

Should there be a warning? This depends on whether the narrowing 
reference conversion is checked - which is defined in 5.1.6.2:

> The unchecked narrowing reference conversions are as follows:
>
> ??? A narrowing reference conversion from a type S to a parameterized 
> class or interface type T is unchecked, unless at least one of the 
> following is true:
>
> ??????? All of the type arguments of T are unbounded wildcards.
>
> ??????? T <: S, and S has no subtype X other than T where the type 
> arguments of X are not contained in the type arguments of T.

Since here the target T is |Sub<?>|, which contains only unbounded 
wildcards, the conversion should /not/ be unchecked (meaning no warning 
should be generated). This also means that |Sub<?>| is a valid type test 
pattern for the instanceof.

Back to javac, the reason as to why javac disallows the cast (and hence, 
the instanceof) is that javac doesn?t think that you can write a 
well-formed witness of |Super<? super Box<?>>| that is /also/ compatible 
with |Sub<?>|. I believe javac is correct in its assertion: the only two 
witnesses I can think of are |Super<Box<?>>| and |Super<Box>|, neither 
of which seems compatible with |Sub<?>| (as |Sub<T> extends 
Super<Box<T>>|, and there?s no value you can replace for T to make the 
resulting type match with either |Super<Box>| or |Super<Box<?>>|). Which 
is exactly the same reason as to why javac doesn?t think (inside the 
|main| method) that there?s a way for |new Sub<>| to be inferred such 
that the inferred type is compatible with |Super<? super Box<?>>|.

Now, while there are some discrepancies between what the JLS say and 
what javac does with respect to narrowing reference conversions, there 
should be no such discrepancies when it comes to inference. Note that 
the same failure with |new Sub<>| can be reproduced even w/o method 
call, as in:

|Super<? super Box<?>> s = new Sub<>(); |

In this case the compiler has to prove that:

|Sub<alpha> <: Super<? super Box<?>> --> Super<Box<alpha>> <: Super<? 
super Box<?>> --> Box<alpha> <= ? super Box<?> --> Box<?> <: Box<alpha> 
--> ? <= alpha --> false |

(that?s because 18.2.3 doesn?t have any notion of how to reduce the 
above type containment).

In other words, there?s no instantiation for alpha which makes the above 
proof correct, so infererence must fail.

Summing up, we know there are difference between how Eclipse, JLS and 
javac deal with narrowing reference conversions. But, typically the 
mismatches have to do with corner cases where no concrete witness for 
the cast can be produced. So I think the most important question here is 
whether |isSub(new Sub<>())| should succeed at all. I don?t think it 
should (see above) - and if that?s the case, this seems ?just? another 
case where javac eagerly rejects a cast that seems unsound anyway.

Cheers

Maurizio

?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230316/842dff4c/attachment-0001.htm>

From simeon.danailov.andreev at gmail.com  Thu Mar 16 15:06:32 2023
From: simeon.danailov.andreev at gmail.com (S A)
Date: Thu, 16 Mar 2023 17:06:32 +0200
Subject: Incompilable instanceof with super-bound
In-Reply-To: <6a18271d-a9df-9412-bb28-1bebd4ddb72e@oracle.com>
References: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
 <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>
 <CAE+3fjbp_EkGzreciDYk6w_47LR2ZH5D=pzG1DQR8-XYk4bHkg@mail.gmail.com>
 <6a18271d-a9df-9412-bb28-1bebd4ddb72e@oracle.com>
Message-ID: <CACcnpz2zToUMcoC4odnPH=TD9ZOh_oy-k9iPA=6xcDidoSspow@mail.gmail.com>

Hi,

on the topic of ecj, neither javac nor ecj accept the call when passing
Sub<?>:

public static void main(String[] args) {
Sub<?> s = new Sub<Box<String>>();
System.out.println(isSub(new Super<Box<String>>()));
}

The ecj compile error is:

1. ERROR in .../test/Test.java (at line 16)
        System.out.println(isSub(new Super<Box<String>>()));
                           ^^^^^
The method isSub(Test.Super<? super Test.Box<?>>) in the type Test is not
applicable for the arguments (Test.Super<Test.Box<String>>)
----------
1 problem (1 error)

The javac compile error is:

test/Test.java:5: error: incompatible types: Super<CAP#1> cannot be
converted to Sub<?>
                return next instanceof Sub<?>;
                       ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object super: Box<?> from capture of ? super Box<?>
test/Test.java:16: error: incompatible types: Super<Box<String>> cannot be
converted to Super<? super Box<?>>
                System.out.println(isSub(new Super<Box<String>>()))

I've not looked into why the cast is not rejected, but from what I
understand the JLS has enough grey area in that regard. So maybe not
rejecting the cast is OK specification-wise. When in doubt please open an
issue at: https://github.com/eclipse-jdt/eclipse.jdt.core/issues

I hope I didn't misunderstand the questions/comments. If so, sorry for the
noise.

Best regards,
Simeon

On Thu, 16 Mar 2023 at 16:54, Maurizio Cimadamore <
maurizio.cimadamore at oracle.com> wrote:

> On 16/03/2023 11:13, Tagir Valeev wrote:
>
> Also fails (with same error). Now, there are two questions here:
>
>    1. should the cast be statically rejected - this means asking whether
>    Sub<?> and Super<? super Box<?>> are provably distinct parameterized
>    types;
>    2. should the cast be allowed without warnings - this means proving
>    that there is only one possible way to go from a Super<? super Box<?>>
>    down to a Sub<?>;
>
> Before I dive into the actual rules, I must pause for a second, and tackle
> the elephant in the room: there is a long-standing discrepancy between
> javac and Eclipse - in that javac static checks around casts go beyond what
> is specified by the JLS. This can result in some casts being *rejected*,
> rather than simply flagged with an unchecked warning. We are in one such
> case here.
>
> Back to the example, we have to prove that there exists a narrowing
> reference conversion (5.1.6.1) between Super<#CAP1>, where #CAP1 :> Box<?>
> (note the capture conversion here) and Sub<?>. To do that we have to
> prove that there is *no* supertype X of  Super<#CAP1> and Y of  Sub<?>
> such that X and Y are provably distinct (4.5). To establish that, we need
> to first find a supertype of Sub<?> that can be compared  against
> Super<#CAP1>. That supertype is Super<#CAP2> where #CAP1 <: Object
> (that's the direct supertype of Sub<?>). So, are Super<#CAP1>  and
> Super<#CAP2>  provably distinct? From the definition:
>
> Two type arguments are provably distinct if one of the following is true:
>
>     Neither argument is a type variable or wildcard, and the two arguments
> are not the same type.
>
>     One type argument is a type variable or wildcard, with an upper bound
> (from capture conversion (?5.1.10), if necessary) of S; and the other type
> argument T is not a type variable or wildcard; and neither |S| <: |T| nor
> |T| <: |S| (?4.8, ?4.10).
>
>     Each type argument is a type variable or wildcard, with upper bounds
> (from capture conversion, if necessary) of S and T; and neither |S| <: |T|
> nor |T| <: |S|.
>
> Since the upper bounds of #CAP1 and #CAP2 are compatible (after all, Box<?>
> <: Object ), we can conclude that, from a JLS perspective, Super<#CAP1>
> and Super<#CAP2> are *not* provably distinct. So a narrowing reference
> conversion exists, and the cast should be allowed.
>
> Should there be a warning? This depends on whether the narrowing reference
> conversion is checked - which is defined in 5.1.6.2:
>
> The unchecked narrowing reference conversions are as follows:
>
>     A narrowing reference conversion from a type S to a parameterized
> class or interface type T is unchecked, unless at least one of the
> following is true:
>
>         All of the type arguments of T are unbounded wildcards.
>
>         T <: S, and S has no subtype X other than T where the type
> arguments of X are not contained in the type arguments of T.
>
> Since here the target T is Sub<?>, which contains only unbounded
> wildcards, the conversion should *not* be unchecked (meaning no warning
> should be generated). This also means that Sub<?> is a valid type test
> pattern for the instanceof.
>
> Back to javac, the reason as to why javac disallows the cast (and hence,
> the instanceof) is that javac doesn?t think that you can write a
> well-formed witness of Super<? super Box<?>> that is *also* compatible
> with Sub<?>. I believe javac is correct in its assertion: the only two
> witnesses I can think of are Super<Box<?>> and Super<Box>, neither of
> which seems compatible with Sub<?> (as Sub<T> extends Super<Box<T>>, and
> there?s no value you can replace for T to make the resulting type match
> with either Super<Box> or Super<Box<?>>). Which is exactly the same
> reason as to why javac doesn?t think (inside the main method) that
> there?s a way for new Sub<> to be inferred such that the inferred type is
> compatible with Super<? super Box<?>>.
>
> Now, while there are some discrepancies between what the JLS say and what
> javac does with respect to narrowing reference conversions, there should be
> no such discrepancies when it comes to inference. Note that the same
> failure with new Sub<> can be reproduced even w/o method call, as in:
>
> Super<? super Box<?>> s = new Sub<>();
>
> In this case the compiler has to prove that:
>
> Sub<alpha> <: Super<? super Box<?>>
> --> Super<Box<alpha>> <: Super<? super Box<?>>
> --> Box<alpha> <= ? super Box<?>
> --> Box<?> <: Box<alpha>
> --> ? <= alpha
> --> false
>
> (that?s because 18.2.3 doesn?t have any notion of how to reduce the above
> type containment).
>
> In other words, there?s no instantiation for alpha which makes the above
> proof correct, so infererence must fail.
>
> Summing up, we know there are difference between how Eclipse, JLS and
> javac deal with narrowing reference conversions. But, typically the
> mismatches have to do with corner cases where no concrete witness for the
> cast can be produced. So I think the most important question here is
> whether isSub(new Sub<>()) should succeed at all. I don?t think it should
> (see above) - and if that?s the case, this seems ?just? another case where
> javac eagerly rejects a cast that seems unsound anyway.
>
> Cheers
>
> Maurizio
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230316/1678fd9a/attachment-0001.htm>

From maurizio.cimadamore at oracle.com  Thu Mar 16 16:43:27 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Thu, 16 Mar 2023 16:43:27 +0000
Subject: Incompilable instanceof with super-bound
In-Reply-To: <CACcnpz2zToUMcoC4odnPH=TD9ZOh_oy-k9iPA=6xcDidoSspow@mail.gmail.com>
References: <CAE+3fjYVMjYVt2sBWw7jXjaAx0JMmVtoNO8CovH+4NT3Jn6X+Q@mail.gmail.com>
 <76711d06-006b-e26a-a17d-304ee1c4cbb3@oracle.com>
 <CAE+3fjbp_EkGzreciDYk6w_47LR2ZH5D=pzG1DQR8-XYk4bHkg@mail.gmail.com>
 <6a18271d-a9df-9412-bb28-1bebd4ddb72e@oracle.com>
 <CACcnpz2zToUMcoC4odnPH=TD9ZOh_oy-k9iPA=6xcDidoSspow@mail.gmail.com>
Message-ID: <48753b96-9562-5afc-8fa0-4272364ae535@oracle.com>

I think the original example was passing `new Sub<>()` ? This fails in 
javac, but, from what I understood from Tagir, Eclipse compiles it fine. 
In my analysis (see my last email) I believe I showed this (the 
inference issue, not the cast) to be a bug in the Eclipse compiler (of 
course this area is tricky, so there might be something I missed).

Cheers
Maurizio

On 16/03/2023 15:06, S A wrote:
> public static void main(String[] args) {
> Sub<?> s = new Sub<Box<String>>();
> System.out.println(isSub(new Super<Box<String>>()));
> }
>
> The ecj compile error is:
>
> 1. ERROR in .../test/Test.java (at line 16)
> ? ? ? ? System.out.println(isSub(new Super<Box<String>>()));
> ? ? ? ? ? ? ? ? ? ? ? ? ? ?^^^^^

From jlu at openjdk.org  Thu Mar 16 18:19:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:19:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=00-01

  Stats: 92 lines in 4 files changed: 0 ins; 0 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:40 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
Message-ID: <CRTgRmg-NKyRb1XyeIcUdbz-JgoZE9nUJ6hBHsRIvLk=.c4614e2d-ec44-40fa-a88d-41c2b94b12bb@github.com>

On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

Conversion did not work as expected, addressing right now.

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:43 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
Message-ID: <Pns4G-crmY2QuscU_BkwBA2hXFMN3VQMdzc-UWVKPDU=.d20ab56a-ca0f-45aa-9a2d-361b532281ed@github.com>

On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:
> 
>> 154: zh=\u00A4
>> 155: zh_CN=\uFFE5
>> 156: zh_HK=HK$
> 
> Why are they not encoded into UTF-8 native?

Not sure, thank you for catching it. Working on it right now.

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:21:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:46 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
Message-ID: <_6WBGo5CQBseDEjMv16qCWmodFlYOO4gsT9WbON7ddA=.f94339a4-8893-47e4-8bb1-f28a8807ad9d@github.com>

On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:
> 
>> 1: #
> 
> This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

Thank you, removed the changes for this file

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:35:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:51 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=01-02

  Stats: 87 lines in 1 file changed: 0 ins; 0 del; 87 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From jlu at openjdk.org  Thu Mar 16 18:35:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:54 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
Message-ID: <XFZBHgkji9zthsA9wOP-bDqbf7PTVoKJzNXHDR1pThQ=.a99810cd-d764-40ee-9699-b234d6583007@github.com>

On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

CurrencySymbols.properties is fully converted to UTF-8 now

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From p.rader at gmx.net  Fri Mar 17 10:39:25 2023
From: p.rader at gmx.net (Peter Rader)
Date: Fri, 17 Mar 2023 11:39:25 +0100
Subject: Current state = CODING_END, new state = FLUSHED?
Message-ID: <trinity-e5a25fa2-bd13-48c3-934f-a4fdf9bb80dc-1679049565612@3c-app-gmx-bs31>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230317/32c6180b/attachment-0001.htm>

From aturbanov at openjdk.org  Fri Mar 17 14:47:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Mar 2023 14:47:00 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <j-S26uZCklzY5yszQoSNdHqeyeEVxRIx9vkDApQMXdk=.ee523f47-9370-4e7a-b3a9-cad2a80fc292@github.com>

On Thu, 9 Mar 2023 17:44:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavadocTokenizer.java line 108:

> 106: 
> 107:         JavadocComment(CommentStyle cs, UnicodeReader reader, int pos, int endPos) {
> 108:             super(cs,  reader, pos, endPos);

Suggestion:

            super(cs, reader, pos, endPos);

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 116:

> 114:      * @param length  length of meaningful content in buffer.
> 115:      */
> 116:     protected  UnicodeReader(Log log, char[] array,  int length) {

Suggestion:

    protected UnicodeReader(Log log, char[] array, int length) {

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 128:

> 126:       * @param endPos  end of meaningful content in buffer.
> 127:       */
> 128:     protected  UnicodeReader(Log log, char[] array, int pos, int endPos) {

Suggestion:

    protected UnicodeReader(Log log, char[] array, int pos, int endPos) {

-------------

PR: https://git.openjdk.org/jdk/pull/12953

From archie.cobbs at gmail.com  Fri Mar 17 15:16:43 2023
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Fri, 17 Mar 2023 10:16:43 -0500
Subject: Current state = CODING_END, new state = FLUSHED?
In-Reply-To: <trinity-e5a25fa2-bd13-48c3-934f-a4fdf9bb80dc-1679049565612@3c-app-gmx-bs31>
References: <trinity-e5a25fa2-bd13-48c3-934f-a4fdf9bb80dc-1679049565612@3c-app-gmx-bs31>
Message-ID: <CANSoFxvcGbG1Gr_ETsOEWDgzagbObfEZtDY_OxB8-VwbTPqG0w@mail.gmail.com>

Hi Peter,

Looks like this bug has been fixed and just needs to be backported (
JDK-8260010 <https://bugs.openjdk.org/browse/JDK-8260010>).

Also, it's not a compiler bug, but rather a library bug, so you might try
asking on the core-libs mailing list
<https://mail.openjdk.org/mailman/listinfo/core-libs-dev> instead.

-Archie

On Fri, Mar 17, 2023 at 5:39?AM Peter Rader <p.rader at gmx.net> wrote:

> I have been requested to ask if you feel responsible to fix this bug.
>
> Caused by: java.lang.IllegalStateException: Current state = CODING_END,
> new state = FLUSHED
>     at java.nio.charset.CharsetDecoder.throwIllegalStateException
> (CharsetDecoder.java:998)
>     at java.nio.charset.CharsetDecoder.flush (CharsetDecoder.java:681)
>     at java.nio.charset.CharsetDecoder.decode (CharsetDecoder.java:810)
>     at java.util.zip.ZipCoder.normalizedHashDecode (ZipCoder.java:136)
>     at java.util.zip.ZipCoder$UTF8ZipCoder.normalizedHash
> (ZipCoder.java:228)
>
> Original ticket: https://issues.apache.org/jira/browse/MNG-7742
>
> Kind regards
>
> Peter Rader
> --
> Fachinformatiker AE / IT Software Developer
> Peter Rader
> Wilsnacker Strasse 17
> 10559 Berlin - GERMANY
> Tel: 0049 (0)30 / 6 29 33 29 6
> Fax: 0049 (0)30 / 6 29 33 29 6
> Handy: 0049 (0)176 / 87 521 576
> Handy: 0049 (0)176 / 47 876 303
>


-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230317/0ced3844/attachment.htm>

From jlaskey at openjdk.org  Fri Mar 17 16:18:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 17 Mar 2023 16:18:44 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer
In-Reply-To: <LqLfK0dP3g8BTaaeFBu_WccQnZ9DlrWQbFme3ZrMgZk=.d104cab5-58a8-4f49-9c41-3e4325ab5ddf@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <LqLfK0dP3g8BTaaeFBu_WccQnZ9DlrWQbFme3ZrMgZk=.d104cab5-58a8-4f49-9c41-3e4325ab5ddf@github.com>
Message-ID: <kOIMu-nEe_oYNRDpQCZYd17j24QrTxzr-vg2Z2U4lLs=.06596f18-b80c-43cf-a9d8-066e0dd5cffd@github.com>

On Tue, 14 Mar 2023 10:41:26 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1228:
> 
>> 1226:          * Constructor.
>> 1227:          *
>> 1228:          * @param cs      comment style
> 
> it seems like javadoc for parameter `cs` should be restored as it is still part of the parameter list

Updating

-------------

PR: https://git.openjdk.org/jdk/pull/12953

From jlaskey at openjdk.org  Fri Mar 17 16:27:10 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 17 Mar 2023 16:27:10 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v2]
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Corrections from review
 - Merge branch 'master' into 8303912
 - Clean up JavadocTokenizer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12953/files
  - new: https://git.openjdk.org/jdk/pull/12953/files/652fcd8e..e3e31d09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=00-01

  Stats: 80523 lines in 781 files changed: 45055 ins; 21180 del; 14288 mod
  Patch: https://git.openjdk.org/jdk/pull/12953.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12953/head:pull/12953

PR: https://git.openjdk.org/jdk/pull/12953

From aturbanov at openjdk.org  Fri Mar 17 16:44:29 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Mar 2023 16:44:29 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v2]
In-Reply-To: <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
Message-ID: <lKQ61t-jsCi6aogmXFs3ZdEWvcvUYgA0JKGcgmHfVK0=.5681bb8e-56b0-4004-85a1-3ca5717a2f94@github.com>

On Fri, 17 Mar 2023 16:27:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Corrections from review
>  - Merge branch 'master' into 8303912
>  - Clean up JavadocTokenizer

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/UnicodeReader.java line 116:

> 114:      * @param length  length of meaningful content in buffer.
> 115:      */
> 116:     protected  UnicodeReader(Log log, char[] array, int length) {

One space missed :)
Suggestion:

    protected UnicodeReader(Log log, char[] array, int length) {

-------------

PR: https://git.openjdk.org/jdk/pull/12953

From jlu at openjdk.org  Fri Mar 17 20:28:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 20:28:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust CF test to read in with UTF-8 to fix failing test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=02-03

  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From angorya at openjdk.org  Fri Mar 17 20:34:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Mar 2023 20:34:00 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:

> 224:         Properties p = new Properties();
> 225:         try {
> 226:             FileInputStream input = new FileInputStream(propertiesPath);

Should this stream be closed in a finally { } block?

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Fri Mar 17 20:56:08 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 17 Mar 2023 20:56:08 GMT
Subject: Integrated: 8180387: com.sun.source.util.JavacTask should have a
 protected constructor.
In-Reply-To: <lq04YMXJ7VA9ysvHpFn-1L9oXUFV-0fkZ8_MvfuxBGw=.9111b78e-41d5-4314-96d6-726a5afcac05@github.com>
References: <lq04YMXJ7VA9ysvHpFn-1L9oXUFV-0fkZ8_MvfuxBGw=.9111b78e-41d5-4314-96d6-726a5afcac05@github.com>
Message-ID: <axjoXclPJ9fE_eQnIhA8Dozo1D62ZnkU5AvP6jQ5zw8=.78de68d2-4337-4f44-ad6c-c41873039fc3@github.com>

On Tue, 7 Feb 2023 21:25:28 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Standard practice is for constructors in `abstract` classes to be `protected` rather than `public` because they can't be used except from subclasses.
> 
> [JDK-8180387](https://bugs.openjdk.org/browse/JDK-8180387) was filed to address a particular instance of this phenomenon in the class `com.sun.source.util.JavacTask`.

This pull request has now been integrated.

Changeset: b085ab93
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b085ab9316ed7a25b4981e05210299be50eb7ccd
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8180387: com.sun.source.util.JavacTask should have a protected constructor.

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12462

From naoto at openjdk.org  Fri Mar 17 21:05:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Mar 2023 21:05:18 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
Message-ID: <qJO-EntPnPd5u6rdRknlaAFlfED0JHmr5CXahe0N4oY=.fae98578-e8b4-4387-bd72-acf3cf871a40@github.com>

On Fri, 17 Mar 2023 20:31:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:
> 
>> 224:         Properties p = new Properties();
>> 225:         try {
>> 226:             FileInputStream input = new FileInputStream(propertiesPath);
> 
> Should this stream be closed in a finally { } block?

or better be `try-with-resources`?

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From weijun at openjdk.org  Fri Mar 17 21:52:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:52:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:

> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
> 326:                         outBuffer.append(toHex(aChar & 0xF));

Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From weijun at openjdk.org  Fri Mar 17 21:56:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:56:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
Message-ID: <whhHbwzCZGIvBavtXFqc5Ari9SWIQg-BwdyP3t89Rcg=.d8dc3f56-857d-4265-a54d-9fdb5a59c96a@github.com>

On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:
> 
>> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
>> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
>> 326:                         outBuffer.append(toHex(aChar & 0xF));
> 
> Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

I probably understand it now, source code still needs escaping. When can we put in UTF-8 there as well?

-------------

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Fri Mar 17 22:09:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 17 Mar 2023 22:09:36 GMT
Subject: Integrated: 8015831: Add lint check for calling overridable methods
 from a constructor
In-Reply-To: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
References: <Ms3zM2qC_QYF8OrfQ4mAi1weE5cHGfWCzPgwuxTLBKY=.d383ef5c-10d7-42de-8be0-03dd64a11af0@github.com>
Message-ID: <W8rtGkBNzSej3xjyy3Kk48y0l4SNHNQrhfIO1zrxJ3o=.0dfc99b1-0b83-4488-9fcf-6664fa375a57@github.com>

On Fri, 6 Jan 2023 02:20:53 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This PR adds a new lint warning category `this-escape`.
> 
> It also adds `@SuppressWarnings` annotations as needed to the JDK itself to allow the JDK to continue to compile with `-Xlint:all`.
> 
> A 'this' escape warning is generated for a constructor `A()` in a class `A` when the compiler detects that the following situation is _in theory possible:_
> * Some subclass `B extends A` exists, and `B` is defined in a separate source file (i.e., compilation unit)
> * Some constructor `B()` of `B` invokes `A()` as its superclass constructor
> * During the execution of `A()`, some non-static method of `B.foo()` could get invoked, perhaps indirectly
> 
> In the above scenario, `B.foo()` would execute before `A()` has returned and before `B()` has performed any initialization. To the extent `B.foo()` accesses any fields of `B` - all of which are still uninitialized - it is likely to function incorrectly.
> 
> Note, when determining if a 'this' escape is possible, the compiler makes no assumptions about code outside of the current compilation unit. It doesn't look outside of the current source file to see what might actually happen when a method is invoked. It does follow method and constructors within the current compilation unit, and applies a simplified union-of-all-possible-branches data flow analysis to see where 'this' could end up.
> 
> From my review, virtually all of the warnings generated in the various JDK modules are valid warnings in the sense that a 'this' escape, as defined above, is really and truly possible. However, that doesn't imply that any bugs were found within the JDK - only that the possibility of a certain type of bug exists if certain superclass constructors are used by someone, somewhere, someday.
> 
> For several "popular" classes, this PR also adds `@implNote`'s to the offending constructors so that subclass implementors are made aware of the threat. For one example, `TreeMap(Map)` invokes `putAll()` and `put()`.
> 
> More details and a couple of motivating examples are given in an included [doc file](https://github.com/archiecobbs/jdk/blob/ThisEscape/src/java.base/share/classes/java/lang/doc-files/ThisEscape.html) that these `@implNote`'s link to. See also the recent thread on `amber-dev` for some background.
> 
> Ideally, over time the owners of the various modules would review their `@SuppressWarnings("this-escape")` annotations and determine which other constructors also warranted such an `@implNote`.
> 
> Because of all the`@SuppressWarnings` annotations, this PR touches a bunch of different JDK modules. My apologies for that. Adding these annotations was determined to be the more conservative approach, as compared to just excepting `this-escape` from various module builds globally.
> 
> **Patch Navigation Guide**
> 
> * Non-trivial compiler changes:
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/code/Types.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/tree/TreeInfo.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/comp/ThisEscapeAnalyzer.java`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties`
>     * `src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties`
> 
> * Javadoc additions of `@implNote`:
> 
>     * `src/java.base/share/classes/java/io/PipedReader.java`
>     * `src/java.base/share/classes/java/io/PipedWriter.java`
>     * `src/java.base/share/classes/java/lang/Throwable.java`
>     * `src/java.base/share/classes/java/util/ArrayDeque.java`
>     * `src/java.base/share/classes/java/util/EnumMap.java`
>     * `src/java.base/share/classes/java/util/HashSet.java`
>     * `src/java.base/share/classes/java/util/Hashtable.java`
>     * `src/java.base/share/classes/java/util/LinkedList.java`
>     * `src/java.base/share/classes/java/util/TreeMap.java`
>     * `src/java.base/share/classes/java/util/TreeSet.java`
> 
> * New unit tests
>     * `test/langtools/tools/javac/warnings/ThisEscape/*.java`
> 
> * **Everything else** is just adding `@SuppressWarnings("this-escape")`

This pull request has now been integrated.

Changeset: 8f5bb538
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f5bb538aba42bffb9611546a18f14eb2ea82b70
Stats:     2295 lines in 54 files changed: 2263 ins; 0 del; 32 mod

8015831: Add lint check for calling overridable methods from a constructor
6557145: Warn about calling abstract methods in constructors

Reviewed-by: ihse, vromero, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/11874

From duke at openjdk.org  Fri Mar 17 22:15:32 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 17 Mar 2023 22:15:32 GMT
Subject: Integrated: 8014021: TreeMaker.Params behaves inconsistently when the
 owning method has the same number of parameters as the number of
 parameter types requested
In-Reply-To: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
References: <BzhNJqqlKr5rhox4c1v1B2w6PBidy2Mgi-UyRs1EhSk=.ff2fdae6-3e08-46e4-83a0-adf1bafa0126@github.com>
Message-ID: <OaS87Tt0n_ShvXuVunf8kbig6OGQgIPFL8UiaGlPRlg=.a04125a1-4214-42b1-a084-16e362587d43@github.com>

On Sat, 18 Feb 2023 01:59:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The method `TreeMaker.Params` has what appears to be strange behavior: normally it creates parameters of the types passed in. However, if the given owner is a method, and the method happens to have the same number of parameters as the number of parameters requested, then the types of the owner method's parameters are used instead. This is weird and confusing.
> 
> What's really going on is that a method owner is _always_ being passed in, and when that method has parameters defined, there are _always_ exactly as many of them as there are types provided.
> 
> So what this method is really doing is just reusing the same symbols for the methods parameters if the method has them defined, otherwise creating the same number of placeholder parameters `x0`, `x1`, `x2`, etc.
> 
> This patch refactors this method and clarifies its usage to eliminate the confusion.

This pull request has now been integrated.

Changeset: 254288a5
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/254288a518ee1d6d486a96c1883e569fa7e95a68
Stats:     21 lines in 2 files changed: 7 ins; 0 del; 14 mod

8014021: TreeMaker.Params behaves inconsistently when the owning method has the same number of parameters as the number of parameter types requested

Reviewed-by: vromero, jlahoda

-------------

PR: https://git.openjdk.org/jdk/pull/12627

From jlu at openjdk.org  Fri Mar 17 22:27:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 22:27:48 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Close streams when finished loading into props

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=03-04

  Stats: 15 lines in 3 files changed: 6 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12726/head:pull/12726

PR: https://git.openjdk.org/jdk/pull/12726

From duke at openjdk.org  Sat Mar 18 00:32:34 2023
From: duke at openjdk.org (duke)
Date: Sat, 18 Mar 2023 00:32:34 GMT
Subject: Withdrawn: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <hS03VVIKN0rlXoaNvcDO4n6V5LcLfmsRo8ZIHyY8EGM=.b4aa83bf-fedb-4653-8d64-80350acd775f@github.com>

On Thu, 20 Oct 2022 15:46:01 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/10797

From vromero at openjdk.org  Sat Mar 18 04:10:20 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Mar 2023 04:10:20 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
Message-ID: <VoutMj_R4pPm17gqDloHC4BittWE4s4i_SwGaGiOLMo=.273de563-2a84-442b-9031-2d927b56c893@github.com>

On Tue, 7 Mar 2023 00:44:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.

I think this one needs a CSR as this fix could provoke binary incompatibilities

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 109:

> 107:     public enum Version {
> 108:         V45_3(45, 3), // base level for all attributes
> 109:         V48(48, 0),   // JDK 1.4

not sure why we are referring to a previous version

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From davidalayachew at gmail.com  Sat Mar 18 06:26:21 2023
From: davidalayachew at gmail.com (David Alayachew)
Date: Sat, 18 Mar 2023 02:26:21 -0400
Subject: Could someone take another look at my submitted bug regarding
 class names?
In-Reply-To: <CANSoFxs=y9fvVdzAVZz9S2fhXdeQMQNhFjon0yLr44JOnOVG5Q@mail.gmail.com>
References: <CAA9v-_Pg5NiiR0gsJTzd5t0QPn5Oi0r3Lc=nJFQVYKGAPrSWEg@mail.gmail.com>
 <CANSoFxtSbxoLTZo+eaXMdqXZOc+sRZ7c=MV=08fm6wAQWGC_ZA@mail.gmail.com>
 <CAA9v-_Os4Mhr8JYx8c8oK7B1TA54X7=puFd8D1=g25bvV=3XnQ@mail.gmail.com>
 <CANSoFxsW7-oe=j2qiFb=W11qx8kf+-rYZyBdd=AL5VbnantF5Q@mail.gmail.com>
 <CAA9v-_MVVVip4v_VmGb311dWM9wWBOJESWk8dwD0fhQ0w9Y_=w@mail.gmail.com>
 <CANSoFxvccRLmyJO9tY3WrVXm1MKaGBfxTrre+-XPh=fTJvvRKg@mail.gmail.com>
 <CAA9v-_PeFUFy9-RetcDPKDcrjX5KQWw7Y3PCuFDuEDAfTpyeWw@mail.gmail.com>
 <CANSoFxs=y9fvVdzAVZz9S2fhXdeQMQNhFjon0yLr44JOnOVG5Q@mail.gmail.com>
Message-ID: <CAA9v-_OZiSw2j5_1qSdr5RbTK=Q8MwO--3z4jcEgAFQ3L1gVGQ@mail.gmail.com>

Hello Archie,

Thank you for your response, and apologies on the delay in mine.

I definitely understand what you are talking about now. I also see why you
were considering the zip file solution earlier on.

I will give this some thought and prototype some ideas, but it definitely
looks like there isn't a clean way out of this. Still, this answers my
question and gives a lot of clarity for how the compiler creates .class
files.

Thank you for your help and insight!
David Alayachew

On Mon, Feb 20, 2023, 1:32 PM Archie Cobbs <archie.cobbs at gmail.com> wrote:

> On Mon, Feb 20, 2023 at 12:26 PM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
>> > yes your idea would solve the problem, but at the expense of backward
>> compatibility.
>>
>> Could you explain how the solution is backwards incompatible? I don't
>> think I understand.
>>
>
> You're talking about changing the mapping that takes a Java class name and
> returns the corresponding filename for that class' classfile in the
> filesystem. This means classes that used to load successfully would
> suddenly fail to load because the file would no longer be found.
>
> Even if you tried to use some kind of fallback scheme, you'd still be
> potentially creating filename clashes with other classes, etc.
>
>
>> > As Jon points out that would be "an incompatible change of seismic
>> proportions".
>>
>> I think I missed Jon's comment. Could you paste/link his comment here?
>>
>
> https://mail.openjdk.org/pipermail/compiler-dev/2023-February/022232.html
>
> -Archie
>
> --
> Archie L. Cobbs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230318/359ff550/attachment.htm>

From duke at openjdk.org  Sat Mar 18 17:35:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Mar 2023 17:35:28 GMT
Subject: Integrated: 7016187: `javac -h` could generate conflict .h for inner
 class and class name with '_'
In-Reply-To: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
References: <TjKjaZLrq5AnmfxbBfv7Yr29TRkl7p_egrz8AzCTGf8=.c5953e6d-6ff2-4a4f-8327-a3cc956a3e0b@github.com>
Message-ID: <Mnk-3IttuMcE6fuavOl00PEuo3Eowap3-seeU6ued-g=.9f907b4f-8e0e-4484-9460-ad991952bec7@github.com>

On Thu, 16 Feb 2023 17:49:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> Consider these two classes:
> 
> public class Foo_Bar {
>     public static native void method();
> }
> 
> 
> public class Foo {
>     public static class Bar {
>         public static native void method();
>     }
> }
> 
> If you run `javac -h` to generate native header files, classes `Foo_Bar` and `Foo$Bar` will want to generate the same native header file `Foo_Bar.h`.
> 
> Currently, javac does not detect this situation, so in effect you get a "last writer wins" situation.
> 
> This patch causes compilation to fail instead in this case with an error like this:
> 
> Foo.java:2: error: error while writing Bar: native header file collision between Foo_Bar and Foo$Bar (both generate Foo_Bar.h)
>     public static class Bar {
>                   ^
> 1 error

This pull request has now been integrated.

Changeset: e339e183
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e339e183c1d60e494d266bac0c2ec05c1ec30cc6
Stats:     42 lines in 2 files changed: 38 ins; 0 del; 4 mod

7016187: `javac -h` could generate conflict .h for inner class and class name with '_'

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12602

From duke at openjdk.org  Sat Mar 18 17:52:11 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Mar 2023 17:52:11 GMT
Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831
Message-ID: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>

The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail.

This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it.

-------------

Commit messages:
 - Add @SuppressWarnings("this-escape") annotations needed by 'bootcycle' build.
 - Merge branch 'master' into ThisEscape
 - Relax warning to apply only if subclass could exist in another module/package.
 - Tweaks to man page.
 - Add YieldRef to Javadoc algorithm summary.
 - Document the this-escape lint option in the javac(1) man page.
 - Omit sealed classes when permitted subclasses are in the compilation unit.
 - Add assertion check for reuse of analyzer, which is unsupported.
 - Include assert detail expressions in the analysis.
 - Use more modern patterned instanceof instead of hasTag() + cast.
 - ... and 83 more: https://git.openjdk.org/jdk/compare/7503ecc0...28182104

Changes: https://git.openjdk.org/jdk/pull/13089/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13089&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304443
  Stats: 74 lines in 63 files changed: 71 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13089.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13089/head:pull/13089

PR: https://git.openjdk.org/jdk/pull/13089

From duke at openjdk.org  Sat Mar 18 18:04:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 18 Mar 2023 18:04:20 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <VoutMj_R4pPm17gqDloHC4BittWE4s4i_SwGaGiOLMo=.273de563-2a84-442b-9031-2d927b56c893@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
 <VoutMj_R4pPm17gqDloHC4BittWE4s4i_SwGaGiOLMo=.273de563-2a84-442b-9031-2d927b56c893@github.com>
Message-ID: <4fDdg-f7NiqBmtQk2XSEHDoAympPrAsrabMBfkUnV_o=.71fed86b-577c-4891-9f35-01d33cf62476@github.com>

On Sat, 18 Mar 2023 04:05:12 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I think this one needs a CSR as this fix could provoke binary incompatibilities

Good point - thanks. I'll add it.

> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 109:
> 
>> 107:     public enum Version {
>> 108:         V45_3(45, 3), // base level for all attributes
>> 109:         V48(48, 0),   // JDK 1.4
> 
> not sure why we are referring to a previous version

Here's why: Part of this change is to disallow encodings that are longer than necessary, for example, encoding the character `0x0100` as `e0 84 80` instead of `c4 80`. This is in accordance with the current JVMS.

However, classfiles prior to major version 48 were allowed to contain longer-than-necessary character encodings - most likely, I'm guessing, because of insufficiently strict validation in the early JVM implementations. So when we are parsing a UTF-8 sequence in a classfile, we need to know whether the classfile's major version is before or after 48 to know whether or not we should allow such longer-than-necessary character encodings. If we didn't do this, then we might incorrectly break a compilation where someone was compiling against some very old classfiles.

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From vromero at openjdk.org  Sat Mar 18 18:29:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Mar 2023 18:29:21 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <4fDdg-f7NiqBmtQk2XSEHDoAympPrAsrabMBfkUnV_o=.71fed86b-577c-4891-9f35-01d33cf62476@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
 <VoutMj_R4pPm17gqDloHC4BittWE4s4i_SwGaGiOLMo=.273de563-2a84-442b-9031-2d927b56c893@github.com>
 <4fDdg-f7NiqBmtQk2XSEHDoAympPrAsrabMBfkUnV_o=.71fed86b-577c-4891-9f35-01d33cf62476@github.com>
Message-ID: <QAzFTO1NxvyUOe4xpB_YqtEKRr3JqXrxaCUFhTO2xzE=.5a7f8125-43e6-482b-9654-82720c75cfc9@github.com>

On Sat, 18 Mar 2023 18:01:02 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java line 109:
>> 
>>> 107:     public enum Version {
>>> 108:         V45_3(45, 3), // base level for all attributes
>>> 109:         V48(48, 0),   // JDK 1.4
>> 
>> not sure why we are referring to a previous version
>
> Here's why: Part of this change is to disallow encodings that are longer than necessary, for example, encoding the character `0x0100` as `e0 84 80` instead of `c4 80`. This is in accordance with the current JVMS.
> 
> However, classfiles prior to major version 48 were allowed to contain longer-than-necessary character encodings - most likely, I'm guessing, because of insufficiently strict validation in the early JVM implementations. So when we are parsing a UTF-8 sequence in a classfile, we need to know whether the classfile's major version is before or after 48 to know whether or not we should allow such longer-than-necessary character encodings. If we didn't do this, then we might incorrectly break a compilation where someone was compiling against some very old classfiles.

I see your point is that those class files (version >= 48) won't be accepted by the JVM anyway

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From vromero at openjdk.org  Sat Mar 18 18:29:24 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Mar 2023 18:29:24 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
Message-ID: <dVzA5KO2ybn0Sk46mqa9WL18ES_3Y_lzM7OlM9WBl58=.5d301906-9485-4615-acda-a79b9d0ae0fb@github.com>

On Tue, 7 Mar 2023 00:44:47 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/InvalidUtfException.java line 34:

> 32:  * @see Convert#utfValidate
> 33:  */
> 34: public class InvalidUtfException extends Exception {

I think we should add the proverbial disclaimer: `This is NOT part of any supported API.`, etc

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From vromero at openjdk.org  Sat Mar 18 18:50:18 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Mar 2023 18:50:18 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <QAzFTO1NxvyUOe4xpB_YqtEKRr3JqXrxaCUFhTO2xzE=.5a7f8125-43e6-482b-9654-82720c75cfc9@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
 <VoutMj_R4pPm17gqDloHC4BittWE4s4i_SwGaGiOLMo=.273de563-2a84-442b-9031-2d927b56c893@github.com>
 <4fDdg-f7NiqBmtQk2XSEHDoAympPrAsrabMBfkUnV_o=.71fed86b-577c-4891-9f35-01d33cf62476@github.com>
 <QAzFTO1NxvyUOe4xpB_YqtEKRr3JqXrxaCUFhTO2xzE=.5a7f8125-43e6-482b-9654-82720c75cfc9@github.com>
Message-ID: <vUrT5TjduYTKI8UFrwvoEOR8aGn1FJqReYPvFwiH7uc=.252f2376-f6e8-4163-82f9-ed9f77c4f1cb@github.com>

On Sat, 18 Mar 2023 18:26:06 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Here's why: Part of this change is to disallow encodings that are longer than necessary, for example, encoding the character `0x0100` as `e0 84 80` instead of `c4 80`. This is in accordance with the current JVMS.
>> 
>> However, classfiles prior to major version 48 were allowed to contain longer-than-necessary character encodings - most likely, I'm guessing, because of insufficiently strict validation in the early JVM implementations. So when we are parsing a UTF-8 sequence in a classfile, we need to know whether the classfile's major version is before or after 48 to know whether or not we should allow such longer-than-necessary character encodings. If we didn't do this, then we might incorrectly break a compilation where someone was compiling against some very old classfiles.
>
> I see your point is that those class files (version >= 48) won't be accepted by the JVM anyway

I was checking hotspot code in particular method: `UTF8::is_legal_utf8` at file `src/hotspot/share/utilities/utf8.cpp` and yes if the major version is < 48 the VM will pardon that class file :)

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From vromero at openjdk.org  Sat Mar 18 23:20:21 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sat, 18 Mar 2023 23:20:21 GMT
Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831
In-Reply-To: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
References: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
Message-ID: <OJ1aZjKhSlPzWZH_GqwKPPkcVcmNNcZRU6NUG15GNMY=.de3926b7-3758-4b1c-bd6f-1bcf6af8f173@github.com>

On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail.
> 
> This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it.

change looks good, rerunning the tests to double check

-------------

PR: https://git.openjdk.org/jdk/pull/13089

From jjg at openjdk.org  Sun Mar 19 00:19:15 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Sun, 19 Mar 2023 00:19:15 GMT
Subject: RFR: JDK-8304433: cleanup sentence breaker code in DocTreeMaker
Message-ID: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>

Please review a localized cleanup of the code in `DocTreeMaker` to split a description into the _first sentence_ and _the rest_.

There are two main aspects to the refactoring:

1. All the related code is moved into a new nested class, `SentenceBreaker`, within `DocTreeMaker`. This provides a stronger distinction between that code and the other, primary methods in `DocTreeMaker` that implement `DocTreeFactory`.

2. The use of casts is improved to reduce the overall number required. In particular, the `cast` method is used early on to convert `List<DocTree>` to `List<DCTree>`. This is similar to existing usage of that method elsewhere.

There are no significant changes in functionality.   There is just one small observable difference, detected by one of the tests.  The refactored code uses `List.of()` for an empty list; the older code used empty `javac` `List` objects. This was detected in a test that uses reflection to verify the result of scanning a tree, and the reflective check was for `javac` `List` objects (only).  The fix in the test is to just remove the import for `javac.util.List` and rely on the import for `List` in `java.util.*`, which picks up `java.util.List`, and which is a supertype of `javac` `List`.

There is followup work that could be done, but is deferred to keep this change simpler and cleaner, with no significant change in functionality.

1. The handling of HTML tags in the first sentence is "less than ideal" and could be improved. In particular, most block tags, including lists and tables, do not terminate the first sentence, and could even lead to incorrect partitioning and downstream HTML generation. Presumably, this does not occur in practice.  Related: the code that ignores `EndElement` tags in the first position also seems suspect.

2. When a `List<DocTree>` is split, the two partial lists use `javac` `List`s, not standard lists. This does have the benefit that such lists are immutable by design.   That being said, it might be worth looking at the possibility of using unmodifiable "standard" lists instead.

-------------

Commit messages:
 - JDK-8304433: cleanup sentence breaker code in DocTreeMaker

Changes: https://git.openjdk.org/jdk/pull/13091/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13091&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304433
  Stats: 282 lines in 2 files changed: 86 ins; 71 del; 125 mod
  Patch: https://git.openjdk.org/jdk/pull/13091.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13091/head:pull/13091

PR: https://git.openjdk.org/jdk/pull/13091

From vromero at openjdk.org  Sun Mar 19 02:44:22 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Sun, 19 Mar 2023 02:44:22 GMT
Subject: RFR: 8304443: bootcycle builds fail after JDK-8015831
In-Reply-To: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
References: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
Message-ID: <FVBfbu8wO8jbHJIZzsinTCStW7pbNZYnmzqcbNhqQs4=.db414789-c33e-4d0a-a332-96e1b0be8909@github.com>

On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail.
> 
> This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it.

looks good, thanks!

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13089

From duke at openjdk.org  Mon Mar 20 14:04:53 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 14:04:53 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code
Message-ID: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>

This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.

This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:

public class Test {
    interface Cafe\u0301 {
    }
    interface Caf\u00e9 {
    }
}

The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.

It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:

$ javac --help-extra
  ...
  --detect-output-file-clashes
        Generate an error if any output file is overwritten during compilation. This can occur, for example,
        on case-insensitive filesystems. This applies to class files, native header files, and source files.
  ...
$ javac --detect-output-file-clashes Test.java
Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
    interface Caf\u00e9 {
    ^
1 error

This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.

**Outstanding Questions**
* Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
* Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

-------------

Commit messages:
 - Add new javac flag "--detect-output-file-clashes".

Changes: https://git.openjdk.org/jdk/pull/12754/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296656
  Stats: 230 lines in 6 files changed: 228 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Mon Mar 20 14:37:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 14:37:28 GMT
Subject: Integrated: 8304443: bootcycle builds fail after JDK-8015831
In-Reply-To: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
References: <BGmsNaqGmFOI-6aLXtY7PDf8Y8zgbWdZ6SNU9veiSSk=.1f4b12df-bcb8-4e92-a229-e3f46866f1e8@github.com>
Message-ID: <PRzTZZg0XTJnUpz3xsCyx794Qe51OiQjRE3KVKNAkzM=.1a0eadac-762f-4e54-a607-83eda801ea30@github.com>

On Sat, 18 Mar 2023 17:46:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The fix for JDK-8015831, which added the new `this-escape` lint warning, caused the build of the `bootcycle-images` make target to fail.
> 
> This commit adds the additional `@SuppressWarnings("this-escape")` annotations needed to fix it.

This pull request has now been integrated.

Changeset: c396f1ed
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c396f1ed8b91b799fdd6a9a849d7407e606227d5
Stats:     74 lines in 63 files changed: 71 ins; 0 del; 3 mod

8304443: bootcycle builds fail after JDK-8015831

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13089

From hannesw at openjdk.org  Mon Mar 20 14:55:48 2023
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Mon, 20 Mar 2023 14:55:48 GMT
Subject: RFR: JDK-8304433: cleanup sentence breaker code in DocTreeMaker
In-Reply-To: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>
References: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>
Message-ID: <NEIEpgohGqpsX3Ip22nsoWwT5yWPpDCpwTo9v8pLRzM=.63946fc9-0d9b-4e66-99f8-4f4f5dd8a6a6@github.com>

On Sun, 19 Mar 2023 00:12:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a localized cleanup of the code in `DocTreeMaker` to split a description into the _first sentence_ and _the rest_.
> 
> There are two main aspects to the refactoring:
> 
> 1. All the related code is moved into a new nested class, `SentenceBreaker`, within `DocTreeMaker`. This provides a stronger distinction between that code and the other, primary methods in `DocTreeMaker` that implement `DocTreeFactory`.
> 
> 2. The use of casts is improved to reduce the overall number required. In particular, the `cast` method is used early on to convert `List<DocTree>` to `List<DCTree>`. This is similar to existing usage of that method elsewhere.
> 
> There are no significant changes in functionality.   There is just one small observable difference, detected by one of the tests.  The refactored code uses `List.of()` for an empty list; the older code used empty `javac` `List` objects. This was detected in a test that uses reflection to verify the result of scanning a tree, and the reflective check was for `javac` `List` objects (only).  The fix in the test is to just remove the import for `javac.util.List` and rely on the import for `List` in `java.util.*`, which picks up `java.util.List`, and which is a supertype of `javac` `List`.
> 
> There is followup work that could be done, but is deferred to keep this change simpler and cleaner, with no significant change in functionality.
> 
> 1. The handling of HTML tags in the first sentence is "less than ideal" and could be improved. In particular, most block tags, including lists and tables, do not terminate the first sentence, and could even lead to incorrect partitioning and downstream HTML generation. Presumably, this does not occur in practice.  Related: the code that ignores `EndElement` tags in the first position also seems suspect.
> 
> 2. When a `List<DocTree>` is split, the two partial lists use `javac` `List`s, not standard lists. This does have the benefit that such lists are immutable by design.   That being said, it might be worth looking at the possibility of using unmodifiable "standard" lists instead.

Looks good to me. Took some time to step through old and new code because of many subtle changes, but that's the purpose of a cleanup I guess. ?

-------------

Marked as reviewed by hannesw (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13091

From jlahoda at openjdk.org  Mon Mar 20 14:57:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Mar 2023 14:57:41 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after JDK-8015831
 Add lint check for calling overridable methods from a constructor
Message-ID: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>

`this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

-------------

Commit messages:
 - JDK-8304537: Ant-based langtools build fails after JDK-8015831 Add lint check for calling overridable methods from a constructor

Changes: https://git.openjdk.org/jdk/pull/13102/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13102&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304537
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13102/head:pull/13102

PR: https://git.openjdk.org/jdk/pull/13102

From vromero at openjdk.org  Mon Mar 20 15:04:36 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Mar 2023 15:04:36 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
In-Reply-To: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
Message-ID: <yb0I9kRMGrlPWwYCMbpPyNfUpzrEb_C5LV-BVGQobME=.e8074e5c-7532-4a4f-890c-7692e424dbfa@github.com>

On Mon, 20 Mar 2023 14:50:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR: https://git.openjdk.org/jdk/pull/13102

From duke at openjdk.org  Mon Mar 20 15:13:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 15:13:31 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
In-Reply-To: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
Message-ID: <QS7-APnwm6k7Xn4CmRmUBzEk3jHmxewCWy-1WJEhR2o=.a6be7330-f3f7-4335-980c-963277286a43@github.com>

On Mon, 20 Mar 2023 14:50:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

Just a note... the fix for JDK-8304443 adds `@SuppressWarnings("this-escape")` to the compiler code, and that should also fix this bug as a side effect. This PR, which disables the `this-escape` lint warning, works too, of course.

So, just in case you change your mind and choose to NOT disable the `this-escape` lint warning, then for consistency's sake we should also re-enable it for the regular build in `modules/jdk.compiler/Gendata.gmk` and `modules/jdk.compiler/Java.gmk`.

My apologies for using two different approaches to suppressing the warning at different times.

-------------

PR: https://git.openjdk.org/jdk/pull/13102

From jjg at openjdk.org  Mon Mar 20 15:18:01 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 20 Mar 2023 15:18:01 GMT
Subject: Integrated: JDK-8304433: cleanup sentence breaker code in DocTreeMaker
In-Reply-To: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>
References: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>
Message-ID: <9_MDroiTQ4HK2fSn8MqVqHonIX2eEDSGVt_61pSWflw=.2ffdbbe7-3202-4554-8860-88d1fc411265@github.com>

On Sun, 19 Mar 2023 00:12:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a localized cleanup of the code in `DocTreeMaker` to split a description into the _first sentence_ and _the rest_.
> 
> There are two main aspects to the refactoring:
> 
> 1. All the related code is moved into a new nested class, `SentenceBreaker`, within `DocTreeMaker`. This provides a stronger distinction between that code and the other, primary methods in `DocTreeMaker` that implement `DocTreeFactory`.
> 
> 2. The use of casts is improved to reduce the overall number required. In particular, the `cast` method is used early on to convert `List<DocTree>` to `List<DCTree>`. This is similar to existing usage of that method elsewhere.
> 
> There are no significant changes in functionality.   There is just one small observable difference, detected by one of the tests.  The refactored code uses `List.of()` for an empty list; the older code used empty `javac` `List` objects. This was detected in a test that uses reflection to verify the result of scanning a tree, and the reflective check was for `javac` `List` objects (only).  The fix in the test is to just remove the import for `javac.util.List` and rely on the import for `List` in `java.util.*`, which picks up `java.util.List`, and which is a supertype of `javac` `List`.
> 
> There is followup work that could be done, but is deferred to keep this change simpler and cleaner, with no significant change in functionality.
> 
> 1. The handling of HTML tags in the first sentence is "less than ideal" and could be improved. In particular, most block tags, including lists and tables, do not terminate the first sentence, and could even lead to incorrect partitioning and downstream HTML generation. Presumably, this does not occur in practice.  Related: the code that ignores `EndElement` tags in the first position also seems suspect.
> 
> 2. When a `List<DocTree>` is split, the two partial lists use `javac` `List`s, not standard lists. This does have the benefit that such lists are immutable by design.   That being said, it might be worth looking at the possibility of using unmodifiable "standard" lists instead.

This pull request has now been integrated.

Changeset: 80e97972
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/80e979720a052fbc944b0d85ab25daa831942f19
Stats:     282 lines in 2 files changed: 86 ins; 71 del; 125 mod

8304433: cleanup sentence breaker code in DocTreeMaker

Reviewed-by: hannesw

-------------

PR: https://git.openjdk.org/jdk/pull/13091

From jjg at openjdk.org  Mon Mar 20 15:17:59 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 20 Mar 2023 15:17:59 GMT
Subject: RFR: JDK-8304433: cleanup sentence breaker code in DocTreeMaker
In-Reply-To: <NEIEpgohGqpsX3Ip22nsoWwT5yWPpDCpwTo9v8pLRzM=.63946fc9-0d9b-4e66-99f8-4f4f5dd8a6a6@github.com>
References: <dE4bKOYGfFFZGfX5WWIgbESnt3bJbg50abojOUGW0-k=.cfae09ae-a913-40a8-bfd2-9ae59f8fe447@github.com>
 <NEIEpgohGqpsX3Ip22nsoWwT5yWPpDCpwTo9v8pLRzM=.63946fc9-0d9b-4e66-99f8-4f4f5dd8a6a6@github.com>
Message-ID: <aQh1j5KWnRgIml7KXYQNLSoseTfrwfjvtrG2fLC_L1w=.eaef87b6-b94e-4a74-b47f-b07bc2fcc7b3@github.com>

On Mon, 20 Mar 2023 14:53:26 GMT, Hannes Walln?fer <hannesw at openjdk.org> wrote:

> Looks good to me. Took some time to step through old and new code because of many subtle changes, but that's the purpose of a cleanup I guess. ?

Thank you

-------------

PR: https://git.openjdk.org/jdk/pull/13091

From duke at openjdk.org  Mon Mar 20 15:46:05 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 15:46:05 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v3]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <Hu90S1n5Hfa37zrcWQeHAEJJeAMCHbDmGG9tcIk-E9U=.4c67a4a6-997f-4949-9c2c-e4fbd7e62813@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add the standard "This is NOT part of any supported API" warning.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/94dd3db3..62930b59

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=01-02

  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From duke at openjdk.org  Mon Mar 20 15:46:13 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 15:46:13 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v2]
In-Reply-To: <dVzA5KO2ybn0Sk46mqa9WL18ES_3Y_lzM7OlM9WBl58=.5d301906-9485-4615-acda-a79b9d0ae0fb@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Ci2qyzGyrsDf3KP1ZOrS3FIkj96FzJN9-zyTEgoTAxk=.15f6f85e-9b24-4784-9914-7b76f92717ee@github.com>
 <dVzA5KO2ybn0Sk46mqa9WL18ES_3Y_lzM7OlM9WBl58=.5d301906-9485-4615-acda-a79b9d0ae0fb@github.com>
Message-ID: <2_qHK5C-7mQWv4ZCWoPe6GlLEDGAgTqbAvw48BIsOmE=.2de2a547-0520-4b42-bcd4-49083836e3f7@github.com>

On Sat, 18 Mar 2023 18:19:14 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/InvalidUtfException.java line 34:
> 
>> 32:  * @see Convert#utfValidate
>> 33:  */
>> 34: public class InvalidUtfException extends Exception {
> 
> I think we should add the proverbial disclaimer: `This is NOT part of any supported API.`, etc

Yep - thanks. Fixed in 62930b59ecd.

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From jlahoda at openjdk.org  Mon Mar 20 16:19:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Mar 2023 16:19:19 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
 [v2]
In-Reply-To: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
Message-ID: <N2ToQRNko5DHbDPmypIAxD0CPZEX6uSld8tVbcoecd0=.f35adbb5-dc00-4e02-a9c9-d683161a1e91@github.com>

> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8304537
 - Suppressing using @SW rather than by command line configuration.
 - JDK-8304537: Ant-based langtools build fails after JDK-8015831 Add lint check for calling overridable methods from a constructor

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/13102/files
  - new: https://git.openjdk.org/jdk/pull/13102/files/0939eaa7..603a60e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=13102&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=13102&range=00-01

  Stats: 382 lines in 73 files changed: 168 ins; 82 del; 132 mod
  Patch: https://git.openjdk.org/jdk/pull/13102.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/13102/head:pull/13102

PR: https://git.openjdk.org/jdk/pull/13102

From jlahoda at openjdk.org  Mon Mar 20 16:19:22 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Mar 2023 16:19:22 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
In-Reply-To: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
Message-ID: <IyPiXD_wdqn2z4j2dCNz3jiRSvDpyJfC4IpeoPLTaHI=.71e65d3b-18f4-4a57-960c-ae29f460899a@github.com>

On Mon, 20 Mar 2023 14:50:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

Thanks, Archie.

So, I've:

 - added a few more @SuppressWarnings, as needed
 - removed the `this-escape` disablement from `jdk.compiler`, `jdk.jdeps` and `jdk.jshell` (because all cases should be suppressed using @SuppressWarnings, I hope)
 - removed the `this-escape` disablement from the langtools build config

-------------

PR: https://git.openjdk.org/jdk/pull/13102

From erikj at openjdk.org  Mon Mar 20 17:03:55 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Mon, 20 Mar 2023 17:03:55 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
 [v2]
In-Reply-To: <N2ToQRNko5DHbDPmypIAxD0CPZEX6uSld8tVbcoecd0=.f35adbb5-dc00-4e02-a9c9-d683161a1e91@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
 <N2ToQRNko5DHbDPmypIAxD0CPZEX6uSld8tVbcoecd0=.f35adbb5-dc00-4e02-a9c9-d683161a1e91@github.com>
Message-ID: <6mL2sBz8yxyI1ZSbMoca7X0rwV6y8Sk_oi5_pSd9XDI=.9836564e-8e6b-4ee0-923b-0ae5816a23c6@github.com>

On Mon, 20 Mar 2023 16:19:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8304537
>  - Suppressing using @SW rather than by command line configuration.
>  - JDK-8304537: Ant-based langtools build fails after JDK-8015831 Add lint check for calling overridable methods from a constructor

Marked as reviewed by erikj (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13102#pullrequestreview-1349018815

From vromero at openjdk.org  Mon Mar 20 17:03:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Mar 2023 17:03:57 GMT
Subject: RFR: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
 [v2]
In-Reply-To: <N2ToQRNko5DHbDPmypIAxD0CPZEX6uSld8tVbcoecd0=.f35adbb5-dc00-4e02-a9c9-d683161a1e91@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
 <N2ToQRNko5DHbDPmypIAxD0CPZEX6uSld8tVbcoecd0=.f35adbb5-dc00-4e02-a9c9-d683161a1e91@github.com>
Message-ID: <DMlYxNba04UsakWqFjAiWV-f-HPmfJRVG4xL8iSeg1A=.c3d6fa7d-1b18-4348-8aaf-1efb6210a90d@github.com>

On Mon, 20 Mar 2023 16:19:19 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into JDK-8304537
>  - Suppressing using @SW rather than by command line configuration.
>  - JDK-8304537: Ant-based langtools build fails after JDK-8015831 Add lint check for calling overridable methods from a constructor

Marked as reviewed by vromero (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13102#pullrequestreview-1349024079

From vladimir.kempik at gmail.com  Mon Mar 20 17:10:14 2023
From: vladimir.kempik at gmail.com (Vladimir Kempik)
Date: Mon, 20 Mar 2023 20:10:14 +0300
Subject: Missaligned memory accesses from JDK
In-Reply-To: <6194F148-F760-407F-961E-180BBDC6AE4F@gmail.com>
References: <29875E09-8B1E-4255-AAED-06305459C872@gmail.com>
 <330a2677.26fa2.186fdec7098.Coremail.yangfei@iscas.ac.cn>
 <6194F148-F760-407F-961E-180BBDC6AE4F@gmail.com>
Message-ID: <F9B8363B-6739-4D3F-8B73-ED795B3F0848@gmail.com>

Adding compiler list.

Could you please suggest on best way to make emit_intX methods not perform misaligned memory stores ?
Talking about src/hotspot/share/asm/codeBuffer.hpp from https://github.com/VladimirKempik/jdk/commit/18d7f399ce1bc213b2495411193938d914d3f616#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae

Regards, Vladimir

> 20 ????? 2023 ?., ? 12:42, Vladimir Kempik <vladimir.kempik at gmail.com> ???????(?):
> 
> 
>>  For each emit_intX functions modified, I see there is a correspondent version which handles unaligned access. For example, 'void emit_int16(uint8_t x1, uint8_t x2)' for 'void emit_int16(uint16_t x)' 
>>  So if we encounter an unaligned access issue when using 'emit_int16(uint16_t x)', shouldn't we change the callsite to use 'emit_int16(uint8_t x1, uint8_t x2)' instead? 
> 
> Hello
> not exactly
> 'void emit_int16(uint8_t x1, uint8_t x2)
> will always use slow version ( store byte)
> 
> but 
> void emit_int16(uint16_t x)
> will use slow version only on unaligned stores. if store is aligned, it will use "store half", which should be faster.
> 
> So we can?t always use emit_int16(uint8_t x1, uint8_t x2) at callsite.
> 
> and we can?t decide which one to use at callsite as callsite should be unaware of end() value inside CodeSection class
> 
> Regards, Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230320/04c4f789/attachment.htm>

From mcimadamore at openjdk.org  Mon Mar 20 17:28:42 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Mar 2023 17:28:42 GMT
Subject: RFR: 8304420: Regression ~11% with Javac-Generates on all platforms in
 b14
Message-ID: <Ay7hseQ6y4pJ_ZYc4q4KK-QfLWchnJid63FUal_twiE=.b714ad75-ea33-41e6-93e9-549c06b6154d@github.com>

This patch fixes a performance regression introduced by  JDK-8303820. The new code for dealing with type metadata makes excessive use of streams and optionals, leading to performance degradation. I've tweaked the code to use plain for loops, and also to use `null` instead of optionals. I've also added a new `getMetadata` method which accepts a map function (if metadata is found) as well as a default value (if metadata is not found) which makes usage from clients similar to just using optionals. This seems to revert performance numbers to what they were before the fix.

-------------

Commit messages:
 - Re-add sealed modifier
 - Drop spurious changes
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/13104/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304420
  Stats: 33 lines in 2 files changed: 17 ins; 2 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/13104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13104/head:pull/13104

PR: https://git.openjdk.org/jdk/pull/13104

From vromero at openjdk.org  Mon Mar 20 17:59:17 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Mar 2023 17:59:17 GMT
Subject: RFR: 8304420: Regression ~11% with Javac-Generates on all
 platforms in b14
In-Reply-To: <Ay7hseQ6y4pJ_ZYc4q4KK-QfLWchnJid63FUal_twiE=.b714ad75-ea33-41e6-93e9-549c06b6154d@github.com>
References: <Ay7hseQ6y4pJ_ZYc4q4KK-QfLWchnJid63FUal_twiE=.b714ad75-ea33-41e6-93e9-549c06b6154d@github.com>
Message-ID: <8_nJTWY-3yzXIHY1YxWR3zVippODvtSxxqk1fA-n_UA=.adb7a317-6edc-4bf0-8bd7-1ccf9c57ffe9@github.com>

On Mon, 20 Mar 2023 16:42:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a performance regression introduced by  JDK-8303820. The new code for dealing with type metadata makes excessive use of streams and optionals, leading to performance degradation. I've tweaked the code to use plain for loops, and also to use `null` instead of optionals. I've also added a new `getMetadata` method which accepts a map function (if metadata is found) as well as a default value (if metadata is not found) which makes usage from clients similar to just using optionals. This seems to revert performance numbers to what they were before the fix.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13104#pullrequestreview-1349127663

From mcimadamore at openjdk.org  Mon Mar 20 18:47:36 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 20 Mar 2023 18:47:36 GMT
Subject: Integrated: 8304420: Regression ~11% with Javac-Generates on all
 platforms in b14
In-Reply-To: <Ay7hseQ6y4pJ_ZYc4q4KK-QfLWchnJid63FUal_twiE=.b714ad75-ea33-41e6-93e9-549c06b6154d@github.com>
References: <Ay7hseQ6y4pJ_ZYc4q4KK-QfLWchnJid63FUal_twiE=.b714ad75-ea33-41e6-93e9-549c06b6154d@github.com>
Message-ID: <l12ogaOSnV8QPGt4ab_BEZJOZnyLXbRw7EVWPgZVETE=.71dd8e60-718f-485d-bf0c-27c159b076ac@github.com>

On Mon, 20 Mar 2023 16:42:00 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This patch fixes a performance regression introduced by  JDK-8303820. The new code for dealing with type metadata makes excessive use of streams and optionals, leading to performance degradation. I've tweaked the code to use plain for loops, and also to use `null` instead of optionals. I've also added a new `getMetadata` method which accepts a map function (if metadata is found) as well as a default value (if metadata is not found) which makes usage from clients similar to just using optionals. This seems to revert performance numbers to what they were before the fix.

This pull request has now been integrated.

Changeset: 42723dcb
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42723dcb1862da598092bb499056940d78a8bdac
Stats:     33 lines in 2 files changed: 17 ins; 2 del; 14 mod

8304420: Regression ~11% with Javac-Generates on all platforms in b14

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13104

From maurizio.cimadamore at oracle.com  Mon Mar 20 19:05:03 2023
From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore)
Date: Mon, 20 Mar 2023 19:05:03 +0000
Subject: Missaligned memory accesses from JDK
In-Reply-To: <F9B8363B-6739-4D3F-8B73-ED795B3F0848@gmail.com>
References: <29875E09-8B1E-4255-AAED-06305459C872@gmail.com>
 <330a2677.26fa2.186fdec7098.Coremail.yangfei@iscas.ac.cn>
 <6194F148-F760-407F-961E-180BBDC6AE4F@gmail.com>
 <F9B8363B-6739-4D3F-8B73-ED795B3F0848@gmail.com>
Message-ID: <0b2d8160-e675-b53a-8a74-3c3b23a10277@oracle.com>

Most likely, this is the wrong compiler-dev - I suggest you forward this 
here:

https://mail.openjdk.org/mailman/listinfo/hotspot-compiler-dev

Cheers
Maurizio

On 20/03/2023 17:10, Vladimir Kempik wrote:
> Adding compiler list.
>
> Could you please suggest on best way to make emit_intX methods not perform misaligned memory stores ?
> Talking about src/hotspot/share/asm/codeBuffer.hpp fromhttps://github.com/VladimirKempik/jdk/commit/18d7f399ce1bc213b2495411193938d914d3f616#diff-deb8ab083311ba60c0016dc34d6518579bbee4683c81e8d348982bac897fe8ae
>
> Regards, Vladimir
>
>> 20 ????? 2023 ?., ? 12:42, Vladimir Kempik 
>> <vladimir.kempik at gmail.com> ???????(?):
>>
>>
>>> ?For each emit_intX functions modified, I see there is a 
>>> correspondent version which handles unaligned access. For example, 
>>> 'void emit_int16(uint8_t x1, uint8_t x2)' for 'void 
>>> emit_int16(uint16_t x)'
>>> ?So if we encounter an unaligned access issue when using 
>>> 'emit_int16(uint16_t x)', shouldn't we change the callsite to use 
>>> 'emit_int16(uint8_t x1, uint8_t x2)' instead?
>>
>> Hello
>> not exactly
>> 'void emit_int16(uint8_t x1, uint8_t x2)
>> will always use slow version ( store byte)
>>
>> but
>> void emit_int16(uint16_t x)
>> will use slow version only on unaligned stores. if store is aligned, 
>> it will use "store half", which should be faster.
>>
>> So we can?t always use emit_int16(uint8_t x1, uint8_t x2) at callsite.
>>
>> and we can?t decide which one to use at callsite as callsite should 
>> be unaware of end() value inside?CodeSection class
>>
>> Regards, Vladimir
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230320/5a346ceb/attachment.htm>

From jlaskey at openjdk.org  Mon Mar 20 20:31:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 20 Mar 2023 20:31:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Tidy javadoc
 - Rename StringTemplate classes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d6947fd4..9ba6400d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=44-45

  Stats: 2086 lines in 54 files changed: 874 ins; 1075 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From vromero at openjdk.org  Mon Mar 20 20:55:51 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Mar 2023 20:55:51 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v9]
In-Reply-To: <no9Gh0lJ3DJ48nFVQTXJUwMnDyUKq1bme0AXKyUVk2k=.49bd05e4-24e8-467a-bf42-978c70396360@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <no9Gh0lJ3DJ48nFVQTXJUwMnDyUKq1bme0AXKyUVk2k=.49bd05e4-24e8-467a-bf42-978c70396360@github.com>
Message-ID: <KJWqSBLOogYRVlBqlNDmorKAqPimRkULlF74GGwXKtE=.11e0e9d9-8733-4f44-ad9e-2a604b367a59@github.com>

On Thu, 16 Feb 2023 14:54:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is both a minor optimization and a fix for JDK-7176515.
>> 
>> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
>> 
>> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
>> 
>> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
>> 
>> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
>> 
>> This results in two improvements:
>> * It avoids building the lookup table for switches on self
>> * It fixes JDK-7176515 as stated
>> 
>> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
>> 
>> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
>> 
>> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-7176515
>  - Simplify code a bit by using Map.computeIfAbsent().
>  - Update unit test after fixing 8299760.
>  - Revert 2nd part of previous commit ("Put mapping tables for different...").
>    
>    This should go into a separate branch.
>  - Further refinements to compiler-generated mappings tables for switched-on enums.
>    
>    - No mapping table needed for any Enum class within the same top level class.
>    - Put mapping tables for different enum types into separate synthetic classes.
>  - Merge branch 'master' into JDK-7176515
>  - Merge branch 'master' into JDK-7176515
>  - Give test a better name and don't rely on assertions being enabled.
>  - Skip enum switch lookup tables when compiling the enum switch class.

I'm seeing one test failing with the last version of this patch:

- test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1476919092

From vromero at openjdk.org  Mon Mar 20 21:18:41 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 20 Mar 2023 21:18:41 GMT
Subject: RFR: 8029301: Confusing error message for array creation method
 reference
In-Reply-To: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
References: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
Message-ID: <VHhyor5LXDJNwA4ZeYsAo7QT1iavOExwBmcXi5KST5Y=.13a3262e-0dad-4206-8be6-9b37669bb75d@github.com>

On Mon, 20 Feb 2023 01:55:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The error for an invalid constructor reference of an array type looks like this:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     constructor Array in class Array cannot be applied to given types
>       required: int
>       found:    no arguments
>       reason: actual and formal argument lists differ in length
> 
> The phrase "constructor Array in class Array" is somewhat confusing.
> 
> This is a simple patch to reword this type of error to look like this instead:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     cannot create array from given types
>       required: int
>       found:    no arguments
>       reason:   actual and formal argument lists differ in length

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12646#pullrequestreview-1349411631

From duke at openjdk.org  Mon Mar 20 21:38:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 21:38:37 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v10]
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <mexFzecyxSNxHfiVJwLk6A6u-_W61yxVj8BHeloq6V8=.8afc9a87-370f-4033-acf5-9b87d91f46d2@github.com>

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - Merge branch 'master' into JDK-7176515
 - Merge branch 'master' into JDK-7176515
 - Simplify code a bit by using Map.computeIfAbsent().
 - Update unit test after fixing 8299760.
 - Revert 2nd part of previous commit ("Put mapping tables for different...").
   
   This should go into a separate branch.
 - Further refinements to compiler-generated mappings tables for switched-on enums.
   
   - No mapping table needed for any Enum class within the same top level class.
   - Put mapping tables for different enum types into separate synthetic classes.
 - Merge branch 'master' into JDK-7176515
 - Merge branch 'master' into JDK-7176515
 - Give test a better name and don't rely on assertions being enabled.
 - Skip enum switch lookup tables when compiling the enum switch class.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10797/files
  - new: https://git.openjdk.org/jdk/pull/10797/files/8987541c..e0d4c0e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=08-09

  Stats: 353161 lines in 2732 files changed: 215172 ins; 116146 del; 21843 mod
  Patch: https://git.openjdk.org/jdk/pull/10797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10797/head:pull/10797

PR: https://git.openjdk.org/jdk/pull/10797

From duke at openjdk.org  Mon Mar 20 21:38:42 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 20 Mar 2023 21:38:42 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v9]
In-Reply-To: <no9Gh0lJ3DJ48nFVQTXJUwMnDyUKq1bme0AXKyUVk2k=.49bd05e4-24e8-467a-bf42-978c70396360@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <no9Gh0lJ3DJ48nFVQTXJUwMnDyUKq1bme0AXKyUVk2k=.49bd05e4-24e8-467a-bf42-978c70396360@github.com>
Message-ID: <z_n04_KyYnJr7sMOyHmB-gHHC_S6Bjo7_7RXSGSGELs=.62088e6b-20d7-4192-a034-fc430276322f@github.com>

On Thu, 16 Feb 2023 14:54:00 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is both a minor optimization and a fix for JDK-7176515.
>> 
>> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
>> 
>> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
>> 
>> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
>> 
>> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
>> 
>> This results in two improvements:
>> * It avoids building the lookup table for switches on self
>> * It fixes JDK-7176515 as stated
>> 
>> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
>> 
>> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
>> 
>> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains ten additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-7176515
>  - Simplify code a bit by using Map.computeIfAbsent().
>  - Update unit test after fixing 8299760.
>  - Revert 2nd part of previous commit ("Put mapping tables for different...").
>    
>    This should go into a separate branch.
>  - Further refinements to compiler-generated mappings tables for switched-on enums.
>    
>    - No mapping table needed for any Enum class within the same top level class.
>    - Put mapping tables for different enum types into separate synthetic classes.
>  - Merge branch 'master' into JDK-7176515
>  - Merge branch 'master' into JDK-7176515
>  - Give test a better name and don't rely on assertions being enabled.
>  - Skip enum switch lookup tables when compiling the enum switch class.

I think that's an unrelated test failure:

> STDERR:
> Unrecognized VM option 'UseCompressedClassPointers'
> Error: Could not create the Java Virtual Machine.

But also I believe this problem was fixed a while ago, so I'll merge in the latest `master` shortly and that should make the test failure go away.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1476963363

From vromero at openjdk.org  Tue Mar 21 04:20:02 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 04:20:02 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v12]
In-Reply-To: <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
 <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
Message-ID: <zAQ0KIZRgEf1xRYDI9AstL6BuQAj2j6YGkAnAg2fGjQ=.5416f5e8-f22d-4a02-bf94-3bc7a5e5b790@github.com>

On Mon, 19 Dec 2022 15:44:49 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> (Description revised)
>> 
>> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
>> 
>>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
>> 
>> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8043179
>  - Merge branch 'master' into JDK-8043179
>  - Update failed test output line numbers after removing @author tags.
>  - Remove @author tags from tests.
>  - Add a unit test verifying a change in reported error for final variables.
>    
>    Before this change, compiling this class:
>    
>        class LambdaMutateFinalVar {
>            LambdaMutateFinalVar() {
>                final String x;
>                Runnable r1 = () -> x = "not ok";
>                x = "ok";
>            }
>        }
>    
>    would report this error:
>    
>      local variables referenced from a lambda expression must be final or effectively final
>    
>    That error is not really appropriate; after all, the variable IS final. The
>    real problem is that it can't be assigned from within the lambda because it
>    can't be assumed to be DU.
>    
>    After this change, this error is reported instead:
>    
>      variable x might already have been assigned
>  - Fix previously incorrect logic and update unit tests.
>  - Fix @author in test to match github username per instructions.
>  - Move unit test into a more appropriate subdirectory.
>  - Use /nodynamiccopyright/ for "golden file" test per instructions.
>  - 8043179: Lambda expression can mutate final field

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2860:

> 2858:                 // lambda body may end up being assigned to later on, so we cannot conclude that
> 2859:                 // the variable will be unassigned when the body is executed.
> 2860:                 uninits.excludeFrom(firstadr);

I think this will exclude all tracked variables not only fields, shouldn't we exclude fields only?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10381#discussion_r1142874296

From jlahoda at openjdk.org  Tue Mar 21 07:36:52 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Mar 2023 07:36:52 GMT
Subject: Integrated: JDK-8304537: Ant-based langtools build fails after
 JDK-8015831 Add lint check for calling overridable methods from a constructor
In-Reply-To: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
References: <WNHt9c9DFkPRmHZAH1aSg88tmYHhK8qjOMPdqTxSNh8=.516c211b-4449-4e23-8d56-4931e0958d9e@github.com>
Message-ID: <y5DyH--369qoLEWW3RkPRNdhG2yn-SvvWy237MULlIM=.540efb13-3dad-438e-9ab2-3ddfdabfd872@github.com>

On Mon, 20 Mar 2023 14:50:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `this-escape` lint is disabled for jdk.compiler, so it should be disabled for the ant-based langtools-only build as well.

This pull request has now been integrated.

Changeset: c4df9b5f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c4df9b5f176672617f29bd253f01df2ea81dac36
Stats:     14 lines in 6 files changed: 5 ins; 6 del; 3 mod

8304537: Ant-based langtools build fails after JDK-8015831 Add lint check for calling overridable methods from a constructor

Reviewed-by: vromero, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/13102

From duke at openjdk.org  Tue Mar 21 14:00:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 14:00:36 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v12]
In-Reply-To: <zAQ0KIZRgEf1xRYDI9AstL6BuQAj2j6YGkAnAg2fGjQ=.5416f5e8-f22d-4a02-bf94-3bc7a5e5b790@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
 <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
 <zAQ0KIZRgEf1xRYDI9AstL6BuQAj2j6YGkAnAg2fGjQ=.5416f5e8-f22d-4a02-bf94-3bc7a5e5b790@github.com>
Message-ID: <gsfeX8mfK0VN74vurXOpXph27LDa2U-L3nqSqN4-Dq8=.df5c40bf-37c0-4ed9-a82e-193814c07330@github.com>

On Tue, 21 Mar 2023 04:17:02 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8043179
>>  - Merge branch 'master' into JDK-8043179
>>  - Update failed test output line numbers after removing @author tags.
>>  - Remove @author tags from tests.
>>  - Add a unit test verifying a change in reported error for final variables.
>>    
>>    Before this change, compiling this class:
>>    
>>        class LambdaMutateFinalVar {
>>            LambdaMutateFinalVar() {
>>                final String x;
>>                Runnable r1 = () -> x = "not ok";
>>                x = "ok";
>>            }
>>        }
>>    
>>    would report this error:
>>    
>>      local variables referenced from a lambda expression must be final or effectively final
>>    
>>    That error is not really appropriate; after all, the variable IS final. The
>>    real problem is that it can't be assigned from within the lambda because it
>>    can't be assumed to be DU.
>>    
>>    After this change, this error is reported instead:
>>    
>>      variable x might already have been assigned
>>  - Fix previously incorrect logic and update unit tests.
>>  - Fix @author in test to match github username per instructions.
>>  - Move unit test into a more appropriate subdirectory.
>>  - Use /nodynamiccopyright/ for "golden file" test per instructions.
>>  - 8043179: Lambda expression can mutate final field
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2860:
> 
>> 2858:                 // lambda body may end up being assigned to later on, so we cannot conclude that
>> 2859:                 // the variable will be unassigned when the body is executed.
>> 2860:                 uninits.excludeFrom(firstadr);
> 
> I think this will exclude all tracked variables not only fields, shouldn't we exclude fields only?

This bug refers only to final fields, but JLS section 16 applies to both fields and variables, so I think this code is following the spec as written.

Here's an example of where this change would catch an illegal final variable assignment:

class LambdaMutateFinalVariable {
    void foo() {
        final String x;
        Runnable r1 = () -> x = "not ok";
        x = "ok";
    }
}

So I don't think the code in the PR is wrong. However, there is a subtlety: currently, the compiler already correctly handles the above example, but that's only by coincidence and thanks to the separate logic for "effectively final":

LambdaMutateFinalVariable.java:4: error: local variables referenced from a lambda expression must be final or effectively final
        Runnable r1 = () -> x = "not ok";
                            ^

With the change in this PR, the DA/DU analysis will instead get there first, and so you get a different error:

LambdaMutateFinalVariable.java:4: error: variable x might already have been assigned
        Runnable r1 = () -> x = "not ok";
                            ^

It seems to me either error is appropriate, because the code violates both rules. But I think the change in the error message is actually an improvement, because the current error is complaining about the variable not being final even though it actually *is* final, which is confusing.

Your thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10381#discussion_r1143424072

From vromero at openjdk.org  Tue Mar 21 14:51:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 14:51:52 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v12]
In-Reply-To: <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
 <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
Message-ID: <cSvlWvITeUh2IY690bIwYHhKaHEmQKUo5jXELWV4pgI=.ce60bac4-f56c-4906-b0ec-e4d970aec1da@github.com>

On Mon, 19 Dec 2022 15:44:49 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> (Description revised)
>> 
>> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
>> 
>>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
>> 
>> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8043179
>  - Merge branch 'master' into JDK-8043179
>  - Update failed test output line numbers after removing @author tags.
>  - Remove @author tags from tests.
>  - Add a unit test verifying a change in reported error for final variables.
>    
>    Before this change, compiling this class:
>    
>        class LambdaMutateFinalVar {
>            LambdaMutateFinalVar() {
>                final String x;
>                Runnable r1 = () -> x = "not ok";
>                x = "ok";
>            }
>        }
>    
>    would report this error:
>    
>      local variables referenced from a lambda expression must be final or effectively final
>    
>    That error is not really appropriate; after all, the variable IS final. The
>    real problem is that it can't be assigned from within the lambda because it
>    can't be assumed to be DU.
>    
>    After this change, this error is reported instead:
>    
>      variable x might already have been assigned
>  - Fix previously incorrect logic and update unit tests.
>  - Fix @author in test to match github username per instructions.
>  - Move unit test into a more appropriate subdirectory.
>  - Use /nodynamiccopyright/ for "golden file" test per instructions.
>  - 8043179: Lambda expression can mutate final field

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10381#pullrequestreview-1350669716

From vromero at openjdk.org  Tue Mar 21 14:51:56 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 14:51:56 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v12]
In-Reply-To: <gsfeX8mfK0VN74vurXOpXph27LDa2U-L3nqSqN4-Dq8=.df5c40bf-37c0-4ed9-a82e-193814c07330@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
 <uww6VaA-X-zCasHAiyVrY2fyrYkma0u33MLdZd7c9xM=.795bd5c7-b917-4f0a-afcd-734351279527@github.com>
 <zAQ0KIZRgEf1xRYDI9AstL6BuQAj2j6YGkAnAg2fGjQ=.5416f5e8-f22d-4a02-bf94-3bc7a5e5b790@github.com>
 <gsfeX8mfK0VN74vurXOpXph27LDa2U-L3nqSqN4-Dq8=.df5c40bf-37c0-4ed9-a82e-193814c07330@github.com>
Message-ID: <QgKUW8D44_JxGO8HS8k3tMnP0d-KOM23FAiR6eM_2YQ=.373dcb1b-3647-4fa3-9db6-d54f6a97ca75@github.com>

On Tue, 21 Mar 2023 13:57:46 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2860:
>> 
>>> 2858:                 // lambda body may end up being assigned to later on, so we cannot conclude that
>>> 2859:                 // the variable will be unassigned when the body is executed.
>>> 2860:                 uninits.excludeFrom(firstadr);
>> 
>> I think this will exclude all tracked variables not only fields, shouldn't we exclude fields only?
>
> This bug refers only to final fields, but JLS section 16 applies to both fields and variables, so I think this code is following the spec as written.
> 
> Here's an example of where this change would catch an illegal final variable assignment:
> 
> class LambdaMutateFinalVariable {
>     void foo() {
>         final String x;
>         Runnable r1 = () -> x = "not ok";
>         x = "ok";
>     }
> }
> 
> So I don't think the code in the PR is wrong. However, there is a subtlety: currently, the compiler already correctly handles the above example, but that's only by coincidence and thanks to the separate logic for "effectively final":
> 
> LambdaMutateFinalVariable.java:4: error: local variables referenced from a lambda expression must be final or effectively final
>         Runnable r1 = () -> x = "not ok";
>                             ^
> 
> With the change in this PR, the DA/DU analysis will instead get there first, and so you get a different error:
> 
> LambdaMutateFinalVariable.java:4: error: variable x might already have been assigned
>         Runnable r1 = () -> x = "not ok";
>                             ^
> 
> It seems to me either error is appropriate, because the code violates both rules. But I think the change in the error message is actually an improvement, because the current error is complaining about the variable not being final even though it actually *is* final, which is confusing.
> 
> Your thoughts?

yep I agree that the error message is better with the patch. My concern was not that the patch was wrong but about the fact that we were applying the change for all variables and fields, but yes it probably makes sense to go for this and have the side effect of better error messages

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10381#discussion_r1143507429

From mcimadamore at openjdk.org  Tue Mar 21 14:55:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

I like the new naming scheme!

src/java.base/share/classes/java/lang/StringTemplate.java line 28:

> 26: package java.lang;
> 27: 
> 28: import java.lang.Object;

You might want to do another pass to check for unused imports

src/java.base/share/classes/java/lang/StringTemplate.java line 44:

> 42:  * {@link StringTemplate} is the run-time representation of a string template or
> 43:  * text block template in a template expression.
> 44:  *

Extra newline?

src/java.base/share/classes/java/lang/StringTemplate.java line 56:

> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
> 56:  * first produces an instance of {@link StringTemplate}, representing the template

The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

src/java.base/share/classes/java/lang/StringTemplate.java line 69:

> 67:  * List<Object> values = st.values();
> 68:  * }
> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},

This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

src/java.base/share/classes/java/lang/StringTemplate.java line 324:

> 322:      * assert Objects.equals(sc, "abcxyz");
> 323:      * }
> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first

I was playing with this example in jshell:

jshell> var st1 = RAW."{1}"
st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }

jshell> var st2 = RAW."{2}"
st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }

jshell> StringTemplate.combine(st1, st2);
$7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }


The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:

Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next

I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

src/java.base/share/classes/java/lang/StringTemplate.java line 431:

> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
> 430:      */
> 431:     static final StringProcessor STR = StringTemplate::interpolate;

`static final` is redundant here (we are in an interface)

src/java.base/share/classes/java/lang/StringTemplate.java line 454:

> 452:      * This interface describes the methods provided by a generalized string template processor. The
> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.

nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:

> 45:  */
> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 47: interface ReferenceKey<T> {

This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:

> 224:                         List.nil(), expressions);
> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,

nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:

> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
> 251:             }
> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,

What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:

> 279:             make.at(tree.pos);
> 280: 
> 281:             if (processor == null || isNamedProcessor(names.RAW)) {

is `processor == null` still a thing?

-------------

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1350457321
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143370713
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143371242
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143373826
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143379210
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143441733
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143444292
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143448931
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143484050
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143501675
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143507003
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143487363

From mcimadamore at openjdk.org  Tue Mar 21 14:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>

On Tue, 21 Mar 2023 13:31:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
> 
>> 67:  * List<Object> values = st.values();
>> 68:  * }
>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
> 
> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143387999

From vromero at openjdk.org  Tue Mar 21 16:24:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 16:24:26 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v10]
In-Reply-To: <mexFzecyxSNxHfiVJwLk6A6u-_W61yxVj8BHeloq6V8=.8afc9a87-370f-4033-acf5-9b87d91f46d2@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <mexFzecyxSNxHfiVJwLk6A6u-_W61yxVj8BHeloq6V8=.8afc9a87-370f-4033-acf5-9b87d91f46d2@github.com>
Message-ID: <L-SGlxaNG8eoXDRkPc2Jj86Mef2KfjavdquI18tZts8=.88a450b9-3b21-41b8-bd6d-ef033a065db0@github.com>

On Mon, 20 Mar 2023 21:38:37 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is both a minor optimization and a fix for JDK-7176515.
>> 
>> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
>> 
>> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
>> 
>> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
>> 
>> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
>> 
>> This results in two improvements:
>> * It avoids building the lookup table for switches on self
>> * It fixes JDK-7176515 as stated
>> 
>> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
>> 
>> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
>> 
>> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-7176515
>  - Merge branch 'master' into JDK-7176515
>  - Simplify code a bit by using Map.computeIfAbsent().
>  - Update unit test after fixing 8299760.
>  - Revert 2nd part of previous commit ("Put mapping tables for different...").
>    
>    This should go into a separate branch.
>  - Further refinements to compiler-generated mappings tables for switched-on enums.
>    
>    - No mapping table needed for any Enum class within the same top level class.
>    - Put mapping tables for different enum types into separate synthetic classes.
>  - Merge branch 'master' into JDK-7176515
>  - Merge branch 'master' into JDK-7176515
>  - Give test a better name and don't rely on assertions being enabled.
>  - Skip enum switch lookup tables when compiling the enum switch class.

I'm still seeing test: test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java failing with this patch

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1478162216

From duke at openjdk.org  Tue Mar 21 17:19:23 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 17:19:23 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v11]
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <zD90MurayrTTk6flXt6MWlAN0x6jFTUO1zZN3mAMloM=.85ec70da-3991-44c4-8a9d-7130ea8124eb@github.com>

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Update regression test to not look for classfile no longer being generated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10797/files
  - new: https://git.openjdk.org/jdk/pull/10797/files/e0d4c0e0..e6ef2acf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10797&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/10797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10797/head:pull/10797

PR: https://git.openjdk.org/jdk/pull/10797

From duke at openjdk.org  Tue Mar 21 17:19:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 17:19:25 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v10]
In-Reply-To: <L-SGlxaNG8eoXDRkPc2Jj86Mef2KfjavdquI18tZts8=.88a450b9-3b21-41b8-bd6d-ef033a065db0@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <mexFzecyxSNxHfiVJwLk6A6u-_W61yxVj8BHeloq6V8=.8afc9a87-370f-4033-acf5-9b87d91f46d2@github.com>
 <L-SGlxaNG8eoXDRkPc2Jj86Mef2KfjavdquI18tZts8=.88a450b9-3b21-41b8-bd6d-ef033a065db0@github.com>
Message-ID: <RolLha-ydsTG3D-g1dNdiiHEO8XTcXCOruluG6idfB4=.fdadd701-377b-4a74-97f4-91e04f4e9ccd@github.com>

On Tue, 21 Mar 2023 16:21:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> I'm still seeing test: test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java failing with this patch

Strange... on github everything is passing now: https://github.com/archiecobbs/jdk/actions/runs/4473109724

But when I run that specific test on my laptop, it fails for me too.

So I guess this test is not included in the standard test suite?

In any case should be fixed in e6ef2acf8ae.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1478287604

From jjg at openjdk.org  Tue Mar 21 17:45:49 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 21 Mar 2023 17:45:49 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
 <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
 <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>
Message-ID: <YJc3pW67llK83vVyZyC5qDwQXJGqz1sivZXcbOYl7zc=.2b494770-0fa1-444f-8faa-787a1efb9be9@github.com>

On Sat, 11 Feb 2023 01:30:50 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> test/langtools/tools/javac/diags/examples/ExtraImportSemicolonWarning.java line 26:
>> 
>>> 24: // key: compiler.warn.extraneous.semicolon
>>> 25: // key: compiler.warn.source.no.system.modules.path
>>> 26: // options: --source 20
>> 
>> Please use "--release 20" instead if possible.
>
>> Please use "--release 20" instead if possible.
> 
> Thanks - that works better.

Why is any `--release` option required?   The test should only be run by JDK 20 and later, right?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12448#discussion_r1143783911

From vromero at openjdk.org  Tue Mar 21 17:47:47 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 17:47:47 GMT
Subject: RFR: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables [v3]
In-Reply-To: <v2JGDuFtVhFqCbsczLLl6qFQiOrGw2n--rGF4HbPqQo=.8c3e5415-61e9-40c0-b437-c3fcfa7f2cdf@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
 <v2JGDuFtVhFqCbsczLLl6qFQiOrGw2n--rGF4HbPqQo=.8c3e5415-61e9-40c0-b437-c3fcfa7f2cdf@github.com>
Message-ID: <h4xxSi9eEe0XQ-os_csaU-nNOMfJlGFyxMNKu9ZFnQk=.a0a687f1-3a36-42c0-be20-e5a807a02006@github.com>

On Mon, 19 Dec 2022 15:44:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug causes this class:
>> 
>> class StaticFinalInit {
>>     static final int foo;
>> }
>> 
>> to fail to compile as it should but with a confusing error message:
>> 
>> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>>     static final int foo;
>>                      ^
>> 
>> In another variant, if there is a non-default constructor:
>> 
>> class StaticFinalInit {
>>     static final int foo;
>>     StaticFinalInit() { }
>> }
>> 
>> the compiler gives the right error message but shows the wrong source code location:
>> 
>> StaticFinalInit.java:3: error: variable foo might not have been initialized
>>     StaticFinalInit() { }
>>                         ^
>> 
>> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
>> 
>> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
>> 
>> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
>> 
>> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
>> 
>> The two examples above now both generate this error message:
>> 
>> StaticFinalInit.java:2: error: variable foo might not have been initialized
>>     static final int foo;
>>                      ^
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8184444
>  - Merge branch 'master' into JDK-8184444
>  - Fix confusing error message for uninitialized static final fields.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10896#pullrequestreview-1351085985

From duke at openjdk.org  Tue Mar 21 17:57:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 17:57:48 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <YJc3pW67llK83vVyZyC5qDwQXJGqz1sivZXcbOYl7zc=.2b494770-0fa1-444f-8faa-787a1efb9be9@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
 <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
 <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>
 <YJc3pW67llK83vVyZyC5qDwQXJGqz1sivZXcbOYl7zc=.2b494770-0fa1-444f-8faa-787a1efb9be9@github.com>
Message-ID: <_7MQpmiY4dcnyE8K-MDfSnA_2ID3Qu0QP5A7Ece1QaY=.8c2b1a63-acfd-4b52-b0b1-3e28f5b1a87a@github.com>

On Tue, 21 Mar 2023 17:42:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>>> Please use "--release 20" instead if possible.
>> 
>> Thanks - that works better.
>
> Why is any `--release` option required?   The test should only be run by JDK 20 and later, right?

Per [this CSR comment](https://bugs.openjdk.org/browse/JDK-8301905?focusedCommentId=14559000&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14559000) it was requested to make this an error for source versions >= 21 and a warning for source versions prior to 21.

In order to satisfy `diags/CheckExamples.java` I needed an example that would generate the warning.

But I guess you're right... so the alternative would be to add `compiler.warn.extraneous.semicolon` to `diags/examples.not-yet.txt`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12448#discussion_r1143798466

From vromero at openjdk.org  Tue Mar 21 18:01:44 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 21 Mar 2023 18:01:44 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v3]
In-Reply-To: <Hu90S1n5Hfa37zrcWQeHAEJJeAMCHbDmGG9tcIk-E9U=.4c67a4a6-997f-4949-9c2c-e4fbd7e62813@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Hu90S1n5Hfa37zrcWQeHAEJJeAMCHbDmGG9tcIk-E9U=.4c67a4a6-997f-4949-9c2c-e4fbd7e62813@github.com>
Message-ID: <bXeSylRWfftGxbc7f2xWpTw_j6tlfxUO69nb0JYCIgU=.2f942d26-2e24-430f-b4c7-2244a1ee6832@github.com>

On Mon, 20 Mar 2023 15:46:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the standard "This is NOT part of any supported API" warning.

@jddarcy has proposed in the CSR review to first issue a warning for the affected class files in the current release and in a subsequent release issue an error. Sounds sensible to me

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12893#issuecomment-1478354452

From jjg at openjdk.org  Tue Mar 21 18:04:46 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 21 Mar 2023 18:04:46 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <_7MQpmiY4dcnyE8K-MDfSnA_2ID3Qu0QP5A7Ece1QaY=.8c2b1a63-acfd-4b52-b0b1-3e28f5b1a87a@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
 <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
 <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>
 <YJc3pW67llK83vVyZyC5qDwQXJGqz1sivZXcbOYl7zc=.2b494770-0fa1-444f-8faa-787a1efb9be9@github.com>
 <_7MQpmiY4dcnyE8K-MDfSnA_2ID3Qu0QP5A7Ece1QaY=.8c2b1a63-acfd-4b52-b0b1-3e28f5b1a87a@github.com>
Message-ID: <IAbDEdcan5ugEB8fPl9NK8FCswrhyiRgOcjt0oUahK8=.dd9e216f-d520-475a-a894-d015a26ea906@github.com>

On Tue, 21 Mar 2023 17:55:12 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Why is any `--release` option required?   The test should only be run by JDK 20 and later, right?
>
> Per [this CSR comment](https://bugs.openjdk.org/browse/JDK-8301905?focusedCommentId=14559000&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14559000) it was requested to make this an error for source versions >= 21 and a warning for source versions prior to 21.
> 
> In order to satisfy `diags/CheckExamples.java` I needed an example that would generate the warning.
> 
> But I guess you're right... so the alternative would be to add `compiler.warn.extraneous.semicolon` to `diags/examples.not-yet.txt`?

No, sorry, I wasn't clear enough; my fault.

It is good to add an example (much better than editing the `not-yet.txt` file.). 

The question was why any option specifying a version number is perceived to be required. What happens if you remove the option completely?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12448#discussion_r1143806737

From cushon at openjdk.org  Tue Mar 21 18:11:24 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 21 Mar 2023 18:11:24 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Make fix contingent on --release 14
  
  based on discussion in CSR.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12914/files
  - new: https://git.openjdk.org/jdk/pull/12914/files/d88c6d1e..53743149

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=01-02

  Stats: 6 lines in 3 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12914/head:pull/12914

PR: https://git.openjdk.org/jdk/pull/12914

From cushon at openjdk.org  Tue Mar 21 18:11:28 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 21 Mar 2023 18:11:28 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v2]
In-Reply-To: <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <-BwglB2hljESJRjBNhpFzA20B5fDyuxpJ1RyfcLecf4=.41c0c677-9526-42a3-88ea-d184a1dc6fc7@github.com>
Message-ID: <wO_q1to4g3szqgTwOYlVw704JN8eCB2DE-2-xeDLAXA=.28ef0a03-d6da-48cd-aa5b-0a52a9951ae7@github.com>

On Tue, 14 Mar 2023 15:52:28 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move test under `test/langtools/tools/javac/annotations/typeAnnotations`

I updated the patch so the change only applies for `--release >= 14`, based on feedback in the CSR

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12914#issuecomment-1478363828

From duke at openjdk.org  Tue Mar 21 18:13:49 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 18:13:49 GMT
Subject: RFR: 8027682: javac wrongly accepts semicolons in package and
 import decls [v6]
In-Reply-To: <IAbDEdcan5ugEB8fPl9NK8FCswrhyiRgOcjt0oUahK8=.dd9e216f-d520-475a-a894-d015a26ea906@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
 <XS02yk0As0lruxndUcAcACDwoYcTM80NPpWv3ZqV0dk=.465aeec4-7def-497b-9a4c-19c16dc3ec4b@github.com>
 <U5iPjUnTNZ38WtNbHPxZrJGDUu6LMgkjwcUuRcwhzqs=.9e65f724-b12e-4c5c-9ea7-b1dda7754721@github.com>
 <supWYl1bdtPXB_50cMIrP7kUeVdHv8VCHOdWrS2DoLc=.ef9b4c33-d243-45b2-b427-be1018a0ff57@github.com>
 <YJc3pW67llK83vVyZyC5qDwQXJGqz1sivZXcbOYl7zc=.2b494770-0fa1-444f-8faa-787a1efb9be9@github.com>
 <_7MQpmiY4dcnyE8K-MDfSnA_2ID3Qu0QP5A7Ece1QaY=.8c2b1a63-acfd-4b52-b0b1-3e28f5b1a87a@github.com>
 <IAbDEdcan5ugEB8fPl9NK8FCswrhyiRgOcjt0oUahK8=.dd9e216f-d520-475a-a894-d015a26ea906@github.com>
Message-ID: <qjzdKkIcUolq85vMnfWGxmJO550p5UbVsHw1zJ_68FI=.f8a9ad09-c0b5-4563-9038-16e36aff115c@github.com>

On Tue, 21 Mar 2023 18:01:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> What happens if you remove the option completely?

Then the `diags/CheckExamples.java` test fails when it runs against `ExtraImportSemicolonWarning.java`, because that source file will then generate an error instead of a warning as expected.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12448#discussion_r1143816957

From duke at openjdk.org  Tue Mar 21 18:15:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 18:15:44 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v3]
In-Reply-To: <bXeSylRWfftGxbc7f2xWpTw_j6tlfxUO69nb0JYCIgU=.2f942d26-2e24-430f-b4c7-2244a1ee6832@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <Hu90S1n5Hfa37zrcWQeHAEJJeAMCHbDmGG9tcIk-E9U=.4c67a4a6-997f-4949-9c2c-e4fbd7e62813@github.com>
 <bXeSylRWfftGxbc7f2xWpTw_j6tlfxUO69nb0JYCIgU=.2f942d26-2e24-430f-b4c7-2244a1ee6832@github.com>
Message-ID: <CEMruCyQsyt7ZvWwp3GWuULaItTTudF1168SnMgqPmo=.e036ce19-d74a-406a-912d-abc937a8ddab@github.com>

On Tue, 21 Mar 2023 17:59:21 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> @jddarcy has proposed in the CSR review to first issue a warning for the affected class files in the current release and in a subsequent release issue an error. Sounds sensible to me

Yep, got that on my to-do list. I'll update the patch with that change soon.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12893#issuecomment-1478374390

From duke at openjdk.org  Tue Mar 21 21:30:27 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 21:30:27 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v4]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <PpIY87UXd_uLb8f6euLadzCZoa4pI3mjfrw--LODQEs=.d167829a-72e6-4c4a-b503-b69ac95a0ffe@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request incrementally with three additional commits since the last revision:

 - In release 21, emit warning instead of error for invalid UTF-8.
 - Use Fragments factory for creating message fragments.
 - Fix incorrect parameter index in message fragment.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/62930b59..0a713fdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=02-03

  Stats: 292 lines in 12 files changed: 159 ins; 36 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From duke at openjdk.org  Tue Mar 21 23:06:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:06:48 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite [v2]
In-Reply-To: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
Message-ID: <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>

> This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).
> 
> The method `Name.compareTo()` looks like this:
> 
> /** An arbitrary but consistent complete order among all Names.
>  */
> public int compareTo(Name other) {
>     return other.getIndex() - this.getIndex();
> }
> 
> Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.
> 
> For example, if you apply this patch:
> 
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> @@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
>      /** An arbitrary but consistent complete order among all Names.
>       */
>      public int compareTo(Name other) {
> -        return other.getIndex() - this.getIndex();
> +        return this.getIndex() - other.getIndex();
>      }
> 
>      /** Return true if this is the empty name.
> 
> then the following tests will fail:
> ```TEST: tools/javac/8203436/T8203436b.java
> TEST: tools/javac/generics/7034019/T7034019c.java
> TEST: tools/javac/generics/7034019/T7034019d.java
> TEST: tools/javac/generics/diamond/neg/Neg21.java
> TEST: tools/javac/generics/diamond/neg/Neg22.java
> TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
> TEST: tools/javac/patterns/InferenceUnitTest.java
> TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
> TEST: tools/javac/varargs/6806876/T6806876.java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
> ==============================
> 
> The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.
> 
> It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:
> 
> /**
>  * A partial ordering between type symbols that refines the
>  * class inheritance graph.
>  *
>  * Type variables always precede other kinds of symbols.
>  */
> public final boolean precedes(TypeSymbol that, Types types) {
>     if (this == that)
>         return false;
>     if (type.hasTag(that.type.getTag())) {
>         if (type.hasTag(CLASS)) {
>             return
>                 types.rank(that.type) < types.rank(this.type) ||
>                 types.rank(that.type) == types.rank(this.type) &&
>                 that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>         } else if (type.hasTag(TYPEVAR)) {
>             return types.isSubtype(this.type, that.type);
>         }
>     }
>     return type.hasTag(TYPEVAR);
> }
> 
> If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.
> 
> An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.
> 
> Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.
> 
> When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.
> 
> So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.
> 
> That's what this patch does.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8303526
 - Require Name.compareTo() to produce a lexicographic ordering.

-------------

Changes: https://git.openjdk.org/jdk/pull/12843/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12843&range=01
  Stats: 36 lines in 2 files changed: 31 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12843.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12843/head:pull/12843

PR: https://git.openjdk.org/jdk/pull/12843

From duke at openjdk.org  Tue Mar 21 23:06:51 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:06:51 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
Message-ID: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>

> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
> 
> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
> 
> This change also makes a couple of other changes:
> 
> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
> 
> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
> 
> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Merge branch 'master' into JDK-8277501
 - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
 - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

-------------

Changes: https://git.openjdk.org/jdk/pull/12755/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12755&range=01
  Stats: 93 lines in 3 files changed: 27 ins; 34 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/12755.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12755/head:pull/12755

PR: https://git.openjdk.org/jdk/pull/12755

From duke at openjdk.org  Tue Mar 21 23:07:28 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:07:28 GMT
Subject: RFR: 8029301: Confusing error message for array creation method
 reference [v2]
In-Reply-To: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
References: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
Message-ID: <8YG8boNuKAIIe_JmTh676zByx6GKVV7Ofe7yY_eKmOk=.3350022f-534a-42bb-b355-970d400d28ed@github.com>

> The error for an invalid constructor reference of an array type looks like this:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     constructor Array in class Array cannot be applied to given types
>       required: int
>       found:    no arguments
>       reason: actual and formal argument lists differ in length
> 
> The phrase "constructor Array in class Array" is somewhat confusing.
> 
> This is a simple patch to reword this type of error to look like this instead:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     cannot create array from given types
>       required: int
>       found:    no arguments
>       reason:   actual and formal argument lists differ in length

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'master' into JDK-8029301
 - Improve error referring to "constructor Array in class Array".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12646/files
  - new: https://git.openjdk.org/jdk/pull/12646/files/4c6e1377..fa787de2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12646&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12646&range=00-01

  Stats: 347443 lines in 2599 files changed: 211701 ins; 115337 del; 20405 mod
  Patch: https://git.openjdk.org/jdk/pull/12646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12646/head:pull/12646

PR: https://git.openjdk.org/jdk/pull/12646

From duke at openjdk.org  Tue Mar 21 23:07:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:07:33 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v2]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <nV-bKNGaEY2qwTi4hp-7IDSNCociwmL45raDwN0pLFQ=.ff465bc1-1054-44bd-830b-b63cfe108858@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Remove obsolete regression test for 7016187 handled now in e339e183c1d6.
 - Merge branch 'master' into JDK-8296656
 - Add new javac flag "--detect-output-file-clashes".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/ac02eeae..22fbfeb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=00-01

  Stats: 167469 lines in 2286 files changed: 120351 ins; 27711 del; 19407 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Tue Mar 21 23:07:37 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:07:37 GMT
Subject: RFR: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables [v4]
In-Reply-To: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
Message-ID: <WsQezx0GGaIbFNuE8rIw9ERFTwNem1UCpip0TrNiHtI=.86619f47-d51e-4165-b024-94eef4a1c74f@github.com>

> This bug causes this class:
> 
> class StaticFinalInit {
>     static final int foo;
> }
> 
> to fail to compile as it should but with a confusing error message:
> 
> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>     static final int foo;
>                      ^
> 
> In another variant, if there is a non-default constructor:
> 
> class StaticFinalInit {
>     static final int foo;
>     StaticFinalInit() { }
> }
> 
> the compiler gives the right error message but shows the wrong source code location:
> 
> StaticFinalInit.java:3: error: variable foo might not have been initialized
>     StaticFinalInit() { }
>                         ^
> 
> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
> 
> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
> 
> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
> 
> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
> 
> The two examples above now both generate this error message:
> 
> StaticFinalInit.java:2: error: variable foo might not have been initialized
>     static final int foo;
>                      ^

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8184444
 - Merge branch 'master' into JDK-8184444
 - Merge branch 'master' into JDK-8184444
 - Fix confusing error message for uninitialized static final fields.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10896/files
  - new: https://git.openjdk.org/jdk/pull/10896/files/d9ef373f..63f5375f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10896&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10896&range=02-03

  Stats: 488440 lines in 6439 files changed: 275289 ins; 150335 del; 62816 mod
  Patch: https://git.openjdk.org/jdk/pull/10896.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10896/head:pull/10896

PR: https://git.openjdk.org/jdk/pull/10896

From duke at openjdk.org  Tue Mar 21 23:08:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 21 Mar 2023 23:08:48 GMT
Subject: RFR: 8043179: Lambda expression can mutate final field [v13]
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <jsKYO8mL-1Bj-OC29Y6ml1u4rMcva9y1qzQqm2rGXWA=.bd0dd47a-b5a0-4a57-a621-15a0edf58066@github.com>

> (Description revised)
> 
> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
> 
>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
> 
> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8043179
 - Merge branch 'master' into JDK-8043179
 - Merge branch 'master' into JDK-8043179
 - Update failed test output line numbers after removing @author tags.
 - Remove @author tags from tests.
 - Add a unit test verifying a change in reported error for final variables.
   
   Before this change, compiling this class:
   
       class LambdaMutateFinalVar {
           LambdaMutateFinalVar() {
               final String x;
               Runnable r1 = () -> x = "not ok";
               x = "ok";
           }
       }
   
   would report this error:
   
     local variables referenced from a lambda expression must be final or effectively final
   
   That error is not really appropriate; after all, the variable IS final. The
   real problem is that it can't be assigned from within the lambda because it
   can't be assumed to be DU.
   
   After this change, this error is reported instead:
   
     variable x might already have been assigned
 - Fix previously incorrect logic and update unit tests.
 - Fix @author in test to match github username per instructions.
 - Move unit test into a more appropriate subdirectory.
 - Use /nodynamiccopyright/ for "golden file" test per instructions.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/da1335e8...e1cd7970

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10381/files
  - new: https://git.openjdk.org/jdk/pull/10381/files/86808b2b..e1cd7970

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10381&range=11-12

  Stats: 488440 lines in 6439 files changed: 275289 ins; 150335 del; 62816 mod
  Patch: https://git.openjdk.org/jdk/pull/10381.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10381/head:pull/10381

PR: https://git.openjdk.org/jdk/pull/10381

From duke at openjdk.org  Wed Mar 22 02:49:17 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Mar 2023 02:49:17 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v5]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <as4AzSbMOe-GGit1gJx-9_BiP5W33fYFaWh0AValWE8=.78ae4d8b-5ab9-48ef-ae3c-160c350600fe@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Merge branch 'master' into JDK-8303623
 - In release 21, emit warning instead of error for invalid UTF-8.
 - Use Fragments factory for creating message fragments.
 - Fix incorrect parameter index in message fragment.
 - Add the standard "This is NOT part of any supported API" warning.
 - Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.
 - Disallow non-standard UTF-8 string encodings.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/0a713fdf..dbe2485c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=03-04

  Stats: 156212 lines in 1913 files changed: 112951 ins; 25525 del; 17736 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From liach at openjdk.org  Wed Mar 22 03:26:53 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 03:26:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v6]
In-Reply-To: <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
Message-ID: <951_NUCgc_2ZAsECQsuhYbbRzq22FgXhZXThU-ygrGU=.6f7fc248-081a-48b4-ac9b-3b7de5c19f1d@github.com>

On Mon, 9 Jan 2023 07:34:41 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Update copyright year
>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>  - address comments
>  - cleanup
>  - add annotation processing test
>  - fix line breaks
>  - add access flag based test
>  - remove spaces from empty lines in text block
>  - add bug number to test
>  - copyright
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/813283e2...43780935

This appear related to https://bugs.openjdk.org/browse/JDK-8213329 as well, for this patch makes javac emit parameter attributes reliably.

test/langtools/tools/javac/RequiredParameterFlags/ImplicitParameters.java line 83:

> 81:                         MyRecord {}
> 82:                     }
> 83:                 }

We really need another local class example, such as

{
    int apple = Integer.parseInt("apple");
    Runnable run = new Runnable() {
        public void run() {
            System.out.println(apple);
        }
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1478869826
PR Review Comment: https://git.openjdk.org/jdk/pull/9862#discussion_r1144191036

From jpai at openjdk.org  Wed Mar 22 06:47:44 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 22 Mar 2023 06:47:44 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v11]
In-Reply-To: <zD90MurayrTTk6flXt6MWlAN0x6jFTUO1zZN3mAMloM=.85ec70da-3991-44c4-8a9d-7130ea8124eb@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <zD90MurayrTTk6flXt6MWlAN0x6jFTUO1zZN3mAMloM=.85ec70da-3991-44c4-8a9d-7130ea8124eb@github.com>
Message-ID: <TgdrklI7nC5Wo9gZyX4DBPa3qyWnFCJzJSyjSdZyXGQ=.c1084c99-55cd-4bd7-90f2-c9c3f66c157d@github.com>

On Tue, 21 Mar 2023 17:19:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is both a minor optimization and a fix for JDK-7176515.
>> 
>> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
>> 
>> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
>> 
>> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
>> 
>> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
>> 
>> This results in two improvements:
>> * It avoids building the lookup table for switches on self
>> * It fixes JDK-7176515 as stated
>> 
>> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
>> 
>> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
>> 
>> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update regression test to not look for classfile no longer being generated.

Hello Archie,

> > I'm still seeing test: test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java failing with this patch
> 
> Strange... on github everything is passing now: https://github.com/archiecobbs/jdk/actions/runs/4473109724
> 
> But when I run that specific test on my laptop, it fails for me too.

GitHub actions job for the jdk repo is configured to run only `tier1` tests. The tests are grouped into different tiers in a file called `TEST.groups`. For hotspot that file resides here and the tier1 definition is this https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L545. You will notice that it's configured to run (among other things), the `tier1_runtime` which is defined in that same file https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L364. That group is defined to run everything under `runtime/` directory except the ones marked with a `-` (minus) sign and one of those is https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L404 `tier1_runtime_appcds_exclude` which is defined here https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/TEST.groups#L513, which except for a few tests, excludes everything else under `runtime/cds/appcds/` directory, so I believe that's why this `test/hotspot/jtreg/runtime/
 cds/appcds/jvmti/ClassFileLoadHookTest.java` isn't run in that job.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1478996188

From duke at openjdk.org  Wed Mar 22 06:58:53 2023
From: duke at openjdk.org (Hannes Greule)
Date: Wed, 22 Mar 2023 06:58:53 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v6]
In-Reply-To: <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
Message-ID: <yiqGSDA1dm5vM_QjPA-xYSZVWaeV_crtcUKazI1T_Os=.8c32e55e-d3c8-4ebb-8992-06a662010ee9@github.com>

On Mon, 9 Jan 2023 07:34:41 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Update copyright year
>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>  - address comments
>  - cleanup
>  - add annotation processing test
>  - fix line breaks
>  - add access flag based test
>  - remove spaces from empty lines in text block
>  - add bug number to test
>  - copyright
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/5cb21f18...43780935

Sorry for the late response.

> Our current implementation applies the change of behavior to all `--release/-target` versions. And as far as I see, `MethodParameters` attribute has been properly supported by the Reflection API to filter out synthetic and mandated parameters since [1c54a00](https://github.com/openjdk/jdk/commit/1c54a00f752a54a7a68b09d3df5d3a6081f4fcc8) (Java 8, when `MethodParameters` is introduced). So I suggest to move along by specifying that this change applies to all release/target versions, which will fix the reflection issue on all versions.

I agree with this, I'd be happy if you could update the CSR accordingly.

I will try to address your review comment as soon as possible.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1479009716

From jlahoda at openjdk.org  Wed Mar 22 12:52:43 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 22 Mar 2023 12:52:43 GMT
Subject: RFR: 8304671: javac regression: Compilation with --release 8 fails on
 underscore in enum identifiers
Message-ID: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>

`_` is a valid name for `--release 8`, but code that estimates if a piece of code is an enum constant or a member will fail to recognize that. This patch enhances the estimator to include `_` at the same level as identifiers.

For the estimator, it is not important if `_` is permitted for the given source level or not - the upper levels will produce proper errors/warnings. So, the estimator will consider `_` to be at the same level as an ordinary identifier.

-------------

Commit messages:
 - 8304671: javac regression: Compilation with --release 8 fails on underscore in enum identifiers

Changes: https://git.openjdk.org/jdk/pull/13137/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13137&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304671
  Stats: 190 lines in 2 files changed: 181 ins; 2 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13137.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13137/head:pull/13137

PR: https://git.openjdk.org/jdk/pull/13137

From duke at openjdk.org  Wed Mar 22 14:15:46 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Mar 2023 14:15:46 GMT
Subject: RFR: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements [v11]
In-Reply-To: <TgdrklI7nC5Wo9gZyX4DBPa3qyWnFCJzJSyjSdZyXGQ=.c1084c99-55cd-4bd7-90f2-c9c3f66c157d@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
 <zD90MurayrTTk6flXt6MWlAN0x6jFTUO1zZN3mAMloM=.85ec70da-3991-44c4-8a9d-7130ea8124eb@github.com>
 <TgdrklI7nC5Wo9gZyX4DBPa3qyWnFCJzJSyjSdZyXGQ=.c1084c99-55cd-4bd7-90f2-c9c3f66c157d@github.com>
Message-ID: <Vf_mrj3ANGbG0JvRlE4s5co5KmCUfH6_atovzXRrRhg=.55b5de80-590b-4334-a10c-3dc99deb5f60@github.com>

On Wed, 22 Mar 2023 06:44:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> > > I'm still seeing test: test/hotspot/jtreg/runtime/cds/appcds/jvmti/ClassFileLoadHookTest.java failing with this patch
> > 
> > Strange... on github everything is passing now: https://github.com/archiecobbs/jdk/actions/runs/4473109724
> > But when I run that specific test on my laptop, it fails for me too.
> 
> GitHub actions job for the jdk repo is configured to run only `tier1` tests.

Thanks very much for that clarification.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/10797#issuecomment-1479639705

From jlaskey at openjdk.org  Wed Mar 22 14:43:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <juvO66YNEB-H7csE6Nz1LSPCTeCs9MfH2t6ICg9FDJs=.7b639e70-729e-4ce2-8d1b-54e2e1d98aa3@github.com>

On Tue, 21 Mar 2023 13:25:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 28:
> 
>> 26: package java.lang;
>> 27: 
>> 28: import java.lang.Object;
> 
> You might want to do another pass to check for unused imports

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 44:
> 
>> 42:  * {@link StringTemplate} is the run-time representation of a string template or
>> 43:  * text block template in a template expression.
>> 44:  *
> 
> Extra newline?

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 56:
> 
>> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
>> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
>> 56:  * first produces an instance of {@link StringTemplate}, representing the template
> 
> The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

"representing the right hand side of the template expression"

> src/java.base/share/classes/java/lang/StringTemplate.java line 324:
> 
>> 322:      * assert Objects.equals(sc, "abcxyz");
>> 323:      * }
>> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first
> 
> I was playing with this example in jshell:
> 
> jshell> var st1 = RAW."{1}"
> st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }
> 
> jshell> var st2 = RAW."{2}"
> st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }
> 
> jshell> StringTemplate.combine(st1, st2);
> $7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }
> 
> 
> The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:
> 
> Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next
> 
> I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

okay

> src/java.base/share/classes/java/lang/StringTemplate.java line 431:
> 
>> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
>> 430:      */
>> 431:     static final StringProcessor STR = StringTemplate::interpolate;
> 
> `static final` is redundant here (we are in an interface)

Did not know that.

> src/java.base/share/classes/java/lang/StringTemplate.java line 454:
> 
>> 452:      * This interface describes the methods provided by a generalized string template processor. The
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 
> nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

works for me

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:
> 
>> 45:  */
>> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 47: interface ReferenceKey<T> {
> 
> This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

Informative incase some one wants to use elsewhere in the JDK. My plan is to move this class to java.util at some point.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:
> 
>> 224:                         List.nil(), expressions);
>> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
>> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,
> 
> nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

Tracks well in javah

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:
> 
>> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
>> 251:             }
>> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,
> 
> What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

Criteria in isLinkageProcessor() prevents this from being called.


        boolean isLinkageProcessor() {
            return processor != null &&
                   !useValuesList &&  <=====
                   types.isSubtype(processor.type, syms.linkageType) &&
                   processor.type.isFinal() &&
                   TreeInfo.symbol(processor) instanceof VarSymbol varSymbol &&
                   varSymbol.isStatic() &&
                   varSymbol.isFinal();
        }

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:
> 
>> 279:             make.at(tree.pos);
>> 280: 
>> 281:             if (processor == null || isNamedProcessor(names.RAW)) {
> 
> is `processor == null` still a thing?

I deliberately left this to track free standing templates. Will be phased out in next preview/final.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144898843
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144899315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144902350
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144907969
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144911867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144916768
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144915315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144920121
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144924240
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144918724

From jlaskey at openjdk.org  Wed Mar 22 14:43:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
 <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
Message-ID: <xPCBJE3YSx1AVxj2eP5Z0-mbJxz40uiXK2kfbn-VOQU=.2ed3ed2e-3bbb-44c0-8a80-897c50729a66@github.com>

On Tue, 21 Mar 2023 13:37:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
>> 
>>> 67:  * List<Object> values = st.values();
>>> 68:  * }
>>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>> 
>> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.
>
> The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

* {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
 * which includes the empty first and last fragments. {@code values} will be the
 * equivalent of {@code List.of(10, 20, 30)}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144904923

From duke at openjdk.org  Wed Mar 22 15:01:36 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 22 Mar 2023 15:01:36 GMT
Subject: RFR: 8029301: Confusing error message for array creation method
 reference [v2]
In-Reply-To: <8YG8boNuKAIIe_JmTh676zByx6GKVV7Ofe7yY_eKmOk=.3350022f-534a-42bb-b355-970d400d28ed@github.com>
References: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
 <8YG8boNuKAIIe_JmTh676zByx6GKVV7Ofe7yY_eKmOk=.3350022f-534a-42bb-b355-970d400d28ed@github.com>
Message-ID: <CJhkybDMHtn_GkIxVWyNuDWmmyzkTRQ5kT1hXcjCQ2Y=.3f16afbe-5694-4514-bb99-b10e06ad7844@github.com>

On Tue, 21 Mar 2023 23:07:28 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The error for an invalid constructor reference of an array type looks like this:
>> 
>> Test.java:3: error: incompatible types: invalid constructor reference
>>         Runnable r = String[]::new;
>>                      ^
>>     constructor Array in class Array cannot be applied to given types
>>       required: int
>>       found:    no arguments
>>       reason: actual and formal argument lists differ in length
>> 
>> The phrase "constructor Array in class Array" is somewhat confusing.
>> 
>> This is a simple patch to reword this type of error to look like this instead:
>> 
>> Test.java:3: error: incompatible types: invalid constructor reference
>>         Runnable r = String[]::new;
>>                      ^
>>     cannot create array from given types
>>       required: int
>>       found:    no arguments
>>       reason:   actual and formal argument lists differ in length
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8029301
>  - Improve error referring to "constructor Array in class Array".

@archiecobbs
The??[sponsor]??label has?been?removed.

[sponsor]: https://github.com/openjdk/jdk/labels/sponsor "Pull?request is?ready to?be?sponsored"

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12646#issuecomment-1479724432

From duke at openjdk.org  Wed Mar 22 15:40:46 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Mar 2023 15:40:46 GMT
Subject: RFR: 8029301: Confusing error message for array creation method
 reference [v2]
In-Reply-To: <8YG8boNuKAIIe_JmTh676zByx6GKVV7Ofe7yY_eKmOk=.3350022f-534a-42bb-b355-970d400d28ed@github.com>
References: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
 <8YG8boNuKAIIe_JmTh676zByx6GKVV7Ofe7yY_eKmOk=.3350022f-534a-42bb-b355-970d400d28ed@github.com>
Message-ID: <vAUxc3_GAtfF3F5irl1D3z2-ZYLC3Ku9Asy83fWTUzM=.527d2d83-7790-4765-82f5-480c20149ca9@github.com>

On Tue, 21 Mar 2023 23:07:28 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The error for an invalid constructor reference of an array type looks like this:
>> 
>> Test.java:3: error: incompatible types: invalid constructor reference
>>         Runnable r = String[]::new;
>>                      ^
>>     constructor Array in class Array cannot be applied to given types
>>       required: int
>>       found:    no arguments
>>       reason: actual and formal argument lists differ in length
>> 
>> The phrase "constructor Array in class Array" is somewhat confusing.
>> 
>> This is a simple patch to reword this type of error to look like this instead:
>> 
>> Test.java:3: error: incompatible types: invalid constructor reference
>>         Runnable r = String[]::new;
>>                      ^
>>     cannot create array from given types
>>       required: int
>>       found:    no arguments
>>       reason:   actual and formal argument lists differ in length
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8029301
>  - Improve error referring to "constructor Array in class Array".

> @archiecobbs The ?[sponsor](https://github.com/openjdk/jdk/labels/sponsor)? label has been removed.

Yeah I saw that. Wasn't sure what I was supposed to do but figured out another`/integrate` was needed...

Thanks for the hint.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12646#issuecomment-1479796692

From jlahoda at openjdk.org  Wed Mar 22 16:26:44 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 22 Mar 2023 16:26:44 GMT
Subject: RFR: 8304694: Runtime exception thrown when break stmt is missing
Message-ID: <a9277IynOCexUnHr_7QYH5A43kSZVQypO7zOmpgx3_Q=.8996b8a6-53d0-4144-8103-1fb217be7946@github.com>

For code like this:

    public static int runFallThrough(R6 r) {
        switch (r) {
            case R6(var v1, var v2) when v1 != 0: return 0;
            case R6(var v1, var v2):
        }
        return 1;
    }


The execution falls through from the last case not outside the switch, but inside the fallback default case (that throws).

The current code is injecting breaks, but only for rule cases, and this situation where the last case needs a break is not handled. To simplify the code, it is now proposed to inject breaks at the beginning of the processing (rather than during processing/at the end) to all necessary cases.

-------------

Commit messages:
 - 8304694: Runtime exception thrown when break stmt is missing

Changes: https://git.openjdk.org/jdk/pull/13146/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13146&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304694
  Stats: 21 lines in 2 files changed: 15 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/13146.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13146/head:pull/13146

PR: https://git.openjdk.org/jdk/pull/13146

From liach at openjdk.org  Wed Mar 22 16:49:15 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 22 Mar 2023 16:49:15 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v6]
In-Reply-To: <yiqGSDA1dm5vM_QjPA-xYSZVWaeV_crtcUKazI1T_Os=.8c32e55e-d3c8-4ebb-8992-06a662010ee9@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <IikwrsO98qW1bsxuBfxFQDDOlnScikoHFapIvei2MTw=.83c1c8aa-ca21-42c3-8221-e634e3674c23@github.com>
 <yiqGSDA1dm5vM_QjPA-xYSZVWaeV_crtcUKazI1T_Os=.8c32e55e-d3c8-4ebb-8992-06a662010ee9@github.com>
Message-ID: <4lxfLaa22hnhIST_LaBqBYI2F9qOMUATR3Kz919ioww=.371efa03-ef39-49ef-a5ee-c5bd255520cc@github.com>

On Wed, 22 Mar 2023 06:56:17 GMT, Hannes Greule <duke at openjdk.org> wrote:

> I agree with this, I'd be happy if you could update the CSR accordingly.

I've updated and finalized the CSR for you.

> I will try to address your review comment as soon as possible.

I've opened SirYwell/jdk#1 with 2 commits to address my review concerns about Tests. Feel free to check it out, though the PR will be hard to navigate until you merge jdk's master branch into your branch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1479917619

From vromero at openjdk.org  Wed Mar 22 17:56:34 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Mar 2023 17:56:34 GMT
Subject: RFR: 8304671: javac regression: Compilation with --release 8 fails
 on underscore in enum identifiers
In-Reply-To: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
References: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
Message-ID: <aLQGl-yp5LBIWspmNRz93hUHVuhnMleGchnxr_di9z0=.9541af4e-b801-4e9f-aebd-b193bfc71d04@github.com>

On Wed, 22 Mar 2023 12:44:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `_` is a valid name for `--release 8`, but code that estimates if a piece of code is an enum constant or a member will fail to recognize that. This patch enhances the estimator to include `_` at the same level as identifiers.
> 
> For the estimator, it is not important if `_` is permitted for the given source level or not - the upper levels will produce proper errors/warnings. So, the estimator will consider `_` to be at the same level as an ordinary identifier.

looks sensible

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13137#pullrequestreview-1353182887

From darcy at openjdk.org  Wed Mar 22 18:11:21 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 22 Mar 2023 18:11:21 GMT
Subject: RFR: 8304671: javac regression: Compilation with --release 8 fails
 on underscore in enum identifiers
In-Reply-To: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
References: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
Message-ID: <t_U3l0I_3Y6k3jnv8riCmRcp2BhOkfCLlAo4lusP9_k=.66625763-ebf9-4528-aff4-9de576413add@github.com>

On Wed, 22 Mar 2023 12:44:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `_` is a valid name for `--release 8`, but code that estimates if a piece of code is an enum constant or a member will fail to recognize that. This patch enhances the estimator to include `_` at the same level as identifiers.
> 
> For the estimator, it is not important if `_` is permitted for the given source level or not - the upper levels will produce proper errors/warnings. So, the estimator will consider `_` to be at the same level as an ordinary identifier.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13137#pullrequestreview-1353206784

From vromero at openjdk.org  Wed Mar 22 20:57:40 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 22 Mar 2023 20:57:40 GMT
Subject: RFR: 8304694: Runtime exception thrown when break stmt is missing
In-Reply-To: <a9277IynOCexUnHr_7QYH5A43kSZVQypO7zOmpgx3_Q=.8996b8a6-53d0-4144-8103-1fb217be7946@github.com>
References: <a9277IynOCexUnHr_7QYH5A43kSZVQypO7zOmpgx3_Q=.8996b8a6-53d0-4144-8103-1fb217be7946@github.com>
Message-ID: <5JGaXzAXiCatbmIlZEn3V0la9TkoDYChVOnMJSuup3g=.48e685a9-21b4-4203-afeb-80e9c3341e06@github.com>

On Wed, 22 Mar 2023 16:14:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like this:
> 
>     public static int runFallThrough(R6 r) {
>         switch (r) {
>             case R6(var v1, var v2) when v1 != 0: return 0;
>             case R6(var v1, var v2):
>         }
>         return 1;
>     }
> 
> 
> The execution falls through from the last case not outside the switch, but inside the fallback default case (that throws).
> 
> The current code is injecting breaks, but only for rule cases, and this situation where the last case needs a break is not handled. To simplify the code, it is now proposed to inject breaks at the beginning of the processing (rather than during processing/at the end) to all necessary cases.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13146#pullrequestreview-1353462578

From duke at openjdk.org  Wed Mar 22 21:03:54 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 22 Mar 2023 21:03:54 GMT
Subject: Integrated: 8029301: Confusing error message for array creation method
 reference
In-Reply-To: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
References: <5hjAQ5_IubT-sYrNAm_L6ZfH9aQCLq8tkt_lNj7f0U4=.7121a235-88cd-41c4-ae96-ec02fbe78db7@github.com>
Message-ID: <0Le9RUNJtSJO-TTfRXGJpc6RsylK7y1WpNbwpoVnoOY=.e6cf19a6-d901-408f-abed-b8c76bfc9fde@github.com>

On Mon, 20 Feb 2023 01:55:05 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The error for an invalid constructor reference of an array type looks like this:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     constructor Array in class Array cannot be applied to given types
>       required: int
>       found:    no arguments
>       reason: actual and formal argument lists differ in length
> 
> The phrase "constructor Array in class Array" is somewhat confusing.
> 
> This is a simple patch to reword this type of error to look like this instead:
> 
> Test.java:3: error: incompatible types: invalid constructor reference
>         Runnable r = String[]::new;
>                      ^
>     cannot create array from given types
>       required: int
>       found:    no arguments
>       reason:   actual and formal argument lists differ in length

This pull request has now been integrated.

Changeset: 91f407d6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/91f407d6fe285c44bcc25c1acdf5dc0c43be0172
Stats:     31 lines in 4 files changed: 24 ins; 2 del; 5 mod

8029301: Confusing error message for array creation method reference

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12646

From liach at openjdk.org  Thu Mar 23 01:52:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/StringTemplate.java line 449:

> 447:      * statically imported explicitly.
> 448:      */
> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;

Should we omit the modifiers `static final`, which are implicit for all interface fields?

src/java.base/share/classes/java/lang/StringTemplate.java line 455:

> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 455:      *

Paragraph break intended here?

src/java.base/share/classes/java/lang/StringTemplate.java line 550:

> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
> 549:      * }
> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}

Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

src/java.base/share/classes/java/lang/StringTemplate.java line 592:

> 590:          */
> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 592:         public sealed interface Linkage permits FormatProcessor {

I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

src/java.base/share/classes/java/lang/StringTemplate.java line 679:

> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 678:     @FunctionalInterface
> 679:     public interface StringProcessor extends SimpleProcessor<String> {

Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:

static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}

which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:

> 1049:      * @param ptypes    list of expression types
> 1050:      *
> 1051:      * @return {@link MethodHandle}

Suggestion:

     * @return the {@link MethodHandle} for concatenation

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:

> 1167:      * have an extra {@link String} slot for the result from the previous
> 1168:      * {@link MethodHandle}.
> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}

Suggestion:

     * {@link #makeConcatWithTemplate}

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1246:

> 1244:      * This method creates a {@link MethodHandle} expecting one input, the
> 1245:      * receiver of the supplied getters. This method uses
> 1246:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplateCluster}

Suggestion:

     * {@link #makeConcatWithTemplateCluster}

src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:

> 368:          */
> 369:         private static Map<MethodType, CarrierElements>
> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());

Suggestion:

                methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:

> 419:          */
> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
> 421:             this.primitives = createPrimitivesArray(primitiveCount );

Suggestion:

            this.primitives = createPrimitivesArray(primitiveCount);

src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:

> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
> 775:          */
> 776:         static CarrierElements of(Class < ? >...ptypes) {

Suggestion:

        static CarrierElements of(Class<?>... ptypes) {

src/java.base/share/classes/java/lang/runtime/Carriers.java line 824:

> 822:         private CarrierElements() {
> 823:             throw new AssertionError("private constructor");
> 824:         }

Suggestion:

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:

> 47: interface ReferenceKey<T> {
> 48:     /**
> 49:      * {@return the value of the unwrapped key.}

Suggestion:

     * {@return the value of the unwrapped key}

Inline return tag generates a period already.

src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:

> 125:     @SuppressWarnings("unchecked")
> 126:     static <K, V> ReferencedKeyMap<K, V>
> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {

What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:

> 38:  * <p>
> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
> 40:  * and sharing of value shapes without creating a new class for each shape.

Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 65:

> 63:      * {@link java.lang.invoke.CallSite CallSite}.
> 64:      */
> 65:     private final MethodHandle valuesMH;

I don't think `java.lang.runtime` is a package where final fields are [trusted](https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/hotspot/share/ci/ciField.cpp#L226), so these method handles might have a performance overhead. However, records appear to be optimized and eligible for inlining.

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:

> 86:      *
> 87:      * @param fragments  string template fragments
> 88:      * @param type       method type

Suggestion:

     * @param type method type accepting values' types and returning a StringTemplate

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:

> 167:      * @return StringTemplate composed from fragments and values
> 168:      */
> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {

I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:

> 202:             Object[] values
> 203:     ) throws Throwable {
> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));

Suggestion:

        List<Object> asList = List.of(values);

For defensive copy.
Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 233:

> 231:      */
> 232:     private static StringTemplate fromArrays(String[] fragments, Object[] values) {
> 233:         return StringTemplateImplFactory.newStringTemplate(fragments, values);

Should perform defensive copying for the input arrays, specifically `values` (fragments is passed to `List.of`, which is already safe)

In addition, I recommend renaming methods that don't perform defensive copies to like `ofTrusted`, so we can better avoid such problems.

src/java.base/share/classes/java/util/Digits.java line 68:

> 66:      */
> 67:     final class DecimalDigits implements Digits {
> 68:         private static final short[] DIGITS;

Can add `@Stable` to speed up array element access. Same for below.

src/java.base/share/classes/java/util/FormatProcessor.java line 157:

> 155:         Objects.requireNonNull(stringTemplate);
> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);

Suggestion:

        Object[] values = stringTemplate.values().toArray();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500281
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500568
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145503416
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145582334
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145509343
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511968
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145520158
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145521984
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145532679
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145528633
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531061
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531547
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145533037
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145534263
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145566980
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145555878
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145567708
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145576079
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145577290
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145570455
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145578159
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145579950

From liach at openjdk.org  Thu Mar 23 01:52:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>

On Fri, 28 Oct 2022 20:05:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Disagree.
>
> As i said above, i consider this thread as resolved

Suggestion:

     * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511120

From vromero at openjdk.org  Thu Mar 23 03:46:43 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Mar 2023 03:46:43 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
Message-ID: <yn9qvUhLML9fIh5VPV1wRkb_ks06baxyaPpUlNBrXqg=.00b296a1-0124-43cb-9800-23603952fdf4@github.com>

On Tue, 21 Mar 2023 18:11:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make fix contingent on --release 14
>   
>   based on discussion in CSR.

looks good, added a minor suggestion

test/langtools/tools/javac/annotations/typeAnnotations/NoTargetOnTypeParameterDeclaration.java line 29:

> 27:  * @summary no- at Target annotations should be applicable to type parameter declarations
> 28:  * @compile/fail/ref=NoTargetOnTypeParameterDeclaration.out --release 13 -XDrawDiagnostics NoTargetOnTypeParameterDeclaration.java
> 29:  * @compile --release 14 NoTargetOnTypeParameterDeclaration.java

suggestion: you could add another command to compile the source with no `--release` option so that the behavior is checked for current and future releases too

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12914#pullrequestreview-1353793145
PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1145639123

From darcy at openjdk.org  Thu Mar 23 04:30:43 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Mar 2023 04:30:43 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
Message-ID: <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>

On Tue, 21 Mar 2023 18:11:24 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make fix contingent on --release 14
>   
>   based on discussion in CSR.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3515:

> 3513:         List<Attribute> targets = typeAnnotations.annotationTargets(a.annotationType.type.tsym);
> 3514:         return (targets == null) ?
> 3515:                 (source.compareTo(Source.JDK14) >= 0 && isTypeParameter) :

Usually this kind of test is done using a constant in the Feature enum; I'll let Vicente or other engineer who focuses on javac weigh in on whether or not the direct comparison is acceptable in this case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1145666707

From darcy at openjdk.org  Thu Mar 23 04:30:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 23 Mar 2023 04:30:46 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <yn9qvUhLML9fIh5VPV1wRkb_ks06baxyaPpUlNBrXqg=.00b296a1-0124-43cb-9800-23603952fdf4@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <yn9qvUhLML9fIh5VPV1wRkb_ks06baxyaPpUlNBrXqg=.00b296a1-0124-43cb-9800-23603952fdf4@github.com>
Message-ID: <xIJZxdV7lCS4fSSrseOExl-q-hdTFFtKm_eMKr2OIcs=.2af9b9b4-bd46-430a-a54c-53acfe48e461@github.com>

On Thu, 23 Mar 2023 03:43:27 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> suggestion: you could add another command to compile the source with no `--release` option so that the behavior is checked for current and future releases too

Yes, I agree that is a good suggestion and our standard testing practice.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1145666205

From clanger at openjdk.org  Thu Mar 23 06:57:43 2023
From: clanger at openjdk.org (Christoph Langer)
Date: Thu, 23 Mar 2023 06:57:43 GMT
Subject: RFR: 8304671: javac regression: Compilation with --release 8 fails
 on underscore in enum identifiers
In-Reply-To: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
References: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
Message-ID: <augTdVNPQDOpZ4XlJmvTMMQnTbyuyGNQk8NgsAwYgT8=.fe283c15-5739-4830-a5de-a6f8a48380b5@github.com>

On Wed, 22 Mar 2023 12:44:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `_` is a valid name for `--release 8`, but code that estimates if a piece of code is an enum constant or a member will fail to recognize that. This patch enhances the estimator to include `_` at the same level as identifiers.
> 
> For the estimator, it is not important if `_` is permitted for the given source level or not - the upper levels will produce proper errors/warnings. So, the estimator will consider `_` to be at the same level as an ordinary identifier.

Thanks for tackling that so quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13137#issuecomment-1480686959

From jlahoda at openjdk.org  Thu Mar 23 08:39:04 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 23 Mar 2023 08:39:04 GMT
Subject: Integrated: 8304671: javac regression: Compilation with --release 8
 fails on underscore in enum identifiers
In-Reply-To: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
References: <-qGQHpAVso5zNtDbZM-lbpWCT-MX8HmPXWpWX7R6E9Q=.fb3978b1-75c8-410a-8536-875903e1ccd2@github.com>
Message-ID: <qASB2P_hDvUBJIamdLRELc51gmnxEKCU-xcONwZfDVI=.0ebce364-7c22-4f70-adb6-5ca259f73df0@github.com>

On Wed, 22 Mar 2023 12:44:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> `_` is a valid name for `--release 8`, but code that estimates if a piece of code is an enum constant or a member will fail to recognize that. This patch enhances the estimator to include `_` at the same level as identifiers.
> 
> For the estimator, it is not important if `_` is permitted for the given source level or not - the upper levels will produce proper errors/warnings. So, the estimator will consider `_` to be at the same level as an ordinary identifier.

This pull request has now been integrated.

Changeset: 63d4afbe
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/63d4afbeb17df4eff0f65041926373ee62a8a33a
Stats:     190 lines in 2 files changed: 181 ins; 2 del; 7 mod

8304671: javac regression: Compilation with --release 8 fails on underscore in enum identifiers

Reviewed-by: vromero, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/13137

From jlaskey at openjdk.org  Thu Mar 23 11:49:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <p_X2VwL8FULtj_Uc8EpMJdBF5min1UtyXow7dgSfm08=.4d5b5224-daef-4c01-9139-38382382426b@github.com>

On Wed, 22 Mar 2023 23:12:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 449:
> 
>> 447:      * statically imported explicitly.
>> 448:      */
>> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;
> 
> Should we omit the modifiers `static final`, which are implicit for all interface fields?

Already changed.

> src/java.base/share/classes/java/lang/StringTemplate.java line 455:
> 
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
>> 455:      *
> 
> Paragraph break intended here?

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060615
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146060887

From jlaskey at openjdk.org  Thu Mar 23 11:52:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:52:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <QU206yI0AfLSRZu-8MGtN95EdFTAmGIHbDIkw5Igv9w=.effa8829-ed13-42c3-b881-9bdfff403779@github.com>

On Wed, 22 Mar 2023 23:16:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 550:
> 
>> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
>> 549:      * }
>> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}
> 
> Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

This is in the changes JLS defined in https://bugs.openjdk.org/browse/JDK-8296302 . I'll be updating the @jls links when finalized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146066143

From jlaskey at openjdk.org  Thu Mar 23 12:16:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:16:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>

On Wed, 22 Mar 2023 23:23:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
> 
>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 678:     @FunctionalInterface
>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
> 
> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
> 
> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
> 
> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

Worth considering. Thank you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146091987

From jlaskey at openjdk.org  Thu Mar 23 12:20:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:20:04 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>

On Thu, 23 Mar 2023 01:33:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
> 
>> 202:             Object[] values
>> 203:     ) throws Throwable {
>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
> 
> Suggestion:
> 
>         List<Object> asList = List.of(values);
> 
> For defensive copy.
> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146098407

From jlaskey at openjdk.org  Thu Mar 23 12:28:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:28:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RsngCPLETmmciRbbJmWhucmKxdY6wywBZYkxO3OlGmw=.8f251d95-7d25-467a-9e6f-68e0f68ffb3f@github.com>

On Thu, 23 Mar 2023 01:45:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 592:
> 
>> 590:          */
>> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 592:         public sealed interface Linkage permits FormatProcessor {
> 
> I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

Linkage is unfinished business for the first preview. What we are working on is a managed construction of the BSM, a ProcessorFactory per se. The hope is that this will be flushed out for the next round.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146110189

From jlaskey at openjdk.org  Thu Mar 23 12:24:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:24:12 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <fnsA_D74g7fDjymHpEjRggSEoo_59PBHF1NK8PwLhjo=.dd834f1d-5566-47a9-a59f-38ad822100fb@github.com>

On Thu, 23 Mar 2023 01:36:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/util/Digits.java line 68:
> 
>> 66:      */
>> 67:     final class DecimalDigits implements Digits {
>> 68:         private static final short[] DIGITS;
> 
> Can add `@Stable` to speed up array element access. Same for below.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 157:
> 
>> 155:         Objects.requireNonNull(stringTemplate);
>> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
>> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);
> 
> Suggestion:
> 
>         Object[] values = stringTemplate.values().toArray();

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146101352
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146103101

From jlaskey at openjdk.org  Thu Mar 23 12:44:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:44:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <_OQ7lbvgmuySOqu5i6NIihfPAee6VjBxoyhwv_lV7cw=.b7735595-141b-4f96-b9f4-605ecfce62aa@github.com>

On Thu, 23 Mar 2023 01:31:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:
> 
>> 167:      * @return StringTemplate composed from fragments and values
>> 168:      */
>> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {
> 
> I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

I don't disagree, I will consider.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146131084

From jlaskey at openjdk.org  Thu Mar 23 13:07:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 13:07:05 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v47]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <F7PO-Fpe6hQGkA70LwmKQ_EfnjmN_p9Ui_fjRO_U3BM=.4df1b97b-72eb-43c8-ac3b-200742e3e5f5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Review recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/9ba6400d..6f95d953

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=45-46

  Stats: 36 lines in 6 files changed: 6 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From duke at openjdk.org  Thu Mar 23 13:17:18 2023
From: duke at openjdk.org (Hannes Greule)
Date: Thu, 23 Mar 2023 13:17:18 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v7]
In-Reply-To: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
Message-ID: <Dp-1qd5RkSBC81YjJ1XkTioWSJQmdRCpHjfg6stdqhE=.f9a71aa3-08a5-4f30-9fda-74c2fce199ff@github.com>

> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
> Parameter names are *not* emitted unless the `-parameter` flag is set.
> 
> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
> 
> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
> I also had to update some tests as they got a new constant pool entry.
> 
> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
> Please let me know if you want tests for specific appearances of synthetic parameters.

Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:

 - Merge pull request #1 from liachmodded/methodparameters-flags
   
 - Update tests
 - Parity for the parameter flag tests in javac and reflection
 - Updated RequiredMethodParameterFlagTest, checks against Local classes as well
 - Merge branch 'master' into methodparameters-flags
 - Update copyright year
 - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
 - address comments
 - cleanup
 - add annotation processing test
 - ... and 16 more: https://git.openjdk.org/jdk/compare/d2710c36...5ac3a214

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/9862/files
  - new: https://git.openjdk.org/jdk/pull/9862/files/43780935..5ac3a214

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=9862&range=05-06

  Stats: 480788 lines in 5885 files changed: 270818 ins; 148305 del; 61665 mod
  Patch: https://git.openjdk.org/jdk/pull/9862.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/9862/head:pull/9862

PR: https://git.openjdk.org/jdk/pull/9862

From jlaskey at openjdk.org  Thu Mar 23 14:42:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 14:42:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
Message-ID: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>

On Thu, 23 Mar 2023 12:12:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
>> 
>>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 678:     @FunctionalInterface
>>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
>> 
>> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
>> 
>> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
>> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
>> 
>> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.
>
> Worth considering. Thank you.

You can, of course, reduce this to;


interface Processor {
 
    ...
    
    static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
        return function::apply;
    }
    
    ...

}


since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146303119

From cushon at openjdk.org  Thu Mar 23 14:52:04 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 23 Mar 2023 14:52:04 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v4]
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <3c4ngeA6R1UnDqbExLk8o1iNAnPpux670Fq_V4DeqGI=.313a4430-8cca-4811-a9e7-35b9f147600b@github.com>

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Add a test case with no --release flag

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12914/files
  - new: https://git.openjdk.org/jdk/pull/12914/files/53743149..57c4515c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=02-03

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12914/head:pull/12914

PR: https://git.openjdk.org/jdk/pull/12914

From cushon at openjdk.org  Thu Mar 23 14:52:07 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Thu, 23 Mar 2023 14:52:07 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <xIJZxdV7lCS4fSSrseOExl-q-hdTFFtKm_eMKr2OIcs=.2af9b9b4-bd46-430a-a54c-53acfe48e461@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <yn9qvUhLML9fIh5VPV1wRkb_ks06baxyaPpUlNBrXqg=.00b296a1-0124-43cb-9800-23603952fdf4@github.com>
 <xIJZxdV7lCS4fSSrseOExl-q-hdTFFtKm_eMKr2OIcs=.2af9b9b4-bd46-430a-a54c-53acfe48e461@github.com>
Message-ID: <y1vIiySfbXTfwKObAWiLkMjL4vZAqO2ySxaccBHnJgc=.5c4fbe9c-8d91-4953-ba1d-0fe192bc67e2@github.com>

On Thu, 23 Mar 2023 04:27:00 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> test/langtools/tools/javac/annotations/typeAnnotations/NoTargetOnTypeParameterDeclaration.java line 29:
>> 
>>> 27:  * @summary no- at Target annotations should be applicable to type parameter declarations
>>> 28:  * @compile/fail/ref=NoTargetOnTypeParameterDeclaration.out --release 13 -XDrawDiagnostics NoTargetOnTypeParameterDeclaration.java
>>> 29:  * @compile --release 14 NoTargetOnTypeParameterDeclaration.java
>> 
>> suggestion: you could add another command to compile the source with no `--release` option so that the behavior is checked for current and future releases too
>
>> suggestion: you could add another command to compile the source with no `--release` option so that the behavior is checked for current and future releases too
> 
> Yes, I agree that is a good suggestion and our standard testing practice.

Done, thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1146311865

From jlaskey at openjdk.org  Thu Mar 23 15:05:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:05:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
Message-ID: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>

On Thu, 23 Mar 2023 14:39:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Worth considering. Thank you.
>
> You can, of course, reduce this to;
> 
> 
> interface Processor {
>  
>     ...
>     
>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>         return function::apply;
>     }
>     
>     ...
> 
> }
> 
> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
> var string = Processor.of(StringTemplate::interpolate);
> 
> 
> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

On the flip side, for those that don't use `var`;


Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);


vs.


SimpleProcessor<JSONObject> simple = Processor.of(st-> new JSONObject(st.interpolate()));
StringProcessor string = Processor.of(StringTemplate::interpolate);

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146336461

From jlaskey at openjdk.org  Thu Mar 23 15:53:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:53:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
Message-ID: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>

On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> You can, of course, reduce this to;
>> 
>> 
>> interface Processor {
>>  
>>     ...
>>     
>>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>>         return function::apply;
>>     }
>>     
>>     ...
>> 
>> }
>> 
>> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> var string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.
>
> On the flip side, for those that don't use `var`;
> 
> 
> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
> 
> 
> vs.
> 
> 
> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
> StringProcessor string = StringTemplate::interpolate;

It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146406021

From duke at openjdk.org  Thu Mar 23 16:03:40 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Mar 2023 16:03:40 GMT
Subject: Integrated: 8043179: Lambda expression can mutate final field
In-Reply-To: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
References: <1JT2jZ9koHnJJBtvvm8a1JVi6pqsIQ4vjx5j337W8ns=.a327f6fb-4abc-46c4-ad9b-3124f68caba5@github.com>
Message-ID: <W_CbBXtjDfWxHyPeROF2BMisoFxiuf7WGrABOzwJRO8=.69adbc80-2c44-45a9-8565-d3175eed1503@github.com>

On Wed, 21 Sep 2022 23:03:45 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> (Description revised)
> 
> JDK-8043176 updated the JLS 16.1.10 to describe how within a lambda body, any variables that were DU before the lambda expression must not be considered DU at the start of the lambda block, because arbitrary code could have executed in the meantime:
> 
>>  _No rule allows V to be definitely unassigned before a lambda body. This is by design: a variable that was definitely unassigned before the lambda body may end up being assigned to later on, so we cannot conclude that the variable will be unassigned when the body is executed._
> 
> This fix to `Flow.AssignAnalyzer` follows in a straightforward way: mark all variables as not DU before recursing into the lambda body.

This pull request has now been integrated.

Changeset: c00d0885
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c00d0885ae3c99c0ebacec0bd7de7382ee954dc1
Stats:     35 lines in 5 files changed: 35 ins; 0 del; 0 mod

8043179: Lambda expression can mutate final field

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/10381

From duke at openjdk.org  Thu Mar 23 16:08:48 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Mar 2023 16:08:48 GMT
Subject: Integrated: 8027682: javac wrongly accepts semicolons in package and
 import decls
In-Reply-To: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
References: <bQN6VoWgHskZ_Wg9PgBhKWwUDYp5jlRGja_LkitHQY4=.1a7d2eec-a992-4cee-9eb0-68fe1821e276@github.com>
Message-ID: <yyWntfn053T718A_wP_vZEamKgL4IwrppFE_nlQMZPs=.4f70d0b2-5163-4c78-8c40-ff21e8b03ba4@github.com>

On Mon, 6 Feb 2023 20:32:27 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> JLS [?7.3](https://docs.oracle.com/javase/specs/jls/se19/html/jls-7.html#jls-7.3) specifies that while a lone semicolon is a valid _TopLevelClassOrInterfaceDeclaration_, it is not a valid _ImportDeclaration_. Therefore, if we see a lone semicolon while looking for the next import statement we have to advance and accept a class declaration, and we can therefore no longer accept any further `import` statements.
> 
> However, the compiler was allowing this, for example:
> 
> package p; import X; ;;; import Y; class Foo {}
> 
> The bug is that the parser was switching out of "look for imports" mode after parsing a valid class declaration, but it was not switching out of "look for imports" mode after parsing a lone semicolon.
> 
> The fix to `JavacParser.java` is easy, however it also requires these adjustments to unit tests:
> 
> * Test `tree/T6963934.java` must go away, because it is verifying a bug that only happens when the above bogus input is successfully parsed, and this can no longer happen.
> * A bug in `lib/types/TypeHarness.java` was uncovered and fixed; it was inserting an extra semicolon.
> * The following bugs, which check invalid syntax within import statements, now generate different parse errors and therefor needed their "golden output" updated:
>   * annotations/typeAnnotations/failures/AnnotatedImport.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage1.java
>   * annotations/typeAnnotations/failures/AnnotatedPackage2.java

This pull request has now been integrated.

Changeset: 4b8f7db6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b8f7db6be80e425bebfaf6f68d49da74f29386a
Stats:     188 lines in 18 files changed: 110 ins; 63 del; 15 mod

8027682: javac wrongly accepts semicolons in package and import decls

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12448

From duke at openjdk.org  Thu Mar 23 16:11:07 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Mar 2023 16:11:07 GMT
Subject: Integrated: 8184444: The compiler error
 "variable not initialized in the default constructor" is not apt in case of
 static final variables
In-Reply-To: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
References: <cOL7EK9Akeeunn-3Nj7byYG57_StGU1x35rFnGXswAw=.a4cf0562-fd0d-4ab7-af8e-2753d96bb83a@github.com>
Message-ID: <xgCGbZwRo57jcOnEcoyfAO4v6FDfJAqgumN7qcSNd98=.4b6c576f-de97-4c8b-aabf-934a260631f5@github.com>

On Fri, 28 Oct 2022 02:05:21 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug causes this class:
> 
> class StaticFinalInit {
>     static final int foo;
> }
> 
> to fail to compile as it should but with a confusing error message:
> 
> StaticFinalInit.java:2: error: variable foo not initialized in the default constructor
>     static final int foo;
>                      ^
> 
> In another variant, if there is a non-default constructor:
> 
> class StaticFinalInit {
>     static final int foo;
>     StaticFinalInit() { }
> }
> 
> the compiler gives the right error message but shows the wrong source code location:
> 
> StaticFinalInit.java:3: error: variable foo might not have been initialized
>     StaticFinalInit() { }
>                         ^
> 
> This behavior is a side-effect of the roundabout way we currently check for definite assignment of static final fields.
> 
> When recursing into a class definition in `Flow.AssignAnalyzer`, we first initialize DA/DU analysis for static fields, and then recurse on the static initializers to pick up static field assignments. However, we don't then check for definite assignment of static final fields. Instead, we proceed with the analysis, and then later, whenever we visit an initial constructor (i.e., one that invokes `super()` instead of `this()`), we check for definite assignment of both static final and instance final fields.
> 
> This works because every class has at least one initial constructor, so static fields will always get checked at least once. Of course, it also results in doing some redundant work (if there are multiple initial constructors) and it generates the wrong error message and/or source code position.
> 
> This patch adds a check for definite assignment of static final fields (with the appropriate error message) after we recurse on the static initializers, and it filters out static fields from the checks being done in initial constructors. It also updates a couple of existing unit tests that were expecting the wrong source code position.
> 
> The two examples above now both generate this error message:
> 
> StaticFinalInit.java:2: error: variable foo might not have been initialized
>     static final int foo;
>                      ^

This pull request has now been integrated.

Changeset: 6fa25cc1
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6fa25cc134e8a6787490e080fb98c2d61cf0b049
Stats:     24 lines in 5 files changed: 20 ins; 1 del; 3 mod

8184444: The compiler error "variable not initialized in the default constructor" is not apt in case of static final variables

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/10896

From forax at openjdk.org  Thu Mar 23 16:38:43 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:38:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
Message-ID: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>

On Thu, 23 Mar 2023 15:49:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> On the flip side, for those that don't use `var`;
>> 
>> 
>> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> vs.
>> 
>> 
>> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
>> StringProcessor string = StringTemplate::interpolate;
>
> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.

It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146450918

From liach at openjdk.org  Thu Mar 23 16:39:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 16:39:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Tidy javadoc
>  - Rename StringTemplate classes

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:

> 180:      */
> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));

Suggestion:

        return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());

per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146462702

From forax at openjdk.org  Thu Mar 23 16:39:44 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:39:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
Message-ID: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>

On Thu, 23 Mar 2023 12:17:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
>> 
>>> 202:             Object[] values
>>> 203:     ) throws Throwable {
>>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
>> 
>> Suggestion:
>> 
>>         List<Object> asList = List.of(values);
>> 
>> For defensive copy.
>> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.
>
> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
so

  List<Object> asList = Arrays.stream(values).toList();

is what you are looking for.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146455491

From jlaskey at openjdk.org  Thu Mar 23 17:09:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
Message-ID: <mmAY9J3CZffkVQAoOMfuuQAn6e1W-CV9WTQmzXl-wcE=.1e74658f-a7cd-4ed7-8d81-91c5aec5122b@github.com>

On Thu, 23 Mar 2023 16:30:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:
> 
>> 180:      */
>> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
>> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));
> 
> Suggestion:
> 
>         return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());
> 
> per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507522

From jlaskey at openjdk.org  Thu Mar 23 17:09:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
 <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
Message-ID: <tRwCH5_g2UXF4dKHNXUHBnI7WSwtoIa25a-GGVUv848=.c98cd493-c687-498a-98e3-337d1ff529a4@github.com>

On Thu, 23 Mar 2023 16:25:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.
>
> There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
> so
> 
>   List<Object> asList = Arrays.stream(values).toList();
> 
> is what you are looking for.

Changed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146507389

From jlaskey at openjdk.org  Thu Mar 23 17:12:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:12:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v48]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <bx0_rNhNOOZtZFTD1o1Kyh0epp_vd3cXYvvgXdw654Y=.75542bb1-2326-4eaa-b8a9-1590237604b3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Clean up list construction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6f95d953..96752c64

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=46-47

  Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Thu Mar 23 17:24:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:24:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
 <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
Message-ID: <Xs8mcQOFKLdtbKIiMuYaZVAhn0F_LEA38YjAQTljriQ=.6130e9f7-58e6-4dae-abf1-ccef25a56510@github.com>

On Thu, 23 Mar 2023 16:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.
>
> Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.
> 
> It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

"Not a lot of people will write a processor" I am not as confident as you. Once the cat is out of the bag that you can do magic (pending Guide to String Templates), processors will become a common idiom for designating string literals, especially text blocks.

But, I do agree that a majority will do old school classes with `process` methods along with several supporting methods. On the other  hand, the API itself uses function interfaces to define STR and RAW. I guess I'll have to do a pro/con chart.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1146528863

From vromero at openjdk.org  Thu Mar 23 17:37:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 23 Mar 2023 17:37:11 GMT
Subject: RFR: 8291154: Create a non static nested class without enclosing
 class throws VerifyError [v2]
In-Reply-To: <zX1W84f6tbI2DwPuW1gqFpGA1sqR5pTWYTlcNSKro3o=.36e64542-7ff1-4cd6-a3f0-a6c0f5ba1231@github.com>
References: <6pcn3LwvxoB4pShWt0LB2ZMTGIhubUVChSmA_26dnYE=.e6d99613-9f14-42ff-ac86-c77d8f119277@github.com>
 <zX1W84f6tbI2DwPuW1gqFpGA1sqR5pTWYTlcNSKro3o=.36e64542-7ff1-4cd6-a3f0-a6c0f5ba1231@github.com>
Message-ID: <f4lPJFDUkKx8zKvsdN0W7_sW7bWRpxLSV3cYI_vNfg4=.322351ae-5493-44ae-838a-4c5ad210bc1c@github.com>

On Wed, 11 Jan 2023 21:49:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The fix for [JDK-8254321](https://bugs.openjdk.org/browse/JDK-8254321) opened a loophole where a Java source file that defines a static nested class `B` that extends a non-static nested class `A` no longer generates an error if `B` is nested within `A`.
>> 
>> Here's an example:
>> 
>> class StaticNestedNonStaticSuper {
>>     public abstract class NonStaticNested {
>>         public static class StaticNested extends NonStaticNested {
>>             public StaticNested() {
>>                 // where is StaticNestedNonStaticSuper.this for super() going to come from??
>>             }
>>         }
>>     }
>> }
>> 
>> 
>> Of course this is illegal because the non-static nested superclass requires an outer 'this' instance to be passed as the first argument to all of its constructors, but the static nested subclass has no such outer 'this' to provide. The compiler was proceeding anyway, resulting in unverifiable bytecode.
>> 
>> This PR adds a check for this situation. The check is added at the point in `Lower.java` where superclass constructor invocations in subclasses of non-static nested classes add the outer 'this' instance as a first parameter to `super()`.
>> 
>> I'm not sure if this is the most appropriate location for this additional check, but at least it is in an optimal place to observe the problem when it happens.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify unit test.

this looks good, running regression tests now

-------------

PR Comment: https://git.openjdk.org/jdk/pull/11954#issuecomment-1481607834

From duke at openjdk.org  Thu Mar 23 19:48:29 2023
From: duke at openjdk.org (Hannes Greule)
Date: Thu, 23 Mar 2023 19:48:29 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v7]
In-Reply-To: <Dp-1qd5RkSBC81YjJ1XkTioWSJQmdRCpHjfg6stdqhE=.f9a71aa3-08a5-4f30-9fda-74c2fce199ff@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Dp-1qd5RkSBC81YjJ1XkTioWSJQmdRCpHjfg6stdqhE=.f9a71aa3-08a5-4f30-9fda-74c2fce199ff@github.com>
Message-ID: <WaPv9UnTrgGA05SHN3SGbhQwnvOm0AC_IwKY2xrkEq4=.10bb7fcd-048e-4797-80dd-0687fbceea71@github.com>

On Thu, 23 Mar 2023 13:17:18 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> With this change, javac emits the MethodParameters attribute in cases where the JLS requires the information about synthetic and mandated parameters to be stored (see issue).
>> Parameter names are *not* emitted unless the `-parameter` flag is set.
>> 
>> The relevant changes are in `ClassWriter`, where we go through the params to see if we need the attribute if the `-parameter` flag is not set (if it is set, both names and flags will be emitted).
>> For records, the mandated flag wasn't set at all, this is solved by the one line fix in `JavacParser`.
>> 
>> The changes to `CreateSymbols` and `ClassReader` are needed as they weren't able to deal with missing names in the attribute.
>> I also had to update some tests as they got a new constant pool entry.
>> 
>> Only the mandated flag is covered by tests at the moment, as the occurrences are well-specified in the JLS.
>> Please let me know if you want tests for specific appearances of synthetic parameters.
>
> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge pull request #1 from liachmodded/methodparameters-flags
>    
>  - Update tests
>  - Parity for the parameter flag tests in javac and reflection
>  - Updated RequiredMethodParameterFlagTest, checks against Local classes as well
>  - Merge branch 'master' into methodparameters-flags
>  - Update copyright year
>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>  - address comments
>  - cleanup
>  - add annotation processing test
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/ad5f9a5d...5ac3a214

Test failures are caused by the Classfile API. I opened a separate PR to fix it: https://github.com/openjdk/jdk/pull/13167

Could someone create an issue on the bug tracker for me? Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1481796818

From duke at openjdk.org  Thu Mar 23 20:00:30 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Mar 2023 20:00:30 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v3]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <Uia8ZU6LdmlpvN7EJVgZpwHYUSVmLRn-3m5419GBItw=.52670250-c79c-439e-b6d1-a4722507600a@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Flush "outputFilesWritten" on close() for good measure.
 - Synchronize consistently (and not redundantly) around "outputFilesWritten".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/22fbfeb8..51134ddf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=01-02

  Stats: 29 lines in 2 files changed: 13 ins; 8 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Thu Mar 23 21:21:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Thu, 23 Mar 2023 21:21:20 GMT
Subject: Integrated: 7176515: ExceptionInInitializerError for an enum with
 multiple switch statements
In-Reply-To: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
References: <FKWN191gv60Eb-KStj4-Q1YA_4D1Yo4HwBfYHeJzjaM=.1d06b7f6-91c5-42e2-983d-e2c061f3c650@github.com>
Message-ID: <G5JSh4DM6DnXxl5r3YmZHyt6sihIZqpJ3KdgpNkjEuU=.6294e946-2fdc-4de2-99ad-2b0c467a615e@github.com>

On Thu, 20 Oct 2022 15:46:01 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch is both a minor optimization and a fix for JDK-7176515.
> 
> JDK-7176515 relates to how javac handles `switch` statements on `Enum` values, which are effectively "syntactic sugar".
> 
> The simple approach would be to just get the enum's `ordinal()` value and then revert to a normal integer value switch on that. However, this snapshots the ordinal values at compile-time, and thus can fail if the `Enum` class is recompiled later.
> 
> Presumably to avoid that possibility (are there any other reasons?) the compiler instead uses a lookup table. This table is dynamically constructed at runtime by a static initializer in a synthetic class. This avoids the "stale ordinal" problem of the simple approach, but it also creates a potential class initialization loop if there happens to an `Enum` switch inside an `Enum` class constructor, as demonstrated by the bug.
> 
> This patch makes the following change: If we are handling an `Enum` switch, and the `Enum` class we are switching on is also the class we are compiling, then just go with the simple approach, because the "stale ordinal" problem can't happen in this case so there's no need to build a runtime lookup table.
> 
> This results in two improvements:
> * It avoids building the lookup table for switches on self
> * It fixes JDK-7176515 as stated
> 
> Although the reproducing test case provided in JDK-7176515 gets fixed by this patch, the underlying issue is still there and can still be triggered with a slightly more complicated test case (included, but commented out).
> 
> So JDK-7176515 could be left open (or a new bug created) and a separate discussion had about how to "really" fix it.
> 
> Part of this discussion should be defining what that means, i.e., the boundaries of the bug. There are some scenarios that are basically impossible to fix, for example, two `Enum` classes whose constructors take as a parameter instances of the other `Enum` class and then switch on it. That cycle has nothing to do with how switches are handled.

This pull request has now been integrated.

Changeset: ac6af6a6
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac6af6a64099c182e982a0a718bc1b780cef616e
Stats:     195 lines in 4 files changed: 178 ins; 2 del; 15 mod

7176515: ExceptionInInitializerError for an enum with multiple switch statements
8299760: ExceptionInInitializerError for an enum with multiple switch statements, follow-up

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/10797

From jwaters at openjdk.org  Thu Mar 23 21:52:50 2023
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 23 Mar 2023 21:52:50 GMT
Subject: RFR: 8292275: javac does not emit SYNTHETIC and MANDATED flags for
 parameters by default [v7]
In-Reply-To: <WaPv9UnTrgGA05SHN3SGbhQwnvOm0AC_IwKY2xrkEq4=.10bb7fcd-048e-4797-80dd-0687fbceea71@github.com>
References: <cXBKN2YWuFVzdacmxsQvmYPy16bODPQvoyy_ovJ2EiM=.052011cd-598e-4bf7-bc10-3a2171f4b317@github.com>
 <Dp-1qd5RkSBC81YjJ1XkTioWSJQmdRCpHjfg6stdqhE=.f9a71aa3-08a5-4f30-9fda-74c2fce199ff@github.com>
 <WaPv9UnTrgGA05SHN3SGbhQwnvOm0AC_IwKY2xrkEq4=.10bb7fcd-048e-4797-80dd-0687fbceea71@github.com>
Message-ID: <JA9q5jhUF2w-PLjV-u8ymZesh6OJWVmj151G76TvpvQ=.39d0544d-2708-4ff6-8af0-25ff3e569e97@github.com>

On Thu, 23 Mar 2023 19:45:37 GMT, Hannes Greule <duke at openjdk.org> wrote:

>> Hannes Greule has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
>> 
>>  - Merge pull request #1 from liachmodded/methodparameters-flags
>>    
>>  - Update tests
>>  - Parity for the parameter flag tests in javac and reflection
>>  - Updated RequiredMethodParameterFlagTest, checks against Local classes as well
>>  - Merge branch 'master' into methodparameters-flags
>>  - Update copyright year
>>  - Merge remote-tracking branch 'upstream/master' into fix/enforce-methodparam_attr-if-mandated
>>  - address comments
>>  - cleanup
>>  - add annotation processing test
>>  - ... and 16 more: https://git.openjdk.org/jdk/compare/4653be2d...5ac3a214
>
> Test failures are caused by the Classfile API. I opened a separate PR to fix it: https://github.com/openjdk/jdk/pull/13167
> 
> Could someone create an issue on the bug tracker for me? Thanks.

@SirYwell On it!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/9862#issuecomment-1481959082

From vromero at openjdk.org  Fri Mar 24 05:22:31 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 05:22:31 GMT
Subject: RFR: 8291154: Create a non static nested class without enclosing
 class throws VerifyError [v2]
In-Reply-To: <zX1W84f6tbI2DwPuW1gqFpGA1sqR5pTWYTlcNSKro3o=.36e64542-7ff1-4cd6-a3f0-a6c0f5ba1231@github.com>
References: <6pcn3LwvxoB4pShWt0LB2ZMTGIhubUVChSmA_26dnYE=.e6d99613-9f14-42ff-ac86-c77d8f119277@github.com>
 <zX1W84f6tbI2DwPuW1gqFpGA1sqR5pTWYTlcNSKro3o=.36e64542-7ff1-4cd6-a3f0-a6c0f5ba1231@github.com>
Message-ID: <Ca8vLZMhiYImX_muKN6jj9WG8Us6BNW-FamdMmsTtAo=.dd3acd62-1c3a-4966-b83c-377b1d6daf9a@github.com>

On Wed, 11 Jan 2023 21:49:39 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The fix for [JDK-8254321](https://bugs.openjdk.org/browse/JDK-8254321) opened a loophole where a Java source file that defines a static nested class `B` that extends a non-static nested class `A` no longer generates an error if `B` is nested within `A`.
>> 
>> Here's an example:
>> 
>> class StaticNestedNonStaticSuper {
>>     public abstract class NonStaticNested {
>>         public static class StaticNested extends NonStaticNested {
>>             public StaticNested() {
>>                 // where is StaticNestedNonStaticSuper.this for super() going to come from??
>>             }
>>         }
>>     }
>> }
>> 
>> 
>> Of course this is illegal because the non-static nested superclass requires an outer 'this' instance to be passed as the first argument to all of its constructors, but the static nested subclass has no such outer 'this' to provide. The compiler was proceeding anyway, resulting in unverifiable bytecode.
>> 
>> This PR adds a check for this situation. The check is added at the point in `Lower.java` where superclass constructor invocations in subclasses of non-static nested classes add the outer 'this' instance as a first parameter to `super()`.
>> 
>> I'm not sure if this is the most appropriate location for this additional check, but at least it is in an optimal place to observe the problem when it happens.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify unit test.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/11954#pullrequestreview-1356016734

From duke at openjdk.org  Fri Mar 24 14:16:44 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 14:16:44 GMT
Subject: Integrated: 8291154: Create a non static nested class without
 enclosing class throws VerifyError
In-Reply-To: <6pcn3LwvxoB4pShWt0LB2ZMTGIhubUVChSmA_26dnYE=.e6d99613-9f14-42ff-ac86-c77d8f119277@github.com>
References: <6pcn3LwvxoB4pShWt0LB2ZMTGIhubUVChSmA_26dnYE=.e6d99613-9f14-42ff-ac86-c77d8f119277@github.com>
Message-ID: <Bx9XrPzp_GKP_ipHewpOBiYwOuUJhECXInNtIit_f5c=.fee538f0-057a-494c-9df1-1b390b8e1da8@github.com>

On Wed, 11 Jan 2023 21:33:08 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The fix for [JDK-8254321](https://bugs.openjdk.org/browse/JDK-8254321) opened a loophole where a Java source file that defines a static nested class `B` that extends a non-static nested class `A` no longer generates an error if `B` is nested within `A`.
> 
> Here's an example:
> 
> class StaticNestedNonStaticSuper {
>     public abstract class NonStaticNested {
>         public static class StaticNested extends NonStaticNested {
>             public StaticNested() {
>                 // where is StaticNestedNonStaticSuper.this for super() going to come from??
>             }
>         }
>     }
> }
> 
> 
> Of course this is illegal because the non-static nested superclass requires an outer 'this' instance to be passed as the first argument to all of its constructors, but the static nested subclass has no such outer 'this' to provide. The compiler was proceeding anyway, resulting in unverifiable bytecode.
> 
> This PR adds a check for this situation. The check is added at the point in `Lower.java` where superclass constructor invocations in subclasses of non-static nested classes add the outer 'this' instance as a first parameter to `super()`.
> 
> I'm not sure if this is the most appropriate location for this additional check, but at least it is in an optimal place to observe the problem when it happens.

This pull request has now been integrated.

Changeset: f96aee74
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f96aee74010476a850175f7012c196e40a31c188
Stats:     22 lines in 3 files changed: 21 ins; 0 del; 1 mod

8291154: Create a non static nested class without enclosing class throws VerifyError

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/11954

From vromero at openjdk.org  Fri Mar 24 14:33:39 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 14:33:39 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v5]
In-Reply-To: <as4AzSbMOe-GGit1gJx-9_BiP5W33fYFaWh0AValWE8=.78ae4d8b-5ab9-48ef-ae3c-160c350600fe@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <as4AzSbMOe-GGit1gJx-9_BiP5W33fYFaWh0AValWE8=.78ae4d8b-5ab9-48ef-ae3c-160c350600fe@github.com>
Message-ID: <4DoAYedGldjlEfe075Jwk8MfXBKWf1hnckh_ZlUgQc8=.e9d87add-da5a-48f5-bbcd-d89c6c7b2f01@github.com>

On Wed, 22 Mar 2023 02:49:17 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8303623
>  - In release 21, emit warning instead of error for invalid UTF-8.
>  - Use Fragments factory for creating message fragments.
>  - Fix incorrect parameter index in message fragment.
>  - Add the standard "This is NOT part of any supported API" warning.
>  - Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.
>  - Disallow non-standard UTF-8 string encodings.

src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java line 235:

> 233:                     return names.fromUtf(poolbuf.elems, offset + 2, len, utf8validation);
> 234:                 } catch (InvalidUtfException e) {
> 235:                     if (Source.DEFAULT == Source.JDK21) {

I think that a new feature should be added to `com.sun.tools.javac.code.Source.Feature`, could be named `WARN_ON_NON_STANDARD_UTF8` or so, and use it for this type of check. I would model the new feature based on `DEPRECATION_ON_IMPORT` with `MIN` as its applicable minimum version and 21 as the maximum applicable one

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12893#discussion_r1146977932

From duke at openjdk.org  Fri Mar 24 14:59:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 14:59:36 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v5]
In-Reply-To: <4DoAYedGldjlEfe075Jwk8MfXBKWf1hnckh_ZlUgQc8=.e9d87add-da5a-48f5-bbcd-d89c6c7b2f01@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <as4AzSbMOe-GGit1gJx-9_BiP5W33fYFaWh0AValWE8=.78ae4d8b-5ab9-48ef-ae3c-160c350600fe@github.com>
 <4DoAYedGldjlEfe075Jwk8MfXBKWf1hnckh_ZlUgQc8=.e9d87add-da5a-48f5-bbcd-d89c6c7b2f01@github.com>
Message-ID: <rBLsHQVH7mHULncJ8_6rCKOq-C0U4aB0t3eIduJ-uig=.0945a5f0-1ee6-4d37-a9b6-c67ad11ceab6@github.com>

On Thu, 23 Mar 2023 23:37:49 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8303623
>>  - In release 21, emit warning instead of error for invalid UTF-8.
>>  - Use Fragments factory for creating message fragments.
>>  - Fix incorrect parameter index in message fragment.
>>  - Add the standard "This is NOT part of any supported API" warning.
>>  - Allow longer-than-necessary UTF-8 encoding in classfiles with major < 48.
>>  - Disallow non-standard UTF-8 string encodings.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/PoolReader.java line 235:
> 
>> 233:                     return names.fromUtf(poolbuf.elems, offset + 2, len, utf8validation);
>> 234:                 } catch (InvalidUtfException e) {
>> 235:                     if (Source.DEFAULT == Source.JDK21) {
> 
> I think that a new feature should be added to `com.sun.tools.javac.code.Source.Feature`, could be named `WARN_ON_NON_STANDARD_UTF8` or so, and use it for this type of check. I would model the new feature based on `DEPRECATION_ON_IMPORT` with `MIN` as its applicable minimum version and 21 as the maximum applicable one

Thanks - that does sound like a more appropriate mechanism to use for controlling this. I'll work on an update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12893#discussion_r1147697360

From jlaskey at openjdk.org  Fri Mar 24 15:43:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RxrEhssrnI3LiefQdgqBY4GomOVQsL4ekmpvSeNujeU=.e2baec72-a21f-4b99-9847-c324d0914cc3@github.com>

On Wed, 22 Mar 2023 23:27:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:
> 
>> 1049:      * @param ptypes    list of expression types
>> 1050:      *
>> 1051:      * @return {@link MethodHandle}
> 
> Suggestion:
> 
>      * @return the {@link MethodHandle} for concatenation

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:
> 
>> 1167:      * have an extra {@link String} slot for the result from the previous
>> 1168:      * {@link MethodHandle}.
>> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}
> 
> Suggestion:
> 
>      * {@link #makeConcatWithTemplate}

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:
> 
>> 368:          */
>> 369:         private static Map<MethodType, CarrierElements>
>> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());
> 
> Suggestion:
> 
>                 methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:
> 
>> 419:          */
>> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
>> 421:             this.primitives = createPrimitivesArray(primitiveCount );
> 
> Suggestion:
> 
>             this.primitives = createPrimitivesArray(primitiveCount);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:
> 
>> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
>> 775:          */
>> 776:         static CarrierElements of(Class < ? >...ptypes) {
> 
> Suggestion:
> 
>         static CarrierElements of(Class<?>... ptypes) {

Changing

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:
> 
>> 47: interface ReferenceKey<T> {
>> 48:     /**
>> 49:      * {@return the value of the unwrapped key.}
> 
> Suggestion:
> 
>      * {@return the value of the unwrapped key}
> 
> Inline return tag generates a period already.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147750445
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752071
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757381
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752347
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147755043
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757878

From jlaskey at openjdk.org  Fri Mar 24 15:43:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
 <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
Message-ID: <rYN35QVpwQyTCYLdyjrhAReLGXJaJJ2Q8J3foqyXJBk=.79a0e847-4dba-4c6e-b38b-522bea0e8950@github.com>

On Wed, 22 Mar 2023 23:26:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As i said above, i consider this thread as resolved
>
> Suggestion:
> 
>      * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147748029

From jlaskey at openjdk.org  Fri Mar 24 15:51:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:51:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <WAU8fcqQiwVjG9k-aZS7r0XP4KN_R3qho0XhzjAZewA=.5256da3e-3d3f-4d42-9fc6-aae4a222f985@github.com>

On Wed, 22 Mar 2023 23:56:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:
> 
>> 125:     @SuppressWarnings("unchecked")
>> 126:     static <K, V> ReferencedKeyMap<K, V>
>> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {
> 
> What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

Remnants of when I was have issues with param types. Changed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147768901

From jlaskey at openjdk.org  Fri Mar 24 15:58:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:58:13 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <pugiPyGFAbHHDjJAkRR85ZzhOuXVeRcvMaUg164VzGc=.ebc126d8-3cbf-457b-a30f-444552472355@github.com>

On Thu, 23 Mar 2023 01:12:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:
> 
>> 38:  * <p>
>> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
>> 40:  * and sharing of value shapes without creating a new class for each shape.
> 
> Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

About a 15-20% performance gain by not having two levels of indirection.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:
> 
>> 86:      *
>> 87:      * @param fragments  string template fragments
>> 88:      * @param type       method type
> 
> Suggestion:
> 
>      * @param type method type accepting values' types and returning a StringTemplate

Changing

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147771982
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147775001

From vromero at openjdk.org  Fri Mar 24 17:34:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 17:34:27 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite [v2]
In-Reply-To: <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
 <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
Message-ID: <EJQeR9v3TrDEZlDGx2pBJ0Nnfxoojzv3NR5fbdnEgs0=.8209aa5b-31dd-4ea4-8bde-3afa8c356707@github.com>

On Tue, 21 Mar 2023 23:06:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).
>> 
>> The method `Name.compareTo()` looks like this:
>> 
>> /** An arbitrary but consistent complete order among all Names.
>>  */
>> public int compareTo(Name other) {
>>     return other.getIndex() - this.getIndex();
>> }
>> 
>> Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.
>> 
>> For example, if you apply this patch:
>> 
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
>> @@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
>>      /** An arbitrary but consistent complete order among all Names.
>>       */
>>      public int compareTo(Name other) {
>> -        return other.getIndex() - this.getIndex();
>> +        return this.getIndex() - other.getIndex();
>>      }
>> 
>>      /** Return true if this is the empty name.
>> 
>> then the following tests will fail:
>> ```TEST: tools/javac/8203436/T8203436b.java
>> TEST: tools/javac/generics/7034019/T7034019c.java
>> TEST: tools/javac/generics/7034019/T7034019d.java
>> TEST: tools/javac/generics/diamond/neg/Neg21.java
>> TEST: tools/javac/generics/diamond/neg/Neg22.java
>> TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
>> TEST: tools/javac/patterns/InferenceUnitTest.java
>> TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
>> TEST: tools/javac/varargs/6806876/T6806876.java
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
>> ==============================
>> 
>> The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.
>> 
>> It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:
>> 
>> /**
>>  * A partial ordering between type symbols that refines the
>>  * class inheritance graph.
>>  *
>>  * Type variables always precede other kinds of symbols.
>>  */
>> public final boolean precedes(TypeSymbol that, Types types) {
>>     if (this == that)
>>         return false;
>>     if (type.hasTag(that.type.getTag())) {
>>         if (type.hasTag(CLASS)) {
>>             return
>>                 types.rank(that.type) < types.rank(this.type) ||
>>                 types.rank(that.type) == types.rank(this.type) &&
>>                 that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>>         } else if (type.hasTag(TYPEVAR)) {
>>             return types.isSubtype(this.type, that.type);
>>         }
>>     }
>>     return type.hasTag(TYPEVAR);
>> }
>> 
>> If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.
>> 
>> An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.
>> 
>> Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.
>> 
>> When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.
>> 
>> So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.
>> 
>> That's what this patch does.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8303526
>  - Require Name.compareTo() to produce a lexicographic ordering.

sorry if I'm missing something but I'm not totally sure what we are fixing here, I mean it could be that the current code is not arbitrarily consistent but it is faster than the proposed implementation

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12843#issuecomment-1483170917

From vromero at openjdk.org  Fri Mar 24 18:24:11 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 18:24:11 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>
Message-ID: <DHL64Jm1uzy3Jrqv5RRTCwl-XmmK5IYUkI9ZNnVibbk=.49f10a88-bb9d-467a-b2a9-19a090324e8d@github.com>

On Thu, 23 Mar 2023 04:28:19 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make fix contingent on --release 14
>>   
>>   based on discussion in CSR.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3515:
> 
>> 3513:         List<Attribute> targets = typeAnnotations.annotationTargets(a.annotationType.type.tsym);
>> 3514:         return (targets == null) ?
>> 3515:                 (source.compareTo(Source.JDK14) >= 0 && isTypeParameter) :
> 
> Usually this kind of test is done using a constant in the Feature enum; I'll let Vicente or other engineer who focuses on javac weigh in on whether or not the direct comparison is acceptable in this case.

right I agree we should add a new member to the Feature enum

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1147924651

From cushon at openjdk.org  Fri Mar 24 19:03:33 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 24 Mar 2023 19:03:33 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <DHL64Jm1uzy3Jrqv5RRTCwl-XmmK5IYUkI9ZNnVibbk=.49f10a88-bb9d-467a-b2a9-19a090324e8d@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>
 <DHL64Jm1uzy3Jrqv5RRTCwl-XmmK5IYUkI9ZNnVibbk=.49f10a88-bb9d-467a-b2a9-19a090324e8d@github.com>
Message-ID: <7IkTayj3uMlEMQIE9GfIsApBAPYZWdAJSWxaHhK_SIM=.982c7fdb-41d7-4242-ab84-843b198ada00@github.com>

On Fri, 24 Mar 2023 18:20:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Check.java line 3515:
>> 
>>> 3513:         List<Attribute> targets = typeAnnotations.annotationTargets(a.annotationType.type.tsym);
>>> 3514:         return (targets == null) ?
>>> 3515:                 (source.compareTo(Source.JDK14) >= 0 && isTypeParameter) :
>> 
>> Usually this kind of test is done using a constant in the Feature enum; I'll let Vicente or other engineer who focuses on javac weigh in on whether or not the direct comparison is acceptable in this case.
>
> right I agree we should add a new member to the Feature enum

Will do, do you have an preferences for the name of the new constant? Maybe `NO_TARGET_ANNOTATIONS_ARE_APPLICABLE_TO_TYPE_PARAMETER_DECLARATIONS`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1147959011

From vromero at openjdk.org  Fri Mar 24 19:29:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 19:29:35 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <7IkTayj3uMlEMQIE9GfIsApBAPYZWdAJSWxaHhK_SIM=.982c7fdb-41d7-4242-ab84-843b198ada00@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>
 <DHL64Jm1uzy3Jrqv5RRTCwl-XmmK5IYUkI9ZNnVibbk=.49f10a88-bb9d-467a-b2a9-19a090324e8d@github.com>
 <7IkTayj3uMlEMQIE9GfIsApBAPYZWdAJSWxaHhK_SIM=.982c7fdb-41d7-4242-ab84-843b198ada00@github.com>
Message-ID: <unHhiqWCgSPMwY3nYeyAL3JD7UOX_rfYBZzOGC8prXA=.3a1039cc-199a-4759-a2d9-1efdc3aef826@github.com>

On Fri, 24 Mar 2023 19:00:51 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> right I agree we should add a new member to the Feature enum
>
> Will do, do you have an preferences for the name of the new constant? Maybe `NO_TARGET_ANNOTATIONS_ARE_APPLICABLE_TO_TYPE_PARAMETER_DECLARATIONS`?

not really but that one seems too long tbh

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1147979394

From cushon at openjdk.org  Fri Mar 24 19:43:14 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 24 Mar 2023 19:43:14 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v5]
In-Reply-To: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
Message-ID: <3Tzr1KbcmKU7bCPvAsk92TzuEXWybLm-GpkTpuJAy0Q=.acc7e245-9395-46b0-92ec-7e5cd74423d0@github.com>

> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
> 
> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.

Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:

  Use Feature enum for version checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12914/files
  - new: https://git.openjdk.org/jdk/pull/12914/files/57c4515c..749af3cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12914&range=03-04

  Stats: 4 lines in 3 files changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12914/head:pull/12914

PR: https://git.openjdk.org/jdk/pull/12914

From cushon at openjdk.org  Fri Mar 24 19:43:16 2023
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 24 Mar 2023 19:43:16 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v3]
In-Reply-To: <unHhiqWCgSPMwY3nYeyAL3JD7UOX_rfYBZzOGC8prXA=.3a1039cc-199a-4759-a2d9-1efdc3aef826@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <UXjBqjbKoteiHjRDnnOrN457rieFRj5p3T2KnQnJ9XY=.5c6105d2-4da9-4c1a-8355-d5c0142ecb47@github.com>
 <DJKBhJ_xiOz1JiX4T2o17lPuYkrXxmvhibo0LlR1K6Q=.45941be9-ed88-4ba8-aae9-4f20ef279c1d@github.com>
 <DHL64Jm1uzy3Jrqv5RRTCwl-XmmK5IYUkI9ZNnVibbk=.49f10a88-bb9d-467a-b2a9-19a090324e8d@github.com>
 <7IkTayj3uMlEMQIE9GfIsApBAPYZWdAJSWxaHhK_SIM=.982c7fdb-41d7-4242-ab84-843b198ada00@github.com>
 <unHhiqWCgSPMwY3nYeyAL3JD7UOX_rfYBZzOGC8prXA=.3a1039cc-199a-4759-a2d9-1efdc3aef826@github.com>
Message-ID: <no86BkWawgpvl-7v-2fQElpBs3yERMkSnCw3SVCVucc=.b63212e8-d6a0-48bf-ac25-8cadb6227b40@github.com>

On Fri, 24 Mar 2023 19:26:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Will do, do you have an preferences for the name of the new constant? Maybe `NO_TARGET_ANNOTATIONS_ARE_APPLICABLE_TO_TYPE_PARAMETER_DECLARATIONS`?
>
> not really but that one seems too long tbh

I went with `NO_TARGET_ANNOTATION_APPLICABILITY`, I'm happy to rename it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12914#discussion_r1147986669

From vromero at openjdk.org  Fri Mar 24 20:42:32 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 24 Mar 2023 20:42:32 GMT
Subject: RFR: 8303784: no-@Target annotations should be applicable to type
 parameter declarations [v5]
In-Reply-To: <3Tzr1KbcmKU7bCPvAsk92TzuEXWybLm-GpkTpuJAy0Q=.acc7e245-9395-46b0-92ec-7e5cd74423d0@github.com>
References: <SKGx76m09IB7pSXLYy0A-7H-40ZKqGBvrfCEjGEf7Vg=.18a0d363-ef54-40fb-9582-8140bfbb7ac8@github.com>
 <3Tzr1KbcmKU7bCPvAsk92TzuEXWybLm-GpkTpuJAy0Q=.acc7e245-9395-46b0-92ec-7e5cd74423d0@github.com>
Message-ID: <d6nrgls7DeEe7wX89nN782ZaqAjiLjV5nHYQ8pytF5o=.426d066c-d417-4b1d-b89c-63c3f10c03ab@github.com>

On Fri, 24 Mar 2023 19:43:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> Please consider this fix for https://bugs.openjdk.org/browse/JDK-8303784, which make `@Target`-less annotations applicable to type parameter declarations.
>> 
>> `@Target`-less annotations are applicable to 'all declaration contexts', which includes type parameter declarations.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Feature enum for version checks

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12914#pullrequestreview-1357391301

From duke at openjdk.org  Fri Mar 24 21:27:19 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 21:27:19 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v4]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <87eI6Y6b8JoIDlf5qKX12RcTat4P6k5GT6HiCWDnykk=.f9541ab6-ff57-4160-a8ff-73dfbd104edc@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Use a lint flag "output-file-clash" instead of a command line flag.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/51134ddf..b255ed85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=02-03

  Stats: 30 lines in 6 files changed: 15 ins; 11 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Fri Mar 24 21:41:23 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 21:41:23 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v5]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <fsjGFaaCiiC0yRzt08wx1x2TYCZANFH01PpwV7vvN-0=.b5a87160-5f7f-4fb1-94e7-acae5de69c9d@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Convert "output-file-clash" from an error into a warning.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/b255ed85..7d2af149

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=03-04

  Stats: 11 lines in 3 files changed: 6 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Fri Mar 24 21:49:06 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 21:49:06 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v6]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <7eImcChf7gbeIss-uVZwvpKWtnKosnrVUMwBCRePnSc=.355519da-d2c8-4cda-bf76-96affadd8328@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Improve warning wording to "output file written more than once".

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/7d2af149..26b758e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From duke at openjdk.org  Fri Mar 24 22:23:29 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 22:23:29 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite [v2]
In-Reply-To: <EJQeR9v3TrDEZlDGx2pBJ0Nnfxoojzv3NR5fbdnEgs0=.8209aa5b-31dd-4ea4-8bde-3afa8c356707@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
 <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
 <EJQeR9v3TrDEZlDGx2pBJ0Nnfxoojzv3NR5fbdnEgs0=.8209aa5b-31dd-4ea4-8bde-3afa8c356707@github.com>
Message-ID: <Wdjv58dZd7MNb8c64zZO_7MNDLYuO_OHAMfP1yc6nF4=.c259bf86-4242-4000-a6b3-e15512c02843@github.com>

On Fri, 24 Mar 2023 17:31:58 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> sorry if I'm missing something but I'm not totally sure what we are fixing here, I mean it could be that the current code is not arbitrarily consistent but it is faster than the proposed implementation

I can explain the problem we're fixing... I think the real question here though is whether the problem we're fixing is a big enough problem that it need to be fixed, or just not worth worrying about.

The problem is that the specification of `Name.compareTo()` is so loose that it introduces a source of non-determinism in the compiler that is dependent on (for example) the order in which class files are read. That non-determinism then flows into `TypeSymbol.precedes()`.

So the real question is, do we really want `TypeSymbol.precedes()` potentially sorting `TypeSymbols` differently each time?

I can't really say definitively, because I'm not familiar with this method - so I'm just basing my opinion on the circumstantial evidence that there are 9 regression tests that are sensitive to this ordering, and also my overall general feeling that needless non-determinism is always a bad thing in computer software because it makes everything harder to debug.

The downside of this patch is a slower implementation of `TypeSymbol.precedes()` - again, I'm not familiar with this method so unsure how critical it is. Also, note that this downside may happen in the future regardless if/when the `Name` classes get refactored to just be `String` wrappers, etc.

So... I dunno. Your thoughts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12843#issuecomment-1483505124

From duke at openjdk.org  Fri Mar 24 22:54:20 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 24 Mar 2023 22:54:20 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v6]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <bmD_nc4qWvAnyQDS3TEBtvZieea8FWKA9Tgumv7huTI=.0f40adbd-1903-4cf4-beb4-a94b4091daf9@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Control behavior via a Feature instead of via direct Source comparison.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/dbe2485c..41642d66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=04-05

  Stats: 9 lines in 3 files changed: 6 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From duke at openjdk.org  Sat Mar 25 22:08:23 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Sat, 25 Mar 2023 22:08:23 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v7]
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <ROtUlyyAchZ1xcrsoRnVus8zFMnONQLtEmPkSgD7MDs=.e15eecc6-125e-46ec-b09b-3223f8758539@github.com>

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Add "compiler.warn.output.file.clash" to message example exclusion file.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12754/files
  - new: https://git.openjdk.org/jdk/pull/12754/files/26b758e8..73ab9af7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12754&range=05-06

  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/12754.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12754/head:pull/12754

PR: https://git.openjdk.org/jdk/pull/12754

From jlahoda at openjdk.org  Mon Mar 27 13:55:41 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 27 Mar 2023 13:55:41 GMT
Subject: RFR: 8304883: Record Deconstruction causes bytecode error
Message-ID: <UJXrdZhKChHxDVCLJQ4ym1RaA_8v2D3Pmpxo9uGv-R4=.fdb1473e-62cf-4f99-8aed-16b2abc7bed1@github.com>

Originally, we used to support cases like:
`case null, String s when s.isEmpty() -> <expression>`
where `s` could be `null` inside the expression, but the guard was only evaluated when `s != null`. This was implemented by augmenting the guard with `s == null || <original-guard>`.

This feature has been dropped since then.

Also note that in other cases, like:

record R(Object o) {}
Object o = new R(null);
switch (o) {
    case R(var v) when v.toString().isEmpty() -> {}
}


We always expected a NPE on dereferencing the binding with value `null` (`v` in this case) in guard.

But, the code to implement the `case null, <binding>` remained in javac, and is causing problems, because, while the user cannot write `case null, <binding>` anymore, internally the desugaring sometimes generates that (when factoring out common prefixes). And the original code will still augment the guards to `<binding> == null || <guard>`, which causes the variables that are assigned in the guard to not being definitely assigned after the augmented guard.

The proposal is to simply remove the code that adds `<binding> == null || <guard>`, as there's no case where we would skip guards for `null` bindings anymore.

-------------

Commit messages:
 - 8304883: Record Deconstruction causes bytecode error

Changes: https://git.openjdk.org/jdk/pull/13192/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304883
  Stats: 62 lines in 2 files changed: 46 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13192/head:pull/13192

PR: https://git.openjdk.org/jdk/pull/13192

From jlahoda at openjdk.org  Mon Mar 27 15:05:26 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 27 Mar 2023 15:05:26 GMT
Subject: Integrated: 8304694: Runtime exception thrown when break stmt is
 missing
In-Reply-To: <a9277IynOCexUnHr_7QYH5A43kSZVQypO7zOmpgx3_Q=.8996b8a6-53d0-4144-8103-1fb217be7946@github.com>
References: <a9277IynOCexUnHr_7QYH5A43kSZVQypO7zOmpgx3_Q=.8996b8a6-53d0-4144-8103-1fb217be7946@github.com>
Message-ID: <8h92ryfg21sPVG4uGiSjv8dE7ACqIfmNItrK_6Qe8zY=.4c2592d8-13be-41a3-80e6-6e7f02fda80d@github.com>

On Wed, 22 Mar 2023 16:14:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> For code like this:
> 
>     public static int runFallThrough(R6 r) {
>         switch (r) {
>             case R6(var v1, var v2) when v1 != 0: return 0;
>             case R6(var v1, var v2):
>         }
>         return 1;
>     }
> 
> 
> The execution falls through from the last case not outside the switch, but inside the fallback default case (that throws).
> 
> The current code is injecting breaks, but only for rule cases, and this situation where the last case needs a break is not handled. To simplify the code, it is now proposed to inject breaks at the beginning of the processing (rather than during processing/at the end) to all necessary cases.

This pull request has now been integrated.

Changeset: 138cdc92
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/138cdc9283ae8f3367e51f0fe7e27833118dd7cb
Stats:     21 lines in 2 files changed: 15 ins; 2 del; 4 mod

8304694: Runtime exception thrown when break stmt is missing

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/13146

From vromero at openjdk.org  Mon Mar 27 15:54:41 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 15:54:41 GMT
Subject: RFR: 8304883: Record Deconstruction causes bytecode error
In-Reply-To: <UJXrdZhKChHxDVCLJQ4ym1RaA_8v2D3Pmpxo9uGv-R4=.fdb1473e-62cf-4f99-8aed-16b2abc7bed1@github.com>
References: <UJXrdZhKChHxDVCLJQ4ym1RaA_8v2D3Pmpxo9uGv-R4=.fdb1473e-62cf-4f99-8aed-16b2abc7bed1@github.com>
Message-ID: <n2ASEBYqegaPEbrCI_jBwYAb2U5TIRxiVUgxalZRWRg=.29052998-7b7c-4984-887a-0f185956ef0c@github.com>

On Mon, 27 Mar 2023 13:46:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Originally, we used to support cases like:
> `case null, String s when s.isEmpty() -> <expression>`
> where `s` could be `null` inside the expression, but the guard was only evaluated when `s != null`. This was implemented by augmenting the guard with `s == null || <original-guard>`.
> 
> This feature has been dropped since then.
> 
> Also note that in other cases, like:
> 
> record R(Object o) {}
> Object o = new R(null);
> switch (o) {
>     case R(var v) when v.toString().isEmpty() -> {}
> }
> 
> 
> We always expected a NPE on dereferencing the binding with value `null` (`v` in this case) in guard.
> 
> But, the code to implement the `case null, <binding>` remained in javac, and is causing problems, because, while the user cannot write `case null, <binding>` anymore, internally the desugaring sometimes generates that (when factoring out common prefixes). And the original code will still augment the guards to `<binding> == null || <guard>`, which causes the variables that are assigned in the guard to not being definitely assigned after the augmented guard.
> 
> The proposal is to simply remove the code that adds `<binding> == null || <guard>`, as there's no case where we would skip guards for `null` bindings anymore.

lgtm

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransPatterns.java line 539:

> 537:                             JCExpression guard = translate(label.guard);
> 538:                             if (hasJoinedNull) {
> 539:                                 JCPattern pattern = label.pat;

side: this idiom seems to be useful, currently used in a couple of places in Check, could it make sense to extract it into a method?

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13192#pullrequestreview-1359366690
PR Review Comment: https://git.openjdk.org/jdk/pull/13192#discussion_r1149453512

From jlaskey at openjdk.org  Mon Mar 27 16:17:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 16:17:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v49]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <m87R9KqgHRFWTaSkiHHK9nbPl0Q9dnSrR0phYMEJpFg=.19cf87ba-2f6a-476c-83e3-e89ff7ba77c3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested review changes.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/96752c64..58eeb319

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=47-48

  Stats: 179 lines in 12 files changed: 31 ins; 116 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jjg at openjdk.org  Mon Mar 27 16:55:21 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Mar 2023 16:55:21 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v2]
In-Reply-To: <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
Message-ID: <9U09VLZk3ZlBd9lWWT7U_VGLUc43GBD1DP7QhKmaLps=.8df50a7b-bf37-4a6c-8075-3d912713bb27@github.com>

On Fri, 17 Mar 2023 16:27:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Corrections from review
>  - Merge branch 'master' into 8303912
>  - Clean up JavadocTokenizer

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1200:

> 1198:          * LINE starting with //
> 1199:          * BLOCK starting with /*
> 1200:          * JAVADOC starting with /**

The detail here would be better as comments on the enum members.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1250:

> 1248:          * LINE starting with //
> 1249:          * BLOCK starting with /*
> 1250:          * JAVADOC starting with /**

duplicates info on the decl for `cs`; suggest moving the info to the enum declaration members

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12953#discussion_r1149541782
PR Review Comment: https://git.openjdk.org/jdk/pull/12953#discussion_r1149544294

From jjg at openjdk.org  Mon Mar 27 17:01:32 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Mar 2023 17:01:32 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v2]
In-Reply-To: <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
Message-ID: <qwpmKy1YvqYJdf7lLVaMHffXNyrQbYvQ6D1jio_pWkE=.1681abb0-a047-441d-9956-dd09cd0ddfdd@github.com>

On Fri, 17 Mar 2023 16:27:10 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Corrections from review
>  - Merge branch 'master' into 8303912
>  - Clean up JavadocTokenizer

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1280:

> 1278:             return line.accept("@deprecated") &&
> 1279:                     (line.isWhitespace() || line.is('*') || line.isEOLN());
> 1280:         }

I note for the record that this is inadequate, given that we now skip over such content in inline tags. This is an unexpected side-effect of that change.  In other words, consider a `{@code...}` tag containing a line with `@deprecated`.

I am not suggesting we do anything about it at this time, but it is worth noting.

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1311:

> 1309: 
> 1310:         /**
> 1311:          * Trim the first part of the Javadoc comment.

Suggestion:

         * Trim the first part of the JavaDoc comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12953#discussion_r1149548220
PR Review Comment: https://git.openjdk.org/jdk/pull/12953#discussion_r1149550710

From jlaskey at openjdk.org  Mon Mar 27 17:17:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 17:17:47 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v3]
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <wodsS1uArSgm2UFHzjyWFG7rD6nvHiWVgJRLtob5C9Y=.32cb8398-90e3-436b-a617-36b34a353254@github.com>

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Recommended changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12953/files
  - new: https://git.openjdk.org/jdk/pull/12953/files/e3e31d09..6e3be1eb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=01-02

  Stats: 11 lines in 3 files changed: 0 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/12953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12953/head:pull/12953

PR: https://git.openjdk.org/jdk/pull/12953

From jlaskey at openjdk.org  Mon Mar 27 17:17:52 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 17:17:52 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v2]
In-Reply-To: <qwpmKy1YvqYJdf7lLVaMHffXNyrQbYvQ6D1jio_pWkE=.1681abb0-a047-441d-9956-dd09cd0ddfdd@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <0J_Nx0GrkGZSny17212leih4uHV8AXj1v0qSD9nWC6Q=.50c878c4-b48f-4c83-b4a2-deedbfe29af5@github.com>
 <qwpmKy1YvqYJdf7lLVaMHffXNyrQbYvQ6D1jio_pWkE=.1681abb0-a047-441d-9956-dd09cd0ddfdd@github.com>
Message-ID: <l2HsyonPOoWNXFalsn6Plfr1leJJz_VFSfiGsr8jY50=.f81fe4a2-3e14-40be-9a4c-b8887af94abd@github.com>

On Mon, 27 Mar 2023 16:55:44 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - Corrections from review
>>  - Merge branch 'master' into 8303912
>>  - Clean up JavadocTokenizer
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1280:
> 
>> 1278:             return line.accept("@deprecated") &&
>> 1279:                     (line.isWhitespace() || line.is('*') || line.isEOLN());
>> 1280:         }
> 
> I note for the record that this is inadequate, given that we now skip over such content in inline tags. This is an unexpected side-effect of that change.  In other words, consider a `{@code...}` tag containing a line with `@deprecated`.
> 
> I am not suggesting we do anything about it at this time, but it is worth noting.

This code is basically maintain the status quo - in a more efficient manner.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12953#discussion_r1149561275

From jjg at openjdk.org  Mon Mar 27 18:11:54 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 27 Mar 2023 18:11:54 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v3]
In-Reply-To: <wodsS1uArSgm2UFHzjyWFG7rD6nvHiWVgJRLtob5C9Y=.32cb8398-90e3-436b-a617-36b34a353254@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
 <wodsS1uArSgm2UFHzjyWFG7rD6nvHiWVgJRLtob5C9Y=.32cb8398-90e3-436b-a617-36b34a353254@github.com>
Message-ID: <pd7QV2fIBdavyGrG5H4JMuYjKwxGZXk9FlgVRNwlfVM=.52c4f3ea-e3eb-49a7-9f2e-7f68a97ad3ab@github.com>

On Mon, 27 Mar 2023 17:17:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Recommended changes

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12953#pullrequestreview-1359621594

From vromero at openjdk.org  Mon Mar 27 18:30:04 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 18:30:04 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v7]
In-Reply-To: <ROtUlyyAchZ1xcrsoRnVus8zFMnONQLtEmPkSgD7MDs=.e15eecc6-125e-46ec-b09b-3223f8758539@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
 <ROtUlyyAchZ1xcrsoRnVus8zFMnONQLtEmPkSgD7MDs=.e15eecc6-125e-46ec-b09b-3223f8758539@github.com>
Message-ID: <QecqJgFnfOLPxvMHabYiap4Igc8MxoCDnh_sqgL469c=.24ca9b2b-03f4-40ea-9690-74590768a603@github.com>

On Sat, 25 Mar 2023 22:08:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
>> 
>> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
>> 
>> public class Test {
>>     interface Cafe\u0301 {
>>     }
>>     interface Caf\u00e9 {
>>     }
>> }
>> 
>> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
>> 
>> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
>> 
>> $ javac --help-extra
>>   ...
>>   --detect-output-file-clashes
>>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>>   ...
>> $ javac --detect-output-file-clashes Test.java
>> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>>     interface Caf\u00e9 {
>>     ^
>> 1 error
>> 
>> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
>> 
>> **Outstanding Questions**
>> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
>> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "compiler.warn.output.file.clash" to message example exclusion file.

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12754#pullrequestreview-1359652933

From arnoldnunag12 at gmail.com  Mon Mar 27 19:11:26 2023
From: arnoldnunag12 at gmail.com (Arnold Alejo Nunag)
Date: Tue, 28 Mar 2023 03:11:26 +0800
Subject: Additional info for report form bug 9075022: local (sub)classes and
 lambdas
Message-ID: <9891a540-cba8-383a-af24-a9ac60699ce5@gmail.com>

Hello,

A few hours ago, I reported a compiler bug through the Bug Report form 
at bugreport.java.com. Since then, a developer friend who discovered the 
issue dug into it and found a bit more information.

The bug number given to me by the form was 9075022. To summarize the 
issue, for reference: if a local class is defined in a method which uses 
a parameter from said method (whether in methods or field initializers), 
and within the method is a lambda which contains a (local) subclass of 
that local class, then attempting to instantiate the local class or 
local subclass within the lambda causes a compiler crash.

Here is example source code which shows the crash when tried to be 
compiled by Java 12 and later:

public abstract class JavacBug {

 ??? public abstract void consume(Runnable r);

 ??? public void doThing(String parameter) {
 ??????? class LocalClass {

 ??????????? @Override
 ??????????? public String toString() {
 ??????????????? return parameter;
 ??????????? }
 ??????? }

 ??????? consume(() -> {
 ??????????? class LambdaLocalClass extends LocalClass {
 ??????????? }

 ??????????? new LocalClass();
 ??????? });
 ??? }
}

Compiling the above results in the following crash on Java 21 EA 
(similar stacktraces are shown for all other affected Java versions):

java.lang.AssertionError
 ??????? at jdk.compiler/com.sun.tools.javac.util.Assert.error(Assert.java:155)
 ??????? at jdk.compiler/com.sun.tools.javac.util.Assert.check(Assert.java:46)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Items$LocalItem.<init>(Items.java:392)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Items.makeLocalItem(Items.java:133)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitIdent(Gen.java:2327)
 ??????? at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCIdent.accept(JCTree.java:2681)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:884)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genArgs(Gen.java:909)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitApply(Gen.java:1925)
 ??????? at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodInvocation.accept(JCTree.java:1817)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genExpr(Gen.java:884)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitExec(Gen.java:1793)
 ??????? at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCExpressionStatement.accept(JCTree.java:1604)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:613)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:648)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:634)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStats(Gen.java:685)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.doVisitBlock(Gen.java:1127)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitBlock(Gen.java:1120)
 ??????? at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCBlock.accept(JCTree.java:1088)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:613)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genStat(Gen.java:648)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genMethod(Gen.java:974)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.visitMethodDef(Gen.java:937)
 ??????? at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCMethodDecl.accept(JCTree.java:912)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genDef(Gen.java:613)
 ??????? at jdk.compiler/com.sun.tools.javac.jvm.Gen.genClass(Gen.java:2471)
 ??????? at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.genCode(JavaCompiler.java:751)
 ??????? at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1681)
 ??????? at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.generate(JavaCompiler.java:1649)
 ??????? at jdk.compiler/com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:960)
 ??????? at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:317)
 ??????? at jdk.compiler/com.sun.tools.javac.main.Main.compile(Main.java:176)
 ??????? at jdk.compiler/com.sun.tools.javac.Main.compile(Main.java:64)
 ??????? at jdk.compiler/com.sun.tools.javac.Main.main(Main.java:50)

As described in my original bug report, the issue exists in Java 12 and 
above.

As mentioned above, my developer friend dug into the issue and bisected 
JDK 12 to find the commit that introduced the regression, which seems to 
be 
https://github.com/openjdk/jdk12/commit/1ed6b88a9965efb2992f158bdb96b86d38cb9a45.

I hope this information will be useful in debugging and fixing the issue.

(As an aside, it does seem a bit unfriendly that there is no way to add 
on additional information to a report after being submitted through the 
online form, nor is the report made accessible to the reporter, whether 
through the site or even a copy sent to the reporter's email address. 
Where would I bring this up for further discussion?)

Regards,
Arnold (@sciwhiz12)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230328/c4aa1271/attachment-0001.htm>

From vromero at openjdk.org  Mon Mar 27 19:49:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 19:49:25 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v6]
In-Reply-To: <bmD_nc4qWvAnyQDS3TEBtvZieea8FWKA9Tgumv7huTI=.0f40adbd-1903-4cf4-beb4-a94b4091daf9@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <bmD_nc4qWvAnyQDS3TEBtvZieea8FWKA9Tgumv7huTI=.0f40adbd-1903-4cf4-beb4-a94b4091daf9@github.com>
Message-ID: <fMb2MK9-9ib2xXehH532WDWqIJ1HB9IU8EsaamO4DkI=.c17922e6-3ee5-42c6-bcad-077cb0b007db@github.com>

On Fri, 24 Mar 2023 22:54:20 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Control behavior via a Feature instead of via direct Source comparison.

src/jdk.compiler/share/classes/com/sun/tools/javac/util/Convert.java line 71:

> 69:      * Do strict validation of UTF-8. At this level, each character has only one valid encoding.
> 70:      */
> 71:     public static final int UTF8_STRICT = 2;

this three constants could be converted into an enum

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12893#discussion_r1149718058

From vromero at openjdk.org  Mon Mar 27 20:07:50 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 20:07:50 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite [v2]
In-Reply-To: <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
 <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
Message-ID: <c7xGeGul2Vtic75rB8JKxbAyZZTJnFqZnTy1y-zKHZk=.45819694-58a8-4fd0-a2d2-3b83d3e2753e@github.com>

On Tue, 21 Mar 2023 23:06:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).
>> 
>> The method `Name.compareTo()` looks like this:
>> 
>> /** An arbitrary but consistent complete order among all Names.
>>  */
>> public int compareTo(Name other) {
>>     return other.getIndex() - this.getIndex();
>> }
>> 
>> Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.
>> 
>> For example, if you apply this patch:
>> 
>> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
>> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
>> @@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
>>      /** An arbitrary but consistent complete order among all Names.
>>       */
>>      public int compareTo(Name other) {
>> -        return other.getIndex() - this.getIndex();
>> +        return this.getIndex() - other.getIndex();
>>      }
>> 
>>      /** Return true if this is the empty name.
>> 
>> then the following tests will fail:
>> ```TEST: tools/javac/8203436/T8203436b.java
>> TEST: tools/javac/generics/7034019/T7034019c.java
>> TEST: tools/javac/generics/7034019/T7034019d.java
>> TEST: tools/javac/generics/diamond/neg/Neg21.java
>> TEST: tools/javac/generics/diamond/neg/Neg22.java
>> TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
>> TEST: tools/javac/patterns/InferenceUnitTest.java
>> TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
>> TEST: tools/javac/varargs/6806876/T6806876.java
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
>> ==============================
>> 
>> The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.
>> 
>> It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:
>> 
>> /**
>>  * A partial ordering between type symbols that refines the
>>  * class inheritance graph.
>>  *
>>  * Type variables always precede other kinds of symbols.
>>  */
>> public final boolean precedes(TypeSymbol that, Types types) {
>>     if (this == that)
>>         return false;
>>     if (type.hasTag(that.type.getTag())) {
>>         if (type.hasTag(CLASS)) {
>>             return
>>                 types.rank(that.type) < types.rank(this.type) ||
>>                 types.rank(that.type) == types.rank(this.type) &&
>>                 that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>>         } else if (type.hasTag(TYPEVAR)) {
>>             return types.isSubtype(this.type, that.type);
>>         }
>>     }
>>     return type.hasTag(TYPEVAR);
>> }
>> 
>> If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.
>> 
>> An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.
>> 
>> Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.
>> 
>> When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.
>> 
>> So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.
>> 
>> That's what this patch does.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge branch 'master' into JDK-8303526
>  - Require Name.compareTo() to produce a lexicographic ordering.

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12843#pullrequestreview-1359792282

From vromero at openjdk.org  Mon Mar 27 20:07:52 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 20:07:52 GMT
Subject: RFR: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite [v2]
In-Reply-To: <Wdjv58dZd7MNb8c64zZO_7MNDLYuO_OHAMfP1yc6nF4=.c259bf86-4242-4000-a6b3-e15512c02843@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
 <Urid3aH1yqDZa8JHXb3lx8Xrk3mVxMuwV4_YPHBZJ0U=.cc6ec126-7cd0-44a4-8aa6-b34783a53033@github.com>
 <EJQeR9v3TrDEZlDGx2pBJ0Nnfxoojzv3NR5fbdnEgs0=.8209aa5b-31dd-4ea4-8bde-3afa8c356707@github.com>
 <Wdjv58dZd7MNb8c64zZO_7MNDLYuO_OHAMfP1yc6nF4=.c259bf86-4242-4000-a6b3-e15512c02843@github.com>
Message-ID: <qZ9l3JGsKhnapOZUvO0PZSz_JGcegq7iny6isoPNQSs=.7c4904fb-962c-4b60-be9a-8dc18fd3918f@github.com>

On Fri, 24 Mar 2023 22:20:48 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> > sorry if I'm missing something but I'm not totally sure what we are fixing here, I mean it could be that the current code is not arbitrarily consistent but it is faster than the proposed implementation
> 
> I can explain the problem we're fixing... I think the real question here though is whether the problem we're fixing is a big enough problem that it need to be fixed, or just not worth worrying about.
> 
> The problem is that the specification of `Name.compareTo()` is so loose that it introduces a source of non-determinism in the compiler that is dependent on (for example) the order in which class files are read. That non-determinism then flows into `TypeSymbol.precedes()`.
> 
> So the real question is, do we really want `TypeSymbol.precedes()` potentially sorting `TypeSymbols` differently each time?
> 
> I can't really say definitively, because I'm not familiar with this method - so I'm just basing my opinion on the circumstantial evidence that there are 9 regression tests that are sensitive to this ordering, and also my overall general feeling that needless non-determinism is always a bad thing in computer software because it makes everything harder to debug.
> 
> The downside of this patch is a slower implementation of `TypeSymbol.precedes()` - again, I'm not familiar with this method so unsure how critical it is. Also, note that this downside may happen in the future regardless if/when the `Name` classes get refactored to just be `String` wrappers, etc.
> 
> So... I dunno. Your thoughts?

I see, patch looks good, we will though have to be on watch for possible performance regressions, but we'll see

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12843#issuecomment-1485790300

From vromero at openjdk.org  Mon Mar 27 20:08:46 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 20:08:46 GMT
Subject: RFR: 8296656: java.lang.NoClassDefFoundError exception on running
 fully legitimate code [v7]
In-Reply-To: <ROtUlyyAchZ1xcrsoRnVus8zFMnONQLtEmPkSgD7MDs=.e15eecc6-125e-46ec-b09b-3223f8758539@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
 <ROtUlyyAchZ1xcrsoRnVus8zFMnONQLtEmPkSgD7MDs=.e15eecc6-125e-46ec-b09b-3223f8758539@github.com>
Message-ID: <wNfHvVrchL5Fn18sdWfSs9lZKh_LZ390B1dOBvgObmc=.223b3780-eb7d-4694-9fd0-1637cfa6ca2b@github.com>

On Sat, 25 Mar 2023 22:08:23 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
>> 
>> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
>> 
>> public class Test {
>>     interface Cafe\u0301 {
>>     }
>>     interface Caf\u00e9 {
>>     }
>> }
>> 
>> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
>> 
>> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
>> 
>> $ javac --help-extra
>>   ...
>>   --detect-output-file-clashes
>>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>>   ...
>> $ javac --detect-output-file-clashes Test.java
>> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>>     interface Caf\u00e9 {
>>     ^
>> 1 error
>> 
>> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
>> 
>> **Outstanding Questions**
>> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
>> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add "compiler.warn.output.file.clash" to message example exclusion file.

tier1-4 green

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12754#issuecomment-1485792340

From duke at openjdk.org  Mon Mar 27 21:36:53 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Mon, 27 Mar 2023 21:36:53 GMT
Subject: Integrated: 8296656: java.lang.NoClassDefFoundError exception on
 running fully legitimate code
In-Reply-To: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
References: <9DCycSXJOKlAam2chILPxfPjk2I_I2OfB4Y7v9eQfVM=.8052a24d-454d-42b1-ab71-3bb086b78d14@github.com>
Message-ID: <DgIfYyz4N4VK5dWcxL3wJlx3xPwfZ_VXakWspOb0T1A=.2e2055e4-64a0-44e4-85c7-2bdbe73f46ab@github.com>

On Sat, 25 Feb 2023 21:22:57 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This bug and a few others fall into the "output file clash" bucket. This is when the compiler thinks it's writing out two separate files, but due to the way the O/S filesystem maps `Path`'s to actual files, it's really writing the same file twice.
> 
> This is usually due to case-insensitive filesystems, but can also be due to how a filesystem "normalizes" file names. For example, on MacOS, compiling this class will generate such a clash:
> 
> public class Test {
>     interface Cafe\u0301 {
>     }
>     interface Caf\u00e9 {
>     }
> }
> 
> The reason is that `\u0301` is the Unicode character "Combining Acute Accent" which means "stick an accent over the previous character". So MacOS normalizes a `e` followed by a `\u0301` into a Unicode `\u00e9`, that is, `?`. However, the Java language treats these the two names `Cafe\u0301` and `Caf\u00e9` as distinct.
> 
> It's infeasible to truly "fix" this problem, so we resort here to a salve, which is to add a new compiler flag `--detect-output-file-clashes` that enables detection of output file clashes. When the flag is enabled, and a clash is detected, an error is immediately thrown. For example, compiling the example above gives this:
> 
> $ javac --help-extra
>   ...
>   --detect-output-file-clashes
>         Generate an error if any output file is overwritten during compilation. This can occur, for example,
>         on case-insensitive filesystems. This applies to class files, native header files, and source files.
>   ...
> $ javac --detect-output-file-clashes Test.java
> Test.java:4: error: error while writing Caf?: output file clash: /Users/archie/test/Test$Caf?.class
>     interface Caf\u00e9 {
>     ^
> 1 error
> 
> This at least gives people at risk of encountering this problem a way to turn a runtime error into a compile-time error.
> 
> **Outstanding Questions**
> * Is making this optional via an (extended) flag `--detect-output-file-clashes` the best way to address this?
> * Does the new field `BaseFileManager.outputFilesWritten` ever need to be cleared? Can the file manager be used for multiple compilations? If so, is there some "reset" step we should hook into?

This pull request has now been integrated.

Changeset: 14b970dc
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/14b970dc9e8d0fe1173039c01cced8a9422ec1ae
Stats:     231 lines in 10 files changed: 228 ins; 0 del; 3 mod

8296656: java.lang.NoClassDefFoundError exception on running fully legitimate code
8287885: Local classes cause ClassLoader error if the type names are similar but not same

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12754

From jjg at openjdk.org  Tue Mar 28 02:34:25 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 Mar 2023 02:34:25 GMT
Subject: RFR: JDK-8305004: add @spec tags to langtools modules
Message-ID: <R7PAAmLl8GuSv1QHLF9BE_lsZ-v3pp2wKBhMNr6U3Tk=.f8493cf0-0394-4b79-866f-e82f1e8a03e1@github.com>

Please review a simple doc-only PR to add `@spec` tags to 3 "langtools" modules, for eventual use in an "External Specifications" page.

-------------

Commit messages:
 - JDK-8305004: add @spec tags to langtools modules

Changes: https://git.openjdk.org/jdk/pull/13201/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13201&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305004
  Stats: 11 lines in 6 files changed: 5 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13201.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13201/head:pull/13201

PR: https://git.openjdk.org/jdk/pull/13201

From iris at openjdk.org  Tue Mar 28 02:59:28 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 28 Mar 2023 02:59:28 GMT
Subject: RFR: JDK-8305004: add @spec tags to langtools modules
In-Reply-To: <R7PAAmLl8GuSv1QHLF9BE_lsZ-v3pp2wKBhMNr6U3Tk=.f8493cf0-0394-4b79-866f-e82f1e8a03e1@github.com>
References: <R7PAAmLl8GuSv1QHLF9BE_lsZ-v3pp2wKBhMNr6U3Tk=.f8493cf0-0394-4b79-866f-e82f1e8a03e1@github.com>
Message-ID: <oDFeMlxEJsn6znxV8HjImqPJVml-0Yhy3Oemue8SAnQ=.5030aa1e-db45-4980-aaa3-d663077c6cec@github.com>

On Tue, 28 Mar 2023 02:26:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple doc-only PR to add `@spec` tags to 3 "langtools" modules, for eventual use in an "External Specifications" page.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13201#pullrequestreview-1360128468

From duke at openjdk.org  Tue Mar 28 03:42:39 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Mar 2023 03:42:39 GMT
Subject: Integrated: 8303526: Changing "arbitrary" Name.compareTo() ordering
 breaks the regression suite
In-Reply-To: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
References: <w3Fma8zIamCXHxE0C4_Mtqw8AGjB8CIJcLzuFbOQZeE=.9af50747-8851-4fbd-9d7d-75d6384a1c9f@github.com>
Message-ID: <DSlqzYWirpExTMy6ilFO1rTMGN-qqzWkj1ULLRyGo94=.68edf454-6219-4b18-898c-8f002eca985a@github.com>

On Thu, 2 Mar 2023 23:29:42 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This was discovered during investigation for [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622).
> 
> The method `Name.compareTo()` looks like this:
> 
> /** An arbitrary but consistent complete order among all Names.
>  */
> public int compareTo(Name other) {
>     return other.getIndex() - this.getIndex();
> }
> 
> Note the "arbitrary but consistent" wording. Unfortunately, the ordering can be "arbitrary" only if you don't mind breaking the regression suite.
> 
> For example, if you apply this patch:
> 
> --- a/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> +++ b/src/jdk.compiler/share/classes/com/sun/tools/javac/util/Name.java
> @@ -105,7 +105,7 @@ public abstract class Name implements javax.lang.model.element.Name, PoolConstan
>      /** An arbitrary but consistent complete order among all Names.
>       */
>      public int compareTo(Name other) {
> -        return other.getIndex() - this.getIndex();
> +        return this.getIndex() - other.getIndex();
>      }
> 
>      /** Return true if this is the empty name.
> 
> then the following tests will fail:
> ```TEST: tools/javac/8203436/T8203436b.java
> TEST: tools/javac/generics/7034019/T7034019c.java
> TEST: tools/javac/generics/7034019/T7034019d.java
> TEST: tools/javac/generics/diamond/neg/Neg21.java
> TEST: tools/javac/generics/diamond/neg/Neg22.java
> TEST: tools/javac/generics/inference/EagerReturnTypeResolution/EagerReturnTypeResolutionTestb.java
> TEST: tools/javac/patterns/InferenceUnitTest.java
> TEST: tools/javac/T8187978/FilterOutCandidatesForDiagnosticsTest.java
> TEST: tools/javac/varargs/6806876/T6806876.java
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>>> jtreg:test/langtools:langtools_javac               3718  3709     9     0 <<
> ==============================
> 
> The compiler behavior should be deterministic whenever possible, and the javac regression suite should be robust. So clearly "arbitrary" behavior by this method is not really supported.
> 
> It turns out there is only one user of `Name.compareTo()`, the method `TypeSymbol.precedes()`:
> 
> /**
>  * A partial ordering between type symbols that refines the
>  * class inheritance graph.
>  *
>  * Type variables always precede other kinds of symbols.
>  */
> public final boolean precedes(TypeSymbol that, Types types) {
>     if (this == that)
>         return false;
>     if (type.hasTag(that.type.getTag())) {
>         if (type.hasTag(CLASS)) {
>             return
>                 types.rank(that.type) < types.rank(this.type) ||
>                 types.rank(that.type) == types.rank(this.type) &&
>                 that.getQualifiedName().compareTo(this.getQualifiedName()) < 0;
>         } else if (type.hasTag(TYPEVAR)) {
>             return types.isSubtype(this.type, that.type);
>         }
>     }
>     return type.hasTag(TYPEVAR);
> }
> 
> If we want the above partial ordering to be stable, we need to specify deterministic behavior for `Name.compareTo()`.
> 
> An obvious choice would be to require that `Name.compareTo()` orders consistently with `String.compareTo()`, i.e., lexicographically on the Unicode characters in the name.
> 
> Fortunately, this comparison can be done efficiently, i.e., without actually converting the `Name` into a `String`, because UTF-8 is "lexicographically consistent" with the characters it encodes, except that Java's use of Modified UTF-8 means a special check for 0x0000 (which is encoded as two bytes) is required.
> 
> When you do this the tests are still broken... but notice that `TypeSymbol.precedes()` is actually using the _reverse_ of `Name.compareTo()`. So somehow, the current `Name.compareTo()` is ordering things "backwards", at least from the point of view of the expectation of the regression tests.
> 
> So replacing `Name.compareTo()` with a version that orders lexicographically, and also un-reversing its treatment in `TypeSymbol.precedes()`, makes things the tests succeed again.
> 
> That's what this patch does.

This pull request has now been integrated.

Changeset: 426025aa
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/426025aab42d485541a899844b96c06570088771
Stats:     36 lines in 2 files changed: 31 ins; 0 del; 5 mod

8303526: Changing "arbitrary" Name.compareTo() ordering breaks the regression suite

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12843

From arnoldnunag12 at gmail.com  Tue Mar 28 08:20:52 2023
From: arnoldnunag12 at gmail.com (Arnold Alejo Nunag)
Date: Tue, 28 Mar 2023 16:20:52 +0800
Subject: Additional info for report form bug 9075022: local (sub)classes
 and lambdas
In-Reply-To: <9891a540-cba8-383a-af24-a9ac60699ce5@gmail.com>
References: <9891a540-cba8-383a-af24-a9ac60699ce5@gmail.com>
Message-ID: <77fbce70-9f0f-2621-00b5-24bbd02b517b@gmail.com>

Hello,

The bug report I submitted earlier was assigned a JDK bug number: 
JDK-8305007 (https://bugs.openjdk.org/browse/JDK-8305007).

Additionally, a bit of debugging and testing by my friend shows a 
possible solution: with regards to the commit I mentioned in my previous 
email 
(https://github.com/openjdk/jdk12/commit/1ed6b88a9965efb2992f158bdb96b86d38cb9a45), 
modifying the code such that it checks the `proxies` map first and then 
falls back to the `lambdaTranslationMap` if the proxies map doesn't 
yield a value and the lambdaTranslationMap is available.

It isn't certain if it's a full fix for the issue, but it does fix the 
bug and the test case in the commit still successfully passes. Hope this 
can be of use.

Regards,
Arnold (@sciwhiz12)


From jlahoda at openjdk.org  Tue Mar 28 09:30:39 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 Mar 2023 09:30:39 GMT
Subject: RFR: 8304883: Record Deconstruction causes bytecode error [v2]
In-Reply-To: <UJXrdZhKChHxDVCLJQ4ym1RaA_8v2D3Pmpxo9uGv-R4=.fdb1473e-62cf-4f99-8aed-16b2abc7bed1@github.com>
References: <UJXrdZhKChHxDVCLJQ4ym1RaA_8v2D3Pmpxo9uGv-R4=.fdb1473e-62cf-4f99-8aed-16b2abc7bed1@github.com>
Message-ID: <WAtb3NB1NfxBa2HbAFZPJGM_CQCgvjJYAhjQfmbFZHg=.c0488c72-2c3b-48f1-ab8c-5f130c328844@github.com>

> Originally, we used to support cases like:
> `case null, String s when s.isEmpty() -> <expression>`
> where `s` could be `null` inside the expression, but the guard was only evaluated when `s != null`. This was implemented by augmenting the guard with `s == null || <original-guard>`.
> 
> This feature has been dropped since then.
> 
> Also note that in other cases, like:
> 
> record R(Object o) {}
> Object o = new R(null);
> switch (o) {
>     case R(var v) when v.toString().isEmpty() -> {}
> }
> 
> 
> We always expected a NPE on dereferencing the binding with value `null` (`v` in this case) in guard.
> 
> But, the code to implement the `case null, <binding>` remained in javac, and is causing problems, because, while the user cannot write `case null, <binding>` anymore, internally the desugaring sometimes generates that (when factoring out common prefixes). And the original code will still augment the guards to `<binding> == null || <guard>`, which causes the variables that are assigned in the guard to not being definitely assigned after the augmented guard.
> 
> The proposal is to simply remove the code that adds `<binding> == null || <guard>`, as there's no case where we would skip guards for `null` bindings anymore.

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:

 - Merge branch 'master' into JDK-8304883
 - 8304883: Record Deconstruction causes bytecode error

-------------

Changes: https://git.openjdk.org/jdk/pull/13192/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13192&range=01
  Stats: 67 lines in 2 files changed: 45 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13192/head:pull/13192

PR: https://git.openjdk.org/jdk/pull/13192

From duke at openjdk.org  Tue Mar 28 13:39:25 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Mar 2023 13:39:25 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v7]
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <6LtAowhUvwmA5S-XuydPlze_uJ0uW7KxtGY-dRClP8k=.405ffcca-37f7-4680-ae09-7c4f3215c395@github.com>

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Use an enum to represent UTF-8 decoding validation levels.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12893/files
  - new: https://git.openjdk.org/jdk/pull/12893/files/41642d66..382d0e44

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12893&range=05-06

  Stats: 116 lines in 9 files changed: 56 ins; 18 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/12893.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12893/head:pull/12893

PR: https://git.openjdk.org/jdk/pull/12893

From duke at openjdk.org  Tue Mar 28 13:39:31 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Mar 2023 13:39:31 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v6]
In-Reply-To: <fMb2MK9-9ib2xXehH532WDWqIJ1HB9IU8EsaamO4DkI=.c17922e6-3ee5-42c6-bcad-077cb0b007db@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <bmD_nc4qWvAnyQDS3TEBtvZieea8FWKA9Tgumv7huTI=.0f40adbd-1903-4cf4-beb4-a94b4091daf9@github.com>
 <fMb2MK9-9ib2xXehH532WDWqIJ1HB9IU8EsaamO4DkI=.c17922e6-3ee5-42c6-bcad-077cb0b007db@github.com>
Message-ID: <8hvztU5CCjvBwrA05kgpr0Sn5gVQldLvCD-XUDHCkXY=.fd0b9b00-0342-4f7e-84aa-01aaf0cd61d8@github.com>

On Mon, 27 Mar 2023 19:43:30 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Control behavior via a Feature instead of via direct Source comparison.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/Convert.java line 71:
> 
>> 69:      * Do strict validation of UTF-8. At this level, each character has only one valid encoding.
>> 70:      */
>> 71:     public static final int UTF8_STRICT = 2;
> 
> this three constants could be converted into an enum

Good idea, thanks. Fixed in 382d0e44c25.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12893#discussion_r1150624076

From jjg at openjdk.org  Tue Mar 28 14:56:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 Mar 2023 14:56:20 GMT
Subject: Integrated: JDK-8305004: add @spec tags to langtools modules
In-Reply-To: <R7PAAmLl8GuSv1QHLF9BE_lsZ-v3pp2wKBhMNr6U3Tk=.f8493cf0-0394-4b79-866f-e82f1e8a03e1@github.com>
References: <R7PAAmLl8GuSv1QHLF9BE_lsZ-v3pp2wKBhMNr6U3Tk=.f8493cf0-0394-4b79-866f-e82f1e8a03e1@github.com>
Message-ID: <s_diwrZvQolZDdt2xzsKsYd_lA0pqyJr1QswqwbqyqY=.386d0b67-5fed-488f-9581-eee3c1a9a91e@github.com>

On Tue, 28 Mar 2023 02:26:49 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a simple doc-only PR to add `@spec` tags to 3 "langtools" modules, for eventual use in an "External Specifications" page.

This pull request has now been integrated.

Changeset: 83ce65e1
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/83ce65e12ccb9e98990a4de3aa31ca308695c7a7
Stats:     11 lines in 6 files changed: 5 ins; 4 del; 2 mod

8305004: add @spec tags to langtools modules

Reviewed-by: iris

-------------

PR: https://git.openjdk.org/jdk/pull/13201

From jlaskey at openjdk.org  Tue Mar 28 15:14:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 15:14:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v50]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <WrElbf-3B1iF4yBMQt2_QmSQ5IBKu1lp9-E2nSZba0s=.69bd2cf1-435b-4bef-ba76-19cac9b5ac5b@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update StringTemplate.combine javadoc

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/58eeb319..c9696c2b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=49
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=48-49

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From vromero at openjdk.org  Tue Mar 28 15:45:26 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 28 Mar 2023 15:45:26 GMT
Subject: RFR: 8303623: Compiler should disallow non-standard UTF-8 string
 encodings [v7]
In-Reply-To: <6LtAowhUvwmA5S-XuydPlze_uJ0uW7KxtGY-dRClP8k=.405ffcca-37f7-4680-ae09-7c4f3215c395@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
 <6LtAowhUvwmA5S-XuydPlze_uJ0uW7KxtGY-dRClP8k=.405ffcca-37f7-4680-ae09-7c4f3215c395@github.com>
Message-ID: <2_9XP5shQGvHljNGAbx8fIDUgUrw4o_9W77msO6_iNw=.2c8be561-4be7-48f5-b219-cf7feb1499a2@github.com>

On Tue, 28 Mar 2023 13:39:25 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> This patch is a precursor to upcoming refactoring to address these related bugs:
>> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
>> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
>> 
>> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
>> 
>> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
>> 
>> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
>> 
>> $ java Test
>> Error: LinkageError occurred while loading main class Test
>> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
>> 
>> So the compiler should also reject any invalid classfiles containing them.
>> 
>> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.
>
> Archie L. Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use an enum to represent UTF-8 decoding validation levels.

looks good to me

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12893#pullrequestreview-1361411251

From duke at openjdk.org  Tue Mar 28 16:17:35 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Tue, 28 Mar 2023 16:17:35 GMT
Subject: Integrated: 8303623: Compiler should disallow non-standard UTF-8
 string encodings
In-Reply-To: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
References: <B9WhGNLGFuSdnYSAElHStFr51zB_IT0TreeWXUDXNsc=.abe9c1b4-6892-4700-9cb6-49098e69cad5@github.com>
Message-ID: <KY0w2T24RgSSPpsHLZR_pFozEQbttB0BBwk-na9b344=.f35715fa-158d-43e1-893f-f12adfef8aa3@github.com>

On Mon, 6 Mar 2023 22:59:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> This patch is a precursor to upcoming refactoring to address these related bugs:
> * [JDK-8269957](https://bugs.openjdk.org/browse/JDK-8269957) - facilitate alternate impls of NameTable and Name
> * [JDK-8268622](https://bugs.openjdk.org/browse/JDK-8268622) - Performance issues in javac `Name` class
> 
> In any multi-byte UTF-8 sequence, the bytes after the first byte are supposed to all look like `10xxxxxx`. But the code in `Convert.utf2chars()` is not checking that, so e.g., you could have `11xxxxxx` instead and it would encode the same character even though the UTF-8 bytes are different. For example, the character "?" normally encodes as `c3 a8`, but `Convert.utf2chars()` would also accept `c3 e8` or `c3 28` for "?". Another way to have non-standard encodings is by using more bytes than necessary. For example, you could encode the character `0x0100` as three bytes `e0 84 80`, but it should really be encoded as two bytes `c4 80`.
> 
> This leniency poses a problem because the current `Name.Table` implementations store UTF-8 byte sequences, not characters. So the same `Name` could be encoded two different ways, which would cause it to be added to the hash table twice. This violates the guarantee of uniqueness provided by `Name.Table` and could even potentially create a security concern (depending on how the compiler is being used).
> 
> But regardless of that, JVMS ?4.4.7 describes "Modified UTF-8" for encoded strings, and it does not allow for non-standard encodings. Instead, you'll get something like this:
> 
> $ java Test
> Error: LinkageError occurred while loading main class Test
> 	java.lang.ClassFormatError: Illegal UTF8 string in constant pool in class file Test
> 
> So the compiler should also reject any invalid classfiles containing them.
> 
> This patch makes `Convert.utf2chars()` throw a new checked exception `InvalidUtfException` and refactors accordingly, and adds a few minor cleanups along the way.

This pull request has now been integrated.

Changeset: c1f5ca11
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c1f5ca115d514327f4c3681e61663e22b686f8c7
Stats:     688 lines in 18 files changed: 567 ins; 25 del; 96 mod

8303623: Compiler should disallow non-standard UTF-8 string encodings

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/12893

From jlaskey at openjdk.org  Tue Mar 28 16:37:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 16:37:44 GMT
Subject: RFR: JDK-8303912 - Clean up JavadocTokenizer [v4]
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <jAVRDntplqNhkRNQmV23GiqN4ywlrHgQ1ye8nSEcXds=.ca1638ad-3ab3-41d5-a8e4-2c1f2b1d2e0f@github.com>

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - this-escape suppression
 - Merge branch 'master' into 8303912
 - Recommended changes
 - Corrections from review
 - Merge branch 'master' into 8303912
 - Clean up JavadocTokenizer

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/12953/files
  - new: https://git.openjdk.org/jdk/pull/12953/files/6e3be1eb..82f97e13

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=12953&range=02-03

  Stats: 23179 lines in 744 files changed: 11220 ins; 8251 del; 3708 mod
  Patch: https://git.openjdk.org/jdk/pull/12953.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12953/head:pull/12953

PR: https://git.openjdk.org/jdk/pull/12953

From jlaskey at openjdk.org  Tue Mar 28 16:40:03 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 16:40:03 GMT
Subject: Integrated: JDK-8303912 - Clean up JavadocTokenizer
In-Reply-To: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
References: <QVGRnh0rnwNyk589Aa8iar8KJ60azv5f3FwCJbW9wSU=.a05a024a-2861-445e-8f00-10cebcde0f5d@github.com>
Message-ID: <06HBKkSangIeWzB6VIfBL3an99IeT3IqIoDeHdUc5GM=.f2870350-305d-4d7c-92f0-1866e068035f@github.com>

On Thu, 9 Mar 2023 17:44:43 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

This pull request has now been integrated.

Changeset: 1fc218c5
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1fc218c58b58887c3b217603ed222ba0b561a9f1
Stats:     382 lines in 4 files changed: 133 ins; 156 del; 93 mod

8303912: Clean up JavadocTokenizer

Reviewed-by: vromero, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/12953

From jlaskey at openjdk.org  Tue Mar 28 17:52:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 17:52:37 GMT
Subject: Integrated: JDK-8305098 [Backout] JDK-8303912 Clean up
 JavadocTokenizer
Message-ID: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>

This reverts commit 1fc218c58b58887c3b217603ed222ba0b561a9f1.

-------------

Commit messages:
 - Revert "8303912: Clean up JavadocTokenizer"

Changes: https://git.openjdk.org/jdk/pull/13212/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13212&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305098
  Stats: 389 lines in 4 files changed: 163 ins; 140 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/13212.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13212/head:pull/13212

PR: https://git.openjdk.org/jdk/pull/13212

From jjg at openjdk.org  Tue Mar 28 17:52:38 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 28 Mar 2023 17:52:38 GMT
Subject: Integrated: JDK-8305098 [Backout] JDK-8303912 Clean up
 JavadocTokenizer
In-Reply-To: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
References: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
Message-ID: <jiF3MmWT00kb65URCs64o4Q96zYV8PvAWRM9vlHuNCI=.b0d2547a-ba88-484f-80d6-c0d579c1c069@github.com>

On Tue, 28 Mar 2023 17:43:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> This reverts commit 1fc218c58b58887c3b217603ed222ba0b561a9f1.

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/13212#pullrequestreview-1361625960

From mcimadamore at openjdk.org  Tue Mar 28 17:52:39 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 28 Mar 2023 17:52:39 GMT
Subject: Integrated: JDK-8305098 [Backout] JDK-8303912 Clean up
 JavadocTokenizer
In-Reply-To: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
References: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
Message-ID: <4gHToFMSoV0W_fl6vxLPJ68x3nP7ktJnnnUPG0-uK8Q=.dea08339-c516-4057-b67c-98c35e1138ed@github.com>

On Tue, 28 Mar 2023 17:43:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> This reverts commit 1fc218c58b58887c3b217603ed222ba0b561a9f1.

LGTM

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13212#pullrequestreview-1361628764

From jlaskey at openjdk.org  Tue Mar 28 17:52:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 17:52:41 GMT
Subject: Integrated: JDK-8305098 [Backout] JDK-8303912 Clean up
 JavadocTokenizer
In-Reply-To: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
References: <-4Kv1oNP1uE881-GOK0qTcRsCuryMyCh021ytx5jiic=.2f232a82-02cb-448c-8dbf-17d0adb36129@github.com>
Message-ID: <swxHq0VANyhu_3sXB_sFN8hdx4OdewOY08YJf-6K2lM=.7a39da5e-4dee-40a0-ac02-b88d9a8d18bf@github.com>

On Tue, 28 Mar 2023 17:43:47 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> This reverts commit 1fc218c58b58887c3b217603ed222ba0b561a9f1.

This pull request has now been integrated.

Changeset: 1683a63a
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1683a63a7df6eb3bd71cd9d0a7ab7081b92107c4
Stats:     389 lines in 4 files changed: 163 ins; 140 del; 86 mod

8305098: [Backout] JDK-8303912 Clean up JavadocTokenizer

Reviewed-by: jjg, mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/13212

From jlaskey at openjdk.org  Wed Mar 29 14:57:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 14:57:06 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v51]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <LVcp5vWdUuUSkMzbbbOdDjYLooIKU_5IpS1jTnwauLA=.59afa583-063e-4194-98f6-d2e06e2004c3@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 69 commits:

 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - Review recommended changes
 - Tidy javadoc
 - Rename StringTemplate classes
 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - ... and 59 more: https://git.openjdk.org/jdk/compare/50a995f0...3e1cc74a

-------------

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50
  Stats: 9255 lines in 75 files changed: 9156 ins; 24 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From jlaskey at openjdk.org  Wed Mar 29 15:46:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 15:46:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v52]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <TC3w3VrcgeJyYDiYGehji419QgXo0wmkd6sqPZ0k-L0=.29b2c5e8-48d3-432d-980a-1e6062a11ed2@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update combine example

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/3e1cc74a..67ffbccc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=51
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50-51

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

PR: https://git.openjdk.org/jdk/pull/10889

From vromero at openjdk.org  Wed Mar 29 19:40:35 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 29 Mar 2023 19:40:35 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
Message-ID: <ODagSXHk9JJa9VkJPNI-VherYni9Lom0405dXC2GXl4=.665c7462-0e4f-4f0a-aa99-446b47466adc@github.com>

On Tue, 21 Mar 2023 23:06:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
>> 
>> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
>> 
>> This change also makes a couple of other changes:
>> 
>> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
>> 
>> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
>> 
>> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8277501
>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12755#pullrequestreview-1363820926

From jjg at openjdk.org  Wed Mar 29 21:53:22 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 29 Mar 2023 21:53:22 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
Message-ID: <Yl99gJBJMYd2DqKFYEfPfH_wiPaqMhnonG2ojFSQ3tw=.fe94ea51-7ff6-44aa-8ccd-738f34e8e1e8@github.com>

On Tue, 21 Mar 2023 23:06:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
>> 
>> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
>> 
>> This change also makes a couple of other changes:
>> 
>> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
>> 
>> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
>> 
>> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8277501
>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

Is it worth renaming the internal `ByteBuffer` class to avoid the name clash?

Just asking.

The counter-argument is that we already deal with `javac.util.List` and `java.util.List`

src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 62:

> 60:     }
> 61: 
> 62:     /** Create a new byte buffer using the given array for storage.

Generally, the style for doc comments is either a single line, or for a newline after the initial `/**`

-------------

PR Review: https://git.openjdk.org/jdk/pull/12755#pullrequestreview-1363956884
PR Review Comment: https://git.openjdk.org/jdk/pull/12755#discussion_r1152482126

From duke at openjdk.org  Wed Mar 29 23:04:36 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 29 Mar 2023 23:04:36 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <Yl99gJBJMYd2DqKFYEfPfH_wiPaqMhnonG2ojFSQ3tw=.fe94ea51-7ff6-44aa-8ccd-738f34e8e1e8@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
 <Yl99gJBJMYd2DqKFYEfPfH_wiPaqMhnonG2ojFSQ3tw=.fe94ea51-7ff6-44aa-8ccd-738f34e8e1e8@github.com>
Message-ID: <jt9-y7eyZGNW14ADgYqopo2plOODgPySkC0dnDwS9kw=.aad73a39-88c2-4586-9e9b-5e93e6dd9aa1@github.com>

On Wed, 29 Mar 2023 21:02:36 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'master' into JDK-8277501
>>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 62:
> 
>> 60:     }
>> 61: 
>> 62:     /** Create a new byte buffer using the given array for storage.
> 
> Generally, the style for doc comments is either a single line, or for a newline after the initial `/**`

Yeah... except not in this file. I was erring on the side of being consistent with the rest of the file (lesser of two evils?)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12755#discussion_r1152570789

From simeon.danailov.andreev at gmail.com  Thu Mar 30 08:39:26 2023
From: simeon.danailov.andreev at gmail.com (S A)
Date: Thu, 30 Mar 2023 11:39:26 +0300
Subject: Compile error in multi type catch block with Java 11, runtime error
 with Java 17
Message-ID: <CACcnpz18Ytm+KVkdTYFSXx_3frJXMS2XdD7pF4A4=kR4Y=8vnw@mail.gmail.com>

Hi all,

Could someone clarify the following difference in javac behavior between
Java 11 and Java 17? Which one is correct?

There are two source files:

package p;
public class Exceptions {
    private static class E extends Exception {
        public void m() { }
    }
    public static class E1 extends E {}
    public static class E2 extends E {}
}

package q;
import p.Exceptions;
import p.Exceptions.*;
public class Test {
    public static void main(String[] args) {
        try {
            if (false) { throw new E2(); }
            throw new E1();
        } catch (E1 | E2 e) {
            e.m(); // javac 11: ...defined in an inaccessible class...
        }
    }
}

Compiling with Java 11 results in an error:

q/Test.java:12: error: E.m() is defined in an inaccessible class or
interface
            e.m(); // javac 11: ...defined in an inaccessible class...
             ^
1 error

Compiling with Java 17 doesn't result in an error, but running the code
results in a runtime exception:

Exception in thread "main" java.lang.IllegalAccessError: failed to access
class p.Exceptions$E from class q.Test (p.Exceptions$E and q.Test are in
unnamed module of loader 'app')
        at q.Test.main(Test.java:12)

The difference in behavior between Java 11 and Java 17 is probably
introduced with: https://bugs.openjdk.org/browse/JDK-8264696

The bug-fix was done for: https://youtrack.jetbrains.com/issue/IDEA-297529
A similar bug was opened for ecj:
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/198

It looks like John Vasileff has gone through the spec and asserts the Java
17 behavior is not expected, see comments:

https://github.com/eclipse-jdt/eclipse.jdt.core/issues/198#issuecomment-1177897759
https://youtrack.jetbrains.com/issue/IDEA-297529/Wrong-compilation-error-reported-when-multi-type-catch-block-references-visible-method-from-invisible-type#focus=Comments-27-6280209.0-0

> because, within the catch block, the type of `e` is `Exceptions.E` per
the LUB algorithm in "4.10.4. Least Upper Bound". And, per "6.6. Access
Control", `Exceptions.E` should not be accessible outside of `Exceptions`.
The members of `Exceptions.E` should be unavailable.
>
> In "6.6. Access Control":
>
> > Otherwise, the member or constructor is declared private. Access is
permitted only when the access occurs from within the body of the top level
class or interface that encloses the declaration of the member or
constructor.

I was redirected to compiler-dev from serviceability-dev. Meanwhile I've
also reported a bug via https://bugreport.java.com/bugreport/, but the
report is still being reviewed.

Best regards and thanks,
Simeon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/compiler-dev/attachments/20230330/6e00646f/attachment-0001.htm>

From kevinw at openjdk.org  Fri Mar 31 08:54:00 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 31 Mar 2023 08:54:00 GMT
Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction
Message-ID: <s2FPofsq_t2vaSm9YNgAb2K-nz40zm6EN8xVJcwxWo4=.fb908601-4ddb-4732-8c6b-0061aef5976b@github.com>

The Permissions in DCmds relate to remote usage over JMX. 
"monitor" is generally for reading information, and "control" is generally for making changes.
The DCmds for changing compiler directives should have "control" as the required permission.

Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change.

-------------

Commit messages:
 - 8305237: CompilerDirectives DCmds permissions correction

Changes: https://git.openjdk.org/jdk/pull/13262/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13262&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305237
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13262.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13262/head:pull/13262

PR: https://git.openjdk.org/jdk/pull/13262

From kevinw at openjdk.org  Fri Mar 31 08:54:02 2023
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 31 Mar 2023 08:54:02 GMT
Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction
In-Reply-To: <s2FPofsq_t2vaSm9YNgAb2K-nz40zm6EN8xVJcwxWo4=.fb908601-4ddb-4732-8c6b-0061aef5976b@github.com>
References: <s2FPofsq_t2vaSm9YNgAb2K-nz40zm6EN8xVJcwxWo4=.fb908601-4ddb-4732-8c6b-0061aef5976b@github.com>
Message-ID: <wWO3fyF9u2J7vP4oiW5kyRE2j0qshUXsUp0cwbCyAZM=.038fc05d-47c8-4aca-9feb-809b93cca211@github.com>

On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The Permissions in DCmds relate to remote usage over JMX. 
> "monitor" is generally for reading information, and "control" is generally for making changes.
> The DCmds for changing compiler directives should have "control" as the required permission.
> 
> Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change.

This has a lot of labels for a trivial change in a very niche feature, but they all seem relevant.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1491551796

From jlaskey at openjdk.org  Fri Mar 31 11:18:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 31 Mar 2023 11:18:19 GMT
Subject: RFR: JDK-8305100 [REDO] Clean up JavadocTokenizer
Message-ID: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>

Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.

Redo changes:

1. Needed to check for end of data after @deprecated
2. Position of newline in offset map was incorrect (out by one).
3. Skip whitespace after first line (put offsets out by one).

-------------

Commit messages:
 - Correct position for end of line
 - Tweaks to get tests running
 - Handle line terminators.
 - Clean up end of comment detection
 - Skip whitespace before @deprecated
 - Clean up JavadocTokenizer
 - Merge branch 'master' into 8305100
 - Clean up JavadocTokenizer

Changes: https://git.openjdk.org/jdk/pull/13265/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13265&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8305100
  Stats: 416 lines in 4 files changed: 167 ins; 159 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/13265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13265/head:pull/13265

PR: https://git.openjdk.org/jdk/pull/13265

From jlaskey at openjdk.org  Fri Mar 31 11:18:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 31 Mar 2023 11:18:19 GMT
Subject: RFR: JDK-8305100 [REDO] Clean up JavadocTokenizer
In-Reply-To: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
References: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
Message-ID: <Z7Ph77Z0V6X1LikiE4OgruOw8JL4eB2r1_3JqXOswuk=.55dd65a9-bce9-406f-a6be-3290109e8814@github.com>

On Fri, 31 Mar 2023 11:10:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
> 
> Redo changes:
> 
> 1. Needed to check for end of data after @deprecated
> 2. Position of newline in offset map was incorrect (out by one).
> 3. Skip whitespace after first line (put offsets out by one).

tier1,tier2,tier3 mach5 run https://mach5.us.oracle.com/mdash/jobs/jlaskey-open-20230330-1940-43993922

Original PR https://github.com/openjdk/jdk/pull/12953

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13265#issuecomment-1491758451
PR Comment: https://git.openjdk.org/jdk/pull/13265#issuecomment-1491759614

From vromero at openjdk.org  Fri Mar 31 15:28:41 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 31 Mar 2023 15:28:41 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
Message-ID: <mgIoPA3uppM6ttnRKns4UVIkO7ViMvWnf9nEb9cPBos=.7865aa49-07dd-480f-9421-54d976b9cee9@github.com>

On Tue, 21 Mar 2023 23:06:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
>> 
>> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
>> 
>> This change also makes a couple of other changes:
>> 
>> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
>> 
>> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
>> 
>> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8277501
>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

would like to close this one, any other comments?

tier1-4 green

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12755#issuecomment-1492123278
PR Comment: https://git.openjdk.org/jdk/pull/12755#issuecomment-1492125978

From cjplummer at openjdk.org  Fri Mar 31 19:44:13 2023
From: cjplummer at openjdk.org (Chris Plummer)
Date: Fri, 31 Mar 2023 19:44:13 GMT
Subject: RFR: 8305237: CompilerDirectives DCmds permissions correction
In-Reply-To: <s2FPofsq_t2vaSm9YNgAb2K-nz40zm6EN8xVJcwxWo4=.fb908601-4ddb-4732-8c6b-0061aef5976b@github.com>
References: <s2FPofsq_t2vaSm9YNgAb2K-nz40zm6EN8xVJcwxWo4=.fb908601-4ddb-4732-8c6b-0061aef5976b@github.com>
Message-ID: <Sy1zmkXEXOdNXRkj0QeMzUGNV3bs0r-C7HRp4rC4MVI=.2d0ccf49-b514-475d-8b65-6aa18a79de27@github.com>

On Fri, 31 Mar 2023 08:24:19 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> The Permissions in DCmds relate to remote usage over JMX. 
> "monitor" is generally for reading information, and "control" is generally for making changes.
> The DCmds for changing compiler directives should have "control" as the required permission.
> 
> Tests in test/hotspot/jtreg/serviceability/dcmd/compiler and test/hotspot/jtreg/compiler/compilercontrol still pass with this change.

I assume this means we have no tests that try to change these compiler directives. Should we?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/13262#issuecomment-1492504793

From jjg at openjdk.org  Fri Mar 31 20:28:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 20:28:17 GMT
Subject: RFR: JDK-8305100 [REDO] Clean up JavadocTokenizer
In-Reply-To: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
References: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
Message-ID: <PkmoMDeQDa5MEInljO3_wsB2C9jabxzO15tBeXf6_5I=.8f020f4e-e304-43d8-bd18-691ef5932b6d@github.com>

On Fri, 31 Mar 2023 11:10:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
> 
> Redo changes:
> 
> 1. Needed to check for end of data after @deprecated
> 2. Position of newline in offset map was incorrect (out by one).
> 3. Skip whitespace after first line (put offsets out by one).

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavaTokenizer.java line 1357:

> 1355:                                     line.get() == EOI)) {
> 1356:                         deprecatedFlag = true;
> 1357:                     }

As mentioned recently elsewhere, this is generally insufficient, albeit no worse than before.
Generally, we should move away from this code, and eliminate `deprecated Flag` entirely. Deprecation is (or should be) indicated by the `@Deprecated` annotation, with associated documentation given by a plain/regular `@deprecated` tag, as read by `DocCommentParser` or equivalent.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/13265#discussion_r1154867472

From jjg at openjdk.org  Fri Mar 31 20:58:17 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 20:58:17 GMT
Subject: RFR: JDK-8305100 [REDO] Clean up JavadocTokenizer
In-Reply-To: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
References: <6nYvwXotqcU7XlbQ4dhbX1o7WzMxH0OzP54pykRoKSc=.e6979e48-773e-4265-bcdd-665c68de306c@github.com>
Message-ID: <BZZ59oMOfUwmX28jJl_ndJOxg8UJ1yyhppdQMEg-Uj8=.15daff7a-0d20-4c74-9d02-0c9ab464ee91@github.com>

On Fri, 31 Mar 2023 11:10:42 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Previous work had cleaned up the JavacTokenizer, but left JavadocTokenizer alone, mostly due to its perplexing state. This is follow up work to simplify the JavadocTokenizer.
> 
> Redo changes:
> 
> 1. Needed to check for end of data after @deprecated
> 2. Position of newline in offset map was incorrect (out by one).
> 3. Skip whitespace after first line (put offsets out by one).

Looks good to me

-------------

Marked as reviewed by jjg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13265#pullrequestreview-1367587275

From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <UC_eXLH1ZYj0NDyQ-MSY5oRvejr6HAHIznL3Lh7rwOY=.4cb34fe7-3979-454d-8d49-b07b248a5cf7@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306

From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <G-JuA4B7q1ygFjywx4FOwGfJX2Ud-Jf4BwgrzPykvXg=.61ddf6ba-5a7d-45a2-87aa-4613ec3dfb3b@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703

From duke at openjdk.org  Fri Mar 31 23:00:55 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 31 Mar 2023 23:00:55 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <mgIoPA3uppM6ttnRKns4UVIkO7ViMvWnf9nEb9cPBos=.7865aa49-07dd-480f-9421-54d976b9cee9@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
 <mgIoPA3uppM6ttnRKns4UVIkO7ViMvWnf9nEb9cPBos=.7865aa49-07dd-480f-9421-54d976b9cee9@github.com>
Message-ID: <A4g7bEyxMkGjvH1nA8n8rYf8_FSzrNyV85cloMTVFpQ=.9750f341-a7cc-4d3a-9807-c34b97a2a57d@github.com>

On Fri, 31 Mar 2023 15:26:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'master' into JDK-8277501
>>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.
>
> tier1-4 green

Hi @vicente-romero-oracle ,

> would like to close this one, any other comments?

If you're asking me, I think renaming `ByteBuffer` is a reasonable idea but should go into a separate PR (guess I'm trying to avoid mission creep). So I'm ready to wrap this one up but am happy to entertain other opinions.

Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12755#issuecomment-1492697935

From jjg at openjdk.org  Fri Mar 31 23:12:37 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 23:12:37 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
Message-ID: <WSGSLP2uOtkzbArjZtHr2Xp0MoZap7QWbOJQqMfM9F0=.acf53f40-e8d4-42dc-bc8b-94460eaa1d03@github.com>

On Tue, 21 Mar 2023 23:06:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
>> 
>> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
>> 
>> This change also makes a couple of other changes:
>> 
>> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
>> 
>> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
>> 
>> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8277501
>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

Marked as reviewed by jjg (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/12755#pullrequestreview-1367732366

From jjg at openjdk.org  Fri Mar 31 23:12:38 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 23:12:38 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <mgIoPA3uppM6ttnRKns4UVIkO7ViMvWnf9nEb9cPBos=.7865aa49-07dd-480f-9421-54d976b9cee9@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
 <mgIoPA3uppM6ttnRKns4UVIkO7ViMvWnf9nEb9cPBos=.7865aa49-07dd-480f-9421-54d976b9cee9@github.com>
Message-ID: <jk6eAedKcMh6ufrbH5ZT4Re2qpL9992e3qT2INAD_2c=.1c59fb8d-e4b5-45d7-ba05-32ec28132f94@github.com>

On Fri, 31 Mar 2023 15:26:18 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
>> 
>>  - Merge branch 'master' into JDK-8277501
>>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.
>
> tier1-4 green

> Hi @vicente-romero-oracle ,
> 
> > would like to close this one, any other comments?
> 
> If you're asking me, I think renaming `ByteBuffer` is a reasonable idea but should go into a separate PR (guess I'm trying to avoid mission creep). So I'm ready to wrap this one up but am happy to entertain other opinions.
> 
> Thanks.

Avoiding creeping missions is a good idea.  One way to help with that can be to file JBS issues as a future reminder.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12755#issuecomment-1492709389

From jjg at openjdk.org  Fri Mar 31 23:12:40 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 31 Mar 2023 23:12:40 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <jt9-y7eyZGNW14ADgYqopo2plOODgPySkC0dnDwS9kw=.aad73a39-88c2-4586-9e9b-5e93e6dd9aa1@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
 <Yl99gJBJMYd2DqKFYEfPfH_wiPaqMhnonG2ojFSQ3tw=.fe94ea51-7ff6-44aa-8ccd-738f34e8e1e8@github.com>
 <jt9-y7eyZGNW14ADgYqopo2plOODgPySkC0dnDwS9kw=.aad73a39-88c2-4586-9e9b-5e93e6dd9aa1@github.com>
Message-ID: <KyQyShKFMq2Emr7neEgWR-jO9bFoQBHfzG5tvGbQ_V8=.dcf3d95d-b22f-4099-b13a-d8310f71cb5f@github.com>

On Wed, 29 Mar 2023 23:01:57 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/util/ByteBuffer.java line 62:
>> 
>>> 60:     }
>>> 61: 
>>> 62:     /** Create a new byte buffer using the given array for storage.
>> 
>> Generally, the style for doc comments is either a single line, or for a newline after the initial `/**`
>
> Yeah... except not in this file. I was erring on the side of being consistent with the rest of the file (lesser of two evils?)

OK, as long as you made a deliberate choice, that's cool.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/12755#discussion_r1154986383

From vromero at openjdk.org  Fri Mar 31 23:18:27 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Fri, 31 Mar 2023 23:18:27 GMT
Subject: RFR: 8277501: Revisit PathFileObject.getCharContent and friends
 [v2]
In-Reply-To: <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
 <eka9-dXBTa2vSDmKp2HfHkxhxqNt_n3SSMyPSuYrvTM=.93a11a4d-30a9-4401-b2ae-64bb17e8395e@github.com>
Message-ID: <YE1QVRJwbYzQ3z5CcH7H8JRoxdqcthzFLQ6opl_SHNg=.8e5f2c27-56cf-499f-9afb-cd53eef0f7e1@github.com>

On Tue, 21 Mar 2023 23:06:51 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
>> 
>> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
>> 
>> This change also makes a couple of other changes:
>> 
>> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
>> 
>> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
>> 
>> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.
>
> Archie L. Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Merge branch 'master' into JDK-8277501
>  - Avoid over-reliance on InputStream.available() in BaseFileManager.makeByteBuffer().
>  - Adjust the semantics of ByteBuffer.appendStream() to not close the stream.

good, closing this one, thanks guys!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/12755#issuecomment-1492713289

From duke at openjdk.org  Fri Mar 31 23:21:17 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Fri, 31 Mar 2023 23:21:17 GMT
Subject: Integrated: 8277501: Revisit PathFileObject.getCharContent and friends
In-Reply-To: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
References: <yQF4pP2-WRqbrhvTX8OWJsEiemcxfpxqma9R4U4eGbc=.7b0c42e1-95af-419d-8b1b-43e65b828446@github.com>
Message-ID: <XwOsb_ejNcYqEMsvq2stNV8NtPsShRJAlI359uinTpw=.e4cad5ad-b559-448a-9dd7-a52be33545e9@github.com>

On Sun, 26 Feb 2023 00:16:43 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

> The method `BaseFileManager.makeByteBuffer()` assumes that the result from`InputStream.available()` is always accurate, but this is not guaranteed.
> 
> This patch cleans up this logic by piggybacking on a similar cleanup that was recently done for [JDK-8302514](https://bugs.openjdk.org/browse/JDK-8302514).
> 
> This change also makes a couple of other changes:
> 
> (1) Adjust the sematics of `ByteBuffer.appendStream()` so that it doesn't also close the input, which is abnormal for a method like this.
> 
> (2) Add synchronization to the buffer caching in `BaseFileManager.makeByteBuffer()` because, according to the API documentation for `JavaFileManager`:
>> An object of this interface is not required to support multi-threaded access, that is, be synchronized. However, it must support concurrent access to different file objects created by this object. 
> 
> `BaseFileManager.makeByteBuffer()` is invoked from `PathFileObject` and so the per-file object thread-safety requirement would apply here.

This pull request has now been integrated.

Changeset: 8eb4e7e0
Author:    Archie L. Cobbs <archie.cobbs at gmail.com>
Committer: Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8eb4e7e07e9211aabcb0f22696e9c572dac7a59f
Stats:     93 lines in 3 files changed: 27 ins; 34 del; 32 mod

8277501: Revisit PathFileObject.getCharContent and friends

Reviewed-by: vromero, jjg

-------------

PR: https://git.openjdk.org/jdk/pull/12755