From jlahoda at openjdk.org  Mon Apr  3 14:30:56 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 3 Apr 2023 14:30:56 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v5]
In-Reply-To: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
Message-ID: <9ooVunXeZllWhssOC1szQne238CExHP7zIg5GXkIlJw=.90a5edce-0952-4219-9779-d92df3c5fc5f@github.com>

> Implements `System.console()` for JShell, based on JDK-8295803. It is only supported for (supported) remote agents.
> 
> When a snippet calls a Console method in the remote agent, a request to perform the task is sent to the main process, performed, and the outcomes are sent back to the remote agent, and returned from the Console method.
> 
> Please also review the CSR for the newly added API:
> https://bugs.openjdk.org/browse/JDK-8299680

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

  Fixing typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11695/files
  - new: https://git.openjdk.org/jdk/pull/11695/files/a5daeb51..05eccb18

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

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

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

From jjg at openjdk.org  Mon Apr  3 14:52:09 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 3 Apr 2023 14:52:09 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v2]
In-Reply-To: <A4LwKXqsKg0IAW-5SyAryndaR1bMiRk5_7sc7zyH0XE=.e369b8a2-2b43-462f-8d72-c45b37869c6d@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
 <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@github.com>
 <A4LwKXqsKg0IAW-5SyAryndaR1bMiRk5_7sc7zyH0XE=.e369b8a2-2b43-462f-8d72-c45b37869c6d@github.com>
Message-ID: <QJzXEbVZEr5tjQwuEwPoXSDTdr_tj0x5t6kLVrPN9cY=.4ed24b36-37f9-420c-b05f-bbaa3e74cde2@github.com>

On Tue, 21 Mar 2023 08:55:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> 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 12 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'origin/JDK-8296454b' into JDK-8296454b
>>  - Merge branch 'master' into JDK-8296454b
>>  - Speeding up writes to the Console's Writer by not waiting for the response.
>>  - Cleanup.
>>  - Cleanup.
>>  - Fixing test.
>>  - Adding support for Charset.
>>  - Test when there's no JShellConsole.
>>  - Buffering output.
>>  - Improving synchronizations and fixing sending of many requests from the agent into the main process.
>>  - ... and 2 more: https://git.openjdk.org/jdk/compare/65938908...d58e53f1
>
> src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java line 196:
> 
>> 194:          */
>> 195:         @Override
>> 196:         public JdkConsole format(String fmt, Object ...args) {
> 
> Suggestion:
> 
>         public JdkConsole format(String fmt, Object ... args) {

There is normally no space before the `...`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/11695#discussion_r1156071500

From jlaskey at openjdk.org  Tue Apr  4 15:16:19 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 15:16:19 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@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:

  RuntimeException is the only exception type that can is deduced from a lambda.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/67ffbccc..6274eb3f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=52
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=51-52

  Stats: 2 lines in 1 file changed: 0 ins; 1 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 forax at openjdk.org  Tue Apr  4 15:24:53 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 4 Apr 2023 15:24:53 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
Message-ID: <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>

On Tue, 4 Apr 2023 15:16:19 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:
> 
>   RuntimeException is the only exception type that can is deduced from a lambda.

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 70:

> 68:          * null.
> 69:          */
> 70:         int hashcode;

All the fields of the keys should be final, otherwise a publication problem can occur (the key is visible from another thread but its fields are not yet initialized)

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:

> 98:         try {
> 99:             return (List<Object>)valuesMH.invokeExact(this);
> 100:         } catch (Throwable ex) {

Errors likes OutOfMemoryError and runtime exception should be rethrown instead of being wrapped

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 109:

> 107:         try {
> 108:             return (String)interpolateMH.invokeExact(this);
> 109:         } catch (Throwable ex) {

see above

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157415311
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157417666
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157417849

From forax at openjdk.org  Tue Apr  4 15:35:01 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Tue, 4 Apr 2023 15:35:01 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
Message-ID: <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>

On Tue, 4 Apr 2023 15:16:19 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:
> 
>   RuntimeException is the only exception type that can is deduced from a lambda.

src/java.base/share/classes/java/lang/StringTemplate.java line 577:

> 575:          */
> 576:         static <R> Processor<R, RuntimeException> of(Function<StringTemplate, R> process) {
> 577:             return process::apply;

The wildcards are missing :)

static <R> Processor<R, RuntimeException> of(Function<? super StringTemplate, ? extends R> process) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157431904

From jlaskey at openjdk.org  Tue Apr  4 15:52:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 15:52:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
 <FI5_yLnJFsWtW5ZSRNsl-wluIt9cEPBJPFr1QLCYCwY=.dacd6d62-dfd9-4b9f-959a-89317e95a40c@github.com>
Message-ID: <74cTZBH2HGtXITYb_G_6sdTPvqTs4V45Pg_8rpJv5AA=.7b50958d-fe2a-463a-bb1f-3759e9f82d6a@github.com>

On Tue, 4 Apr 2023 15:18:43 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RuntimeException is the only exception type that can is deduced from a lambda.
>
> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 70:
> 
>> 68:          * null.
>> 69:          */
>> 70:         int hashcode;
> 
> All the fields of the keys should be final, otherwise a publication problem can occur (the key is visible from another thread but its fields are not yet initialized)

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157453484

From jlaskey at openjdk.org  Tue Apr  4 16:01:42 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 16:01:42 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v53]
In-Reply-To: <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <8IomKDUZEGYuWO0jwzX6b3C5oQH9aknVWeGtaRySXDs=.d229cb1f-3635-4992-838b-c521a8975062@github.com>
 <6F3EPwqwVYV2OJhfvYrSaz7M0QIswDq2c0Besicj20U=.b3c8d68b-f41b-4110-b37d-b362148eb599@github.com>
Message-ID: <S-vNyonwJvpSSTOTpocL3sf60FrE0FWqFOMwbUA0FZU=.d7f1c249-7b58-4c66-b03b-38324ecdd28a@github.com>

On Tue, 4 Apr 2023 15:31:12 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   RuntimeException is the only exception type that can is deduced from a lambda.
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 577:
> 
>> 575:          */
>> 576:         static <R> Processor<R, RuntimeException> of(Function<StringTemplate, R> process) {
>> 577:             return process::apply;
> 
> The wildcards are missing :)
> 
> static <R> Processor<R, RuntimeException> of(Function<? super StringTemplate, ? extends R> process) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:
> 
>> 98:         try {
>> 99:             return (List<Object>)valuesMH.invokeExact(this);
>> 100:         } catch (Throwable ex) {
> 
> Errors likes OutOfMemoryError and runtime exception should be rethrown instead of being wrapped

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 109:
> 
>> 107:         try {
>> 108:             return (String)interpolateMH.invokeExact(this);
>> 109:         } catch (Throwable ex) {
> 
> see above

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157464394
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157459830
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1157460255

From jlaskey at openjdk.org  Tue Apr  4 16:07:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 4 Apr 2023 16:07:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@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:

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6274eb3f..4c6d70d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=53
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=52-53

  Stats: 8 lines in 3 files changed: 4 ins; 0 del; 4 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 jlahoda at openjdk.org  Wed Apr  5 07:53:10 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Apr 2023 07:53:10 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v6]
In-Reply-To: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
Message-ID: <HQ-kQiR7ic8K16ZGWqUf--B-yZI3YyCGDkD9r_vZH9o=.d8213f81-66b4-4461-a82f-9f182fb262d6@github.com>

> Implements `System.console()` for JShell, based on JDK-8295803. It is only supported for (supported) remote agents.
> 
> When a snippet calls a Console method in the remote agent, a request to perform the task is sent to the main process, performed, and the outcomes are sent back to the remote agent, and returned from the Console method.
> 
> Please also review the CSR for the newly added API:
> https://bugs.openjdk.org/browse/JDK-8299680

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

  Removing spaces before '...'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11695/files
  - new: https://git.openjdk.org/jdk/pull/11695/files/05eccb18..6366c9be

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

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

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

From jlahoda at openjdk.org  Wed Apr  5 10:38:32 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 5 Apr 2023 10:38:32 GMT
Subject: Integrated: 8296454: System.console() shouldn't return null in jshell
In-Reply-To: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
Message-ID: <wz3JYnmZieeR7KfuUeYqlGlpvuGWKP1qY9hYgFl8Ia8=.8cc417a3-ca74-43fd-b7e2-7295e3f688cd@github.com>

On Thu, 15 Dec 2022 15:30:12 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> Implements `System.console()` for JShell, based on JDK-8295803. It is only supported for (supported) remote agents.
> 
> When a snippet calls a Console method in the remote agent, a request to perform the task is sent to the main process, performed, and the outcomes are sent back to the remote agent, and returned from the Console method.
> 
> Please also review the CSR for the newly added API:
> https://bugs.openjdk.org/browse/JDK-8299680

This pull request has now been integrated.

Changeset: 4bf19878
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bf1987856f454e029c413e53d4b0c5807d3e890
Stats:     1041 lines in 15 files changed: 991 ins; 0 del; 50 mod

8296454: System.console() shouldn't return null in jshell

Reviewed-by: vromero

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

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

From duke at openjdk.org  Fri Apr  7 10:01:30 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
Message-ID: <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>

On Tue, 4 Apr 2023 16:07:54 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:
> 
>   Recommended changes

These?should rethrow all?`Error`s:

src/java.base/share/classes/java/lang/StringConcatHelper.java line 364:

> 362:         try {
> 363:             return value.prepend(indexCoder, buf);
> 364:         } catch (Throwable ex) {

This?should rethrow?errors (such?as?`OutOfMemoryError`):
Suggestion:

        } catch (Error err) {
            throw err;
        } catch (Throwable ex) {

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:

> 98:         try {
> 99:             return (List<Object>)valuesMH.invokeExact(this);
> 100:         } catch (RuntimeException | OutOfMemoryError ex) {

Suggestion:

        } catch (RuntimeException | Error ex) {

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 111:

> 109:         try {
> 110:             return (String) interpolateMH.invokeExact(this);
> 111:         } catch (RuntimeException | OutOfMemoryError ex) {

Suggestion:

        } catch (RuntimeException | Error ex) {

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1376048871
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160580952
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160595676
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160595790

From duke at openjdk.org  Fri Apr  7 10:01:30 2023
From: duke at openjdk.org (ExE Boss)
Date: Fri, 7 Apr 2023 10:01:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <-AiZ8W_A-neX-_n9fv41Pjjo26E1MqzTjyXSRtr7yzI=.45602272-797f-4a58-8b7d-d527a6f7b631@github.com>
 <K-LthF3HG8j-XoUjck4xZ2RdT8ZdS_jlKb3bivA7wZI=.f8a91109-4bd3-46d7-a86c-9f720f4d20e1@github.com>
 <8wF7uVw_nKKSsFRkNTrca2cwW_Yyz2ZKCudyJQ-y4O8=.f7537649-9d90-4805-bf5a-1c6ac0c8e358@github.com>
 <jFftqftzDSSQqAYaG6f944PpB4L11OJWh0TkJjYk-nM=.692bccb6-304f-4173-8538-5644e36dff2f@github.com>
 <QTuXZCQBCHnfr-n7W3F7K3vEr88fCuQVsvRcikoTbOM=.020347ed-48ee-4beb-97e6-60ab0f5f4da9@github.com>
Message-ID: <NTKibLWXQzrCIBY8wvYUh_dNOj2OSUyqrkQYUd7Zk-A=.bc1d54f2-a304-4364-aba0-64228e90d64c@github.com>

On Tue, 1 Nov 2022 00:02:46 GMT, David Schlosnagle <duke at openjdk.org> wrote:

>> Anyway, i think you are right, this can be public
>
> If this is a public int field, it will be inlined to class file byte code at compile time, which may not be what you want if this value needs to change in the future. If this needs to be exposed, should it be as a public method?

It?can?also be?initialised in?a?static?initialiser, which?will make?it no?longer?inlined at?use?sites:
Suggestion:

    public static final int MAX_INDY_CONCAT_ARG_SLOTS;
    static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1160586124

From jlaskey at openjdk.org  Sat Apr  8 14:42:35 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 14:42:35 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v55]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <RV84nzy4c88wTwf2PhV2A4uYS0HMiK1_jwYo-YvZMMA=.4dd46868-c5b8-4a02-ac45-80151c4381f1@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 Error handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/4c6d70d1..62eadb84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=54
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=53-54

  Stats: 5 lines in 2 files changed: 2 ins; 0 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  Sat Apr  8 14:42:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 14:42:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v54]
In-Reply-To: <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <BSADnCP_cZkZnwJDnznJ3T8PbB0IF6_xF_wuEJv7Pc0=.b8c1654a-6fe1-487e-9095-b4a5f2bcd22d@github.com>
 <AhfxQ0KFneqkzcwmZyT_BrIP7EPK8mq3TDxAOa_a0yI=.3daa6dc8-2844-4fe4-a2ea-a40e9ee38eaf@github.com>
Message-ID: <IhW7W0jh8z0Qs5RZwP0W4nUgyiXJbKGGtG6VwVJ6_Vw=.61492a73-946c-49d3-9dc8-7bbf4425b835@github.com>

On Fri, 7 Apr 2023 09:32:59 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Recommended changes
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 364:
> 
>> 362:         try {
>> 363:             return value.prepend(indexCoder, buf);
>> 364:         } catch (Throwable ex) {
> 
> This?should rethrow?errors (such?as?`OutOfMemoryError`):
> Suggestion:
> 
>         } catch (Error err) {
>             throw err;
>         } catch (Throwable ex) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 100:
> 
>> 98:         try {
>> 99:             return (List<Object>)valuesMH.invokeExact(this);
>> 100:         } catch (RuntimeException | OutOfMemoryError ex) {
> 
> Suggestion:
> 
>         } catch (RuntimeException | Error ex) {

Changing

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 111:
> 
>> 109:         try {
>> 110:             return (String) interpolateMH.invokeExact(this);
>> 111:         } catch (RuntimeException | OutOfMemoryError ex) {
> 
> Suggestion:
> 
>         } catch (RuntimeException | Error ex) {

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119626
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119647
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1161119669

From jlaskey at openjdk.org  Sat Apr  8 15:51:36 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Sat, 8 Apr 2023 15:51:36 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@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:

  Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/62eadb84..6016deb8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=55
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=54-55

  Stats: 3 lines in 1 file changed: 1 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 cdecatheu at hey.com  Mon Apr 10 13:27:29 2023
From: cdecatheu at hey.com (Cyril de Catheu)
Date: Mon, 10 Apr 2023 15:27:29 +0200
Subject: [user-question] on eval value size limit
Message-ID: <c90e7459a3a123302ca0421ae7a45b697cfdac0b@hey.com>

Hey,?
I'm a user of jshell, I hope this is the correct mailing list for my
question.
It seems jshell snippets value have a character limit.?

It can be reproduced in a jshell with the following (sorry for the long
strings):?

jshell> "a".repeat(21842);
$1 ==>
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
...
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"

jshell> "a".repeat(21843);
$2 ==>
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
...
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

--> notice in the second case the last character is cut.
So the limit seems to be of around 21842 characters.?

This does not look related to the jshell tool, it can also be reproduced
with a jdk.jshell.JShell instance programmatically. It seems to be
happening down in the ExecutionControl implementation.

This is an issue for me because I'm using functions that return html or
json that are >>20k characters, so my results get broken.

Is there a way to change this limit?

Have a nice day.
Cyril de Catheu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230410/fe546d8f/attachment.htm>

From jan.lahoda at oracle.com  Tue Apr 11 15:45:20 2023
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Tue, 11 Apr 2023 17:45:20 +0200
Subject: [user-question] on eval value size limit
In-Reply-To: <c90e7459a3a123302ca0421ae7a45b697cfdac0b@hey.com>
References: <c90e7459a3a123302ca0421ae7a45b697cfdac0b@hey.com>
Message-ID: <d12b05db-053b-6ac3-1da7-9976a5fba306@oracle.com>

Hi Cyril,


For the remote execution backend (which is the default) is used, I 
believe the truncation of the variable content is hardcoded, and cannot 
be changed by the user. But for local/in-process execution backend, the 
backend should not truncate the output. So, using the local execution 
might be part of the solution. In the API, it could be something like:

 ??? public static void main(String[] args) {
 ??????? {
 ??????????? JShell j = JShell.builder().build();
 ??????????? for (SnippetEvent evt : j.eval("\"a\".repeat(65536)")) {
 ??????????????? System.err.println("output default execution: " + 
evt.value().length());
 ??????????? }
 ??????? }
 ??????? {
 ??????????? JShell j = JShell.builder().executionEngine("local").build();
 ??????????? for (SnippetEvent evt : j.eval("\"a\".repeat(65536)")) {
 ??????????????? System.err.println("output local execution: " + 
evt.value().length());
 ??????????? }
 ??????? }
 ??? }


which produces:

output default execution: 21844
output local execution: 65538


For the actual tool, there are feedback mode that define the truncation 
limit (inside the "UI" tool), and these can be set. For example:

$ ./jshell --execution local
|? Welcome to JShell -- Version 21-internal
|? For an introduction type: /help intro

jshell> /set mode custom normal -command
|? Created new feedback mode: custom

jshell> /set truncation custom 2147483647 varvalue,expression

jshell> /set feedback custom
|? Feedback mode: custom

jshell> "a".repeat(65536)
$1 ==> "a... very long output


Please also note there's a related bugreport:

https://bugs.openjdk.org/browse/JDK-8299829


Thanks,

 ??? Jan


On 10. 04. 23 15:27, Cyril de Catheu wrote:
> Hey,
> I'm a user of jshell, I hope this is the correct mailing list for my 
> question.
> It seems jshell snippets value have a character limit.
>
> It can be reproduced in a jshell with the following (sorry for the 
> long strings):
>
> jshell> "a".repeat(21842);
> $1 ==> 
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
> ... 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa"
>
> jshell> "a".repeat(21843);
> $2 ==> 
> "aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 
> ... 
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
>
> --> notice in the second case the last character is cut.
> So the limit seems to be of around 21842 characters.
>
> This does not look related to the jshell tool, it can also be 
> reproduced with a jdk.jshell.JShell instance programmatically. It 
> seems to be happening down in the ExecutionControl implementation.
>
> This is an issue for me because I'm using functions that return html 
> or json that are >>20k characters, so my results get broken.
>
> Is there a way to change this limit?
>
> Have a nice day.
> Cyril de Catheu
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/kulla-dev/attachments/20230411/79e19e56/attachment-0001.htm>

From liach at openjdk.org  Wed Apr 12 15:55:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Apr 2023 15:55:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>

On Sat, 8 Apr 2023 15:51:36 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:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

A few comments on the API/CSR's specification. Thanks for uploading the Javadocs.

src/java.base/share/classes/java/lang/StringTemplate.java line 351:

> 349:      * then it is returned unchanged.
> 350:      */
> 351:     static StringTemplate combine(StringTemplate... stringTemplates) {

Sorry for a late mention, but I believe this method and its List variant are better named `concat` instead: `concat` indicates an explicitly ordered operation (String, Stream, AffineTransform), while `combine` is usually unordered (IntSummaryStatistics, CompletableFuture.thenCombine, Collector.combiner). Using `concat` also brings `String` and `StringTemplate` closer.

All examples come from using the search box with `concat` and `combine` in the code review Javadoc copy: https://cr.openjdk.org/~jlaskey/templates/docs/api/java.base/java/util/FormatProcessor.html

src/java.base/share/classes/java/lang/StringTemplate.java line 522:

> 520:      * {@link String};
> 521:      * {@snippet :
> 522:      * Processor<JSONObject, RuntimeException> jsonProcessor = st -> new JSONObject(st.interpolate());

This isn't quite a good example; it defeats the point of string templates, that injection attacks like `}, "another_key": {` can still happen with JSON.

src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 112:

> 110:         }
> 111:         interpolateMH = MethodHandles.filterArguments(interpolateMH, 0, components);
> 112:         mt = MethodType.methodType(String.class, StringTemplateImpl.class);

This MethodType can be stored in a static final field than created every time on the fly. Don't know if JIT compiler can inline this statement. Same fore that `List.class, StringTemplateImpl.class` type below.

src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 109:

> 107:      * @param lookup          method lookup
> 108:      * @param name            method name
> 109:      * @param type            method type

Maybe mention that the name is ignored, and the type must be convertible from `(String[], Object[])StringTemplate`? The specification says "fragments list" and "values list", which are more accurately described as arrays.

Also, does "large" string template mean there are more than 250~ fragments that the bootstrap method arguments can't fit, or does it mean dynamic number of fragments? Might be worth mentioning that as well.

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1381542020
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164313718
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164324857
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164284857
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164278200

From liach at openjdk.org  Wed Apr 12 17:46:47 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 12 Apr 2023 17:46:47 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <P_9HK0RpcWiS9WgNSxyfVYk506xRzIdPZz8KJk0Kz8E=.fe2290a7-d475-4b6d-8293-ba7930196a0d@github.com>

On Sat, 8 Apr 2023 15:51:36 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:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

Just curious, in what scenario can `StringTemplateTree.getProcessor()` evaluate to `null`, when `"{variable}"` is not a valid literal without a `StringTemplate.RAW.` qualifier?

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1505686329

From jlaskey at openjdk.org  Wed Apr 12 18:09:48 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 12 Apr 2023 18:09:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
Message-ID: <HYAv-m_6aRPQs7ierBE4Z86pw2n2pYT65tVoLHN-tgI=.aca4977f-fdb9-4e95-a928-48e8a8d19d1f@github.com>

On Sat, 8 Apr 2023 15:51:36 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:
> 
>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

This is a remnant from when the processor was not required.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1505712211

From jlaskey at openjdk.org  Wed Apr 12 19:02:22 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 12 Apr 2023 19:02:22 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@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 75 commits:

 - Merge branch 'master' into 8285932
 - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
 - Clean up Error handling
 - Recommended changes
 - RuntimeException is the only exception type that can is deduced from a lambda.
 - Update combine example
 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=56
  Stats: 9261 lines in 75 files changed: 9162 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 aturbanov at openjdk.org  Wed Apr 12 20:54:02 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 12 Apr 2023 20:54:02 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/lang/runtime/Carriers.java line 286:

> 284:          */
> 285:         MethodHandle constructor(CarrierShape carrierShape) {
> 286:             int longCount = carrierShape.longCount();

`longCount`/`intCount` seems unused in this method

src/java.base/share/classes/java/lang/runtime/Carriers.java line 369:

> 367:          * Cache mapping {@link MethodType} to previously defined {@link CarrierElements}.
> 368:          */
> 369:         private static Map<MethodType, CarrierElements>

Can it be made `final` ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164641033
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164640633

From aturbanov at openjdk.org  Wed Apr 12 21:02:00 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 12 Apr 2023 21:02:00 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <nctaH1CV9Q41hfLZwj6Z1hSrVN_gpBdZ_n4XBcyW0rY=.da4f802d-2626-4c0f-aeac-4bbedbf44223@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java line 28:

> 26: package jdk.internal.access;
> 27: 
> 28: import java.lang.invoke.MethodHandle;

Couple of unused imports

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1164647158

From aturbanov at openjdk.org  Thu Apr 13 07:48:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 07:48:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:

> 111:         @Override
> 112:         public String toString() {
> 113:             return "java.util.WeakKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:

> 170:         @Override
> 171:         public String toString() {
> 172:             return "java.util.SoftKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:

> 224:         @Override
> 225:         public String toString() {
> 226:             return "java.util.StrongKey#" + System.identityHashCode(this);

Why `java.util` ? It's a bit misleading

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 130:

> 128:     }
> 129: 
> 130:     @java.lang.Override

Suggestion:

    @Override

src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 131:

> 129: 
> 130:     @java.lang.Override
> 131:     public java.lang.String toString() {

Suggestion:

    public String toString() {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130712
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165130798
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165132919
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133244
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165133383

From aturbanov at openjdk.org  Thu Apr 13 09:40:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 13 Apr 2023 09:40:09 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <p81Ik8FFpIo7PzFcTzutZnXrlspAYpfb4WqgmZcXArs=.fdfe8066-1abe-47b6-a9d5-be643fd4be6a@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/FormatItem.java line 71:

> 69:                     MethodType.methodType(MethodHandle.class, long.class));
> 70: 
> 71:     private static final long charMix(long lengthCoder, char value) {

let's drop `final` modifier from `static` methods

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165274119

From jlaskey at openjdk.org  Thu Apr 13 12:01:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:01:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
 <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
Message-ID: <ko_Cs8ZNFbIaFWfomx-LHK-QMtMJQ8mtVoGAaBpS3EA=.fbdd5a4c-0a5b-44bd-8029-70e0cc4a9820@github.com>

On Wed, 12 Apr 2023 15:09:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 109:
> 
>> 107:      * @param lookup          method lookup
>> 108:      * @param name            method name
>> 109:      * @param type            method type
> 
> Maybe mention that the name is ignored, and the type must be convertible from `(String[], Object[])StringTemplate`? The specification says "fragments list" and "values list", which are more accurately described as arrays.
> 
> Also, does "large" string template mean there are more than 250~ fragments that the bootstrap method arguments can't fit, or does it mean dynamic number of fragments? Might be worth mentioning that as well.

Updating comments

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165418717

From jlaskey at openjdk.org  Thu Apr 13 12:15:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:15:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v56]
In-Reply-To: <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <3oVaYdmKp9fMrTjEf7ll4vuTqQi5KKbN2ERtV2bTevE=.b33c805e-4149-4b85-945c-b7e9dfb6c781@github.com>
 <5QkOHvuy9d8hQXPe6ETbT6fmE1No5e47lBCukDnNldY=.21ede21a-3340-47da-b69e-9322b7b9adc0@github.com>
Message-ID: <RgGhnFOTuTls6r4HJVObv6MyQZwDqkU0S3PooaSvQcI=.be5eefdb-b214-4aef-9e86-88795eee482a@github.com>

On Wed, 12 Apr 2023 15:15:09 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 112:
> 
>> 110:         }
>> 111:         interpolateMH = MethodHandles.filterArguments(interpolateMH, 0, components);
>> 112:         mt = MethodType.methodType(String.class, StringTemplateImpl.class);
> 
> This MethodType can be stored in a static final field than created every time on the fly. Don't know if JIT compiler can inline this statement. Same fore that `List.class, StringTemplateImpl.class` type below.

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165433226

From jlaskey at openjdk.org  Thu Apr 13 12:22:51 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:22:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>
Message-ID: <ZO_xat8BU3ZfeyfqSCsmBLSdxWKjpS87ihyB67PIWrM=.875b5c1a-794d-4d1c-8f52-1e1c9b92d142@github.com>

On Wed, 12 Apr 2023 20:50:35 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 286:
> 
>> 284:          */
>> 285:         MethodHandle constructor(CarrierShape carrierShape) {
>> 286:             int longCount = carrierShape.longCount();
> 
> `longCount`/`intCount` seems unused in this method

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 369:
> 
>> 367:          * Cache mapping {@link MethodType} to previously defined {@link CarrierElements}.
>> 368:          */
>> 369:         private static Map<MethodType, CarrierElements>
> 
> Can it be made `final` ?

Changing

> src/java.base/share/classes/jdk/internal/access/JavaTemplateAccess.java line 28:
> 
>> 26: package jdk.internal.access;
>> 27: 
>> 28: import java.lang.invoke.MethodHandle;
> 
> Couple of unused imports

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165440095
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165439152
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165442266

From jlaskey at openjdk.org  Thu Apr 13 12:38:10 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:38:10 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <4Smfn2tAtGrX5g31k9KRWLqq3E_-yh4X9ajnRu0PWsI=.3fb1b2b1-ded4-49d6-8da0-c77078bd7ce8@github.com>
Message-ID: <CFwI3PS89j7uNSqy0u0k436ktRFLf2F3mRojjryvAHc=.24eb2c4e-2270-4f96-b1b5-4c6f9acc3ab8@github.com>

On Thu, 13 Apr 2023 07:42:24 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 113:
> 
>> 111:         @Override
>> 112:         public String toString() {
>> 113:             return "java.util.WeakKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

Moved and not reflected in the string. Changing to `this.getClass().getCanonicalName() + "#" + System.identityHashCode(this);`

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 172:
> 
>> 170:         @Override
>> 171:         public String toString() {
>> 172:             return "java.util.SoftKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 226:
> 
>> 224:         @Override
>> 225:         public String toString() {
>> 226:             return "java.util.StrongKey#" + System.identityHashCode(this);
> 
> Why `java.util` ? It's a bit misleading

same

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 130:
> 
>> 128:     }
>> 129: 
>> 130:     @java.lang.Override
> 
> Suggestion:
> 
>     @Override

One of those IntelliJ things - ugh.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 131:
> 
>> 129: 
>> 130:     @java.lang.Override
>> 131:     public java.lang.String toString() {
> 
> Suggestion:
> 
>     public String toString() {

same

> src/java.base/share/classes/java/util/FormatItem.java line 71:
> 
>> 69:                     MethodType.methodType(MethodHandle.class, long.class));
>> 70: 
>> 71:     private static final long charMix(long lengthCoder, char value) {
> 
> let's drop `final` modifier from `static` methods

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165449867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450204
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165450363
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452561
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165452753
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165456644

From jlaskey at openjdk.org  Thu Apr 13 12:47:38 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 12:47:38 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v58]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <W8xbsb0XlDvC2JqrUHnti7ogxKW0IuZkYP9-ZsEV2yY=.393178aa-63b3-4993-9564-05e054f25e8c@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:

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f1b187a1..5e0dfce9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=57
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=56-57

  Stats: 38 lines in 7 files changed: 14 ins; 6 del; 18 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 rriggs at openjdk.org  Thu Apr 13 13:31:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 13:31:48 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

src/java.base/share/classes/java/util/Digits.java line 39:

> 37:  * @since 21
> 38:  */
> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

The Digits utility implementation class is not public and would be useful elsewhere before JEP 430 is final.
The PreviewFeature annotation is not needed and would impede its use else where, for example, in HexFormat.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165524941

From jlaskey at openjdk.org  Thu Apr 13 13:36:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 13:36:57 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@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:

  Remove preview feature on package private java.util.Digits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5e0dfce9..69f49bdf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=58
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=57-58

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 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 Apr 13 13:45:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 13:45:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>
Message-ID: <2Orq5gqsqNC3HRWPfyABqMlMk3i5lj2LB1Ib6ECHxQc=.3b7e9f34-96a7-405b-be17-71d9fa6c160a@github.com>

On Thu, 13 Apr 2023 13:29:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/util/Digits.java line 39:
> 
>> 37:  * @since 21
>> 38:  */
>> 39: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> The Digits utility implementation class is not public and would be useful elsewhere before JEP 430 is final.
> The PreviewFeature annotation is not needed and would impede its use else where, for example, in HexFormat.

Removing preview feature.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165543387

From jlaskey at openjdk.org  Thu Apr 13 16:37:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:37:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v60]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <HNXFWWDeLdcP1Y3r-DnaThYtkv1OeCFmyiNhj6NIMX8=.c7ce520e-e93d-4cc8-9350-c9f800763c93@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:

  HexDigits -> OctalDigits

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/69f49bdf..961a5417

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=59
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=58-59

  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 dfuchs at openjdk.org  Thu Apr 13 16:37:40 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 16:37:40 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
Message-ID: <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>

On Thu, 13 Apr 2023 13:36:57 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:
> 
>   Remove preview feature on package private java.util.Digits

src/java.base/share/classes/java/util/Digits.java line 233:

> 231: 
> 232:         /**
> 233:          * Singleton instance of HexDigits.

Suggestion:

         * Singleton instance of OctalDigits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165774156

From jlaskey at openjdk.org  Thu Apr 13 16:37:41 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:37:41 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
 <cqtw3in9QfR2gOdF0kYTHUOcbsXs4XPEM9qVqhleOxc=.1c5aa5cc-2cd5-4393-8105-5c5e460aa0ca@github.com>
Message-ID: <jEAED2oUquyG6rAXh497IQvkaVg5ksQNGNHZs4IMcbA=.14a323d6-30da-4f8c-978f-31a5c1a231b9@github.com>

On Thu, 13 Apr 2023 16:27:51 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove preview feature on package private java.util.Digits
>
> src/java.base/share/classes/java/util/Digits.java line 233:
> 
>> 231: 
>> 232:         /**
>> 233:          * Singleton instance of HexDigits.
> 
> Suggestion:
> 
>          * Singleton instance of OctalDigits.

Nice catch

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165778236

From dfuchs at openjdk.org  Thu Apr 13 16:42:15 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Apr 2023 16:42:15 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
Message-ID: <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>

On Thu, 13 Apr 2023 13:36:57 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:
> 
>   Remove preview feature on package private java.util.Digits

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

> 165:      * {@link FormatProcessor#process(StringTemplate)}. This {@link MethodHandle}
> 166:      * is used by {@link FormatProcessor#FMT} and the ilk to perform a more
> 167:      * specialized composition of a result. This is specialization is done by

Typo here? "This is specialization is done"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165785237

From jlaskey at openjdk.org  Thu Apr 13 16:54:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 16:54:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v59]
In-Reply-To: <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <qK50FJFg-4mKgeVzLQak-MSEK_0w_rtFqk7XmNg60v4=.dfef936b-efc8-47de-8bb8-ce8be9e2957e@github.com>
 <HnYdeuWGz5w8lbi8FXkmkFsTwefMsOPgdrUyi_84L4w=.dfbb9045-002c-4397-a584-789cd2d5d940@github.com>
Message-ID: <RxIYh3jdWoE_6WWtfNtigGAvE78IImTdcCn-b2OMPSU=.535b8e07-45db-4a7f-9fd0-8374cc2dd89d@github.com>

On Thu, 13 Apr 2023 16:38:25 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove preview feature on package private java.util.Digits
>
> src/java.base/share/classes/java/util/FormatProcessor.java line 167:
> 
>> 165:      * {@link FormatProcessor#process(StringTemplate)}. This {@link MethodHandle}
>> 166:      * is used by {@link FormatProcessor#FMT} and the ilk to perform a more
>> 167:      * specialized composition of a result. This is specialization is done by
> 
> Typo here? "This is specialization is done"

removing "is"

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165799277

From jlaskey at openjdk.org  Thu Apr 13 17:09:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 17:09:13 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@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:

  Typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/961a5417..f27ad709

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=60
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=59-60

  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 rriggs at openjdk.org  Thu Apr 13 18:13:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 18:13:25 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
Message-ID: <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>

On Thu, 13 Apr 2023 17:09:13 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:
> 
>   Typo

src/jdk.incubator.concurrent/share/classes/module-info.java line 35:

> 33:     exports jdk.incubator.concurrent;
> 34: }
> 35: 

Not related to StringTemplates; could be left as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165615588

From rriggs at openjdk.org  Thu Apr 13 18:13:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 18:13:19 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>

On Wed, 12 Apr 2023 19:02:22 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 with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

The PreviewFeature annotations can/should be removed from classes/methods that are not part of the public interface. They are unnecessary and possibly misleading, implying part of the public interface.

src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:

> 552: 
> 553:     /**
> 554:      * Class used to tally ahd track the number of ints, longs and objects.

typo: ahd

src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:

> 35:  * @since 21
> 36:  */
> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

Generally, The `PreviewFeature` annotation is not needed on internal APIs and serves little purpose.

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1383555414
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165702256
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165631226

From jlaskey at openjdk.org  Thu Apr 13 19:01:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:01:05 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v57]
In-Reply-To: <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
 <U7ScSkaMKh0oLYW_3qPtTc0dX6rU67_-YBirL9G0QpI=.0fd09d8d-1fd6-4f0b-9b9a-77e79b760fee@github.com>
Message-ID: <TxUiPpReLmcDuL49va3jxFdzd2eI87l0JUrGSP4hARo=.3102ce2e-29e5-4c66-9495-fa3d9c6f09d5@github.com>

On Thu, 13 Apr 2023 15:27:12 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
>> 
>>  - Merge branch 'master' into 8285932
>>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>>  - Clean up Error handling
>>  - Recommended changes
>>  - RuntimeException is the only exception type that can is deduced from a lambda.
>>  - Update combine example
>>  - Merge branch 'master' into 8285932
>>  - Update StringTemplate.combine javadoc
>>  - Requested review changes.
>>  - Clean up list construction
>>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1
>
> src/java.base/share/classes/java/lang/runtime/Carriers.java line 554:
> 
>> 552: 
>> 553:     /**
>> 554:      * Class used to tally ahd track the number of ints, longs and objects.
> 
> typo: ahd

Will fix.

> src/java.base/share/classes/jdk/internal/util/FormatConcatItem.java line 37:
> 
>> 35:  * @since 21
>> 36:  */
>> 37: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> Generally, The `PreviewFeature` annotation is not needed on internal APIs and serves little purpose.

PreviewFeature might be heavy handed. I can replace it with a warning to not depend on this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915844
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165915665

From jlaskey at openjdk.org  Thu Apr 13 19:01:09 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:01:09 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v61]
In-Reply-To: <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <jayHaXL1Rijkezg5u8iUXIYB0NVds5SnQITdu1NtsUg=.c69b7ca8-d363-4489-ac29-029ae62ec2f1@github.com>
 <PM3kLa9PJ7UhH2SajPm1HwBzBZDUEFDuHz8oupWyFIo=.1a2ea76a-87ff-498c-9b04-624977ee0b11@github.com>
Message-ID: <AEK10ysW4cwzgdKz1H9C1YjE_3ZI-iL2GXKrjBBmqjU=.bdd162b1-aff4-4d5c-a4ed-d273f4444d72@github.com>

On Thu, 13 Apr 2023 14:30:19 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Typo
>
> src/jdk.incubator.concurrent/share/classes/module-info.java line 35:
> 
>> 33:     exports jdk.incubator.concurrent;
>> 34: }
>> 35: 
> 
> Not related to StringTemplates; could be left as is.

Agree - I think it must have been a merge issue. I don't recall having a need to change this file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1165914905

From jlaskey at openjdk.org  Thu Apr 13 19:45:59 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 13 Apr 2023 19:45:59 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v62]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@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:

  Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f27ad709..70c215c6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=61
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=60-61

  Stats: 54 lines in 10 files changed: 30 ins; 23 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 rriggs at openjdk.org  Thu Apr 13 20:28:51 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 20:28:51 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v62]
In-Reply-To: <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <EshG5qcfwecXSS9cQj-3YH3tayV0xuXKUkMqQuUvlSo=.b9e627d5-22f9-4326-9780-d069df8d5aa3@github.com>
Message-ID: <3v1bFtY5NV-SJ2oeYKedlQfsLCCFCsxq2dOW1CaFd5E=.ba437051-8d3e-488c-8173-b46cf34ac5d2@github.com>

On Thu, 13 Apr 2023 19:45:59 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:
> 
>   Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes

Core library files look good to me.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1384156858

From duke at openjdk.org  Sat Apr 15 02:03:41 2023
From: duke at openjdk.org (duke)
Date: Sat, 15 Apr 2023 02:03:41 GMT
Subject: Withdrawn: 8298044: Fix hidden but significant trailing whitespace in
 properties files for langtools code
In-Reply-To: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
References: <XTrtCArjzxYwYSv-IZZ_I1vdatcAPUNmDMURw33rHg0=.a3f2717c-a5c1-403b-899a-7f4af166a891@github.com>
Message-ID: <rj7lON6h3c2xK7O5Ey_ctMcLhMo_841ZCLsROQwfdjU=.05289d9e-1c2f-4986-9d3a-c4b9c2b8b94b@github.com>

On Fri, 2 Dec 2022 16:36:22 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> According to [the specification](https://docs.oracle.com/en/java/javase/19/docs/api/java.base/java/util/Properties.html#load(java.io.Reader)) trailing whitespaces in the values of properties files are (somewhat surprisingly) actually significant.
> 
> We have multiple files in the JDK with trailing whitespaces in the values. For most of this files, this is likely incorrect and due to oversight, but in a few cases it might actually be intended (like "The value is: ").
> 
> After a discussion in the PR for [JDK-8295729](https://bugs.openjdk.org/browse/JDK-8295729), the consensus was to replace valid trailing spaces with the corresponding unicode sequence, `\u0020`. (And of course remove non-wanted trailing spaces.)
> 
> Doing so has a dual benefit:
> 
> 1) It makes it clear to everyone reading the code that there is a trailing space and it is intended
> 
> 2) It will allow us to remove all actual trailing space characters, and turn on the corresponding check in jcheck to keep the properties files, just like all other source code files, free of trailing spaces.
> 
> Ultimately, the call of whether a trailing space is supposed to be there, or is a bug, lies with the respective component teams owning these files. Thus I have split up the set of properties files with trailing spaces in several groups, to match the JDK teams, and open a JBS issue for each of them. This issue is for code I believe belongs with the langtools team.

This pull request has been closed without being integrated.

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

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

From jlaskey at openjdk.org  Tue Apr 18 13:40:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 18 Apr 2023 13:40:04 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v63]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <detyyRHhaFRUMjl6xHiBrjMLwXIKzp0G6AzHJGGzYu0=.d97e0788-c644-4d91-af5a-3a3f5d7cb672@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:

 - Spacing
 - Tidy up

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/70c215c6..c6d943c3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=62
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=61-62

  Stats: 7 lines in 4 files changed: 5 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 abimpoudis at openjdk.org  Tue Apr 25 12:14:14 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Tue, 25 Apr 2023 12:14:14 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables
Message-ID: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>

This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.

Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

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

Depends on: https://git.openjdk.org/jdk/pull/13074

Commit messages:
 - Fix indentation in JavacParser
 - Merge branch 'JDK-8300543' into unnamed
 - Fix top level type pattern with underscore
 - Introduce source in MemberEnter (javadoc uses MemberEnter)
 - Merge branch 'JDK-8300543' into unnamed
 - Fix parsePattern after merge
 - Fix
 - Implement cases with multiple unnamed patterns and guards
 - WIP: guards
 - Merge branch 'JDK-8300543' into unnamed
 - ... and 14 more: https://git.openjdk.org/jdk/compare/35f51562...6e3f495e

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8302344
  Stats: 767 lines in 32 files changed: 596 ins; 52 del; 119 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From cstein at openjdk.org  Tue Apr 25 14:25:10 2023
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 25 Apr 2023 14:25:10 GMT
Subject: RFR: 8306560: Add TOOLING.jsh load file
Message-ID: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>

This PR adds the `TOOLING.jsh` load file for being used in `jshell TOOLING` commands.

_Man page update is pending..._

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

Commit messages:
 - Add `TOOLING` load file name into help messages
 - Add dedicated `TOOLING` test class
 - Include `TOOLING` in compound start test
 - 8306560: Add TOOLING.jsh load file

Changes: https://git.openjdk.org/jdk/pull/13609/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13609&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306560
  Stats: 165 lines in 6 files changed: 153 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/13609.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13609/head:pull/13609

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

From acobbs at openjdk.org  Tue Apr 25 20:47:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Apr 2023 20:47:57 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before super()
Message-ID: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>

This is a first draft of a patch for JEP 447.

Summary of changes:

1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement

The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.

Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

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

Commit messages:
 - Use for() loop instead of stream for efficiency.
 - Fix typo in comment.
 - Merge branch 'master' into SuperInit
 - Fix Javadoc comment.
 - Merge branch 'master' into SuperInit
 - Merge branch 'master' into SuperInit
 - Merge branch 'master' into SuperInit
 - Merge branch 'master' into SuperInit
 - Merge branch 'master' into SuperInit
 - Merge branch 'master' into SuperInit
 - ... and 4 more: https://git.openjdk.org/jdk/compare/bad6aa68...0eac8b68

Changes: https://git.openjdk.org/jdk/pull/13656/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13656&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8194743
  Stats: 1340 lines in 20 files changed: 1076 ins; 162 del; 102 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

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

From duke at openjdk.org  Wed Apr 26 01:22:23 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 26 Apr 2023 01:22:23 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super()
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <JS8QxzGUlF0SmHjGbODz7ZpFJVaO5iOUKVFEKdE9PFc=.2fd5f08e-45cd-4c93-9b9f-09fb9b4e3afb@github.com>

On Tue, 25 Apr 2023 20:40:18 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5591:

> 5589:         }
> 5590: 
> 5591:         // Check for proper placement of super()/init() calls.

Suggestion:

        // Check for proper placement of super()/this() calls.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2859:

> 2857:                         letInit(tree.pos(), sym);
> 2858:                 }
> 2859:             }

The?common `isConstructor`?check can?be?moved to?an?enclosing `if`?statement:

Suggestion:

            if (isConstructor) {
                // If super(): at this point all initialization blocks will execute
                Name name = TreeInfo.name(tree.meth);
                if (name == names._super) {
                    forEachInitializer(classDef, false, def -> {
                        scan(def);
                        clearPendingExits(false);
                    });
                }

                // If this(): at this point all final uninitialized fields will get initialized
                else if (name == names._this) {
                    for (int address = firstadr; address < nextadr; address++) {
                        VarSymbol sym = vardecls[address].sym;
                        if (isFinalUninitializedField(sym) && !sym.isStatic())
                            letInit(tree.pos(), sym);
                    }
                }
            }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177207245
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177209992

From acobbs at openjdk.org  Wed Apr 26 02:25:57 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 26 Apr 2023 02:25:57 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v2]
In-Reply-To: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
Message-ID: <0iBw7BzPsaoSs-4C4n5imanznVXSwaiN4hfigr34H60=.af35031e-d089-4406-a82e-840fb3f01c72@github.com>

> This is a first draft of a patch for JEP 447.
> 
> Summary of changes:
> 
> 1. Track when we're within a constructor "prologue" via new flag `AttrContext.ctorPrologue`
> 1. Add checks for illegal early access to `this` in constructor prologues, and update existing checks to distinguish between static context vs. constructor prologue context
> 1. Verify allowed placement of `super()`/`this()` calls via new method `Check.checkSuperInitCalls()`
> 1. Remove/refactor assumptions in several places that `super()`/`this()` was always the first statement
> 
> The changes in `Flow.java` are an example of <span>#</span>4. `Flow.FlowAnalyzer` checks for uncaught checked exceptions. For initializer blocks, this was previously done by requiring that any checked exceptions thrown be declared as thrown by all constructors containing `super()`. This list of checked exceptions was being pre-calculated before recursing into the initial constructors. This worked because initializer blocks were executed at the beginning of each initial constructor right after `super()` is called.
> 
> Now initializer blocks are traversed as each `super()` invocation is encountered, reflecting what actually happens at runtime. Similarly, final fields are marked as DA after encountering `this()`, not automatically at the beginning of those  constructors. These changes produce equivalent checks, but are compatible with the new flexibility of placement of `super()`/`this()` as well as possible future changes that could occur along these same lines.

Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:

 - Small refactoring to avoid redundant test.
 - Fix typo in comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13656/files
  - new: https://git.openjdk.org/jdk/pull/13656/files/0eac8b68..0e638da2

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

  Stats: 25 lines in 2 files changed: 10 ins; 6 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/13656.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13656/head:pull/13656

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

From acobbs at openjdk.org  Wed Apr 26 02:27:24 2023
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 26 Apr 2023 02:27:24 GMT
Subject: RFR: 8194743: Compiler implementation for Statements before
 super() [v2]
In-Reply-To: <JS8QxzGUlF0SmHjGbODz7ZpFJVaO5iOUKVFEKdE9PFc=.2fd5f08e-45cd-4c93-9b9f-09fb9b4e3afb@github.com>
References: <NOF-YbVLoOgUEvt-pWZVkbKkLnkSH-9ek3IGUb7JBfo=.a6db8599-7c2b-4534-aeb2-1d5d67c9cc57@github.com>
 <JS8QxzGUlF0SmHjGbODz7ZpFJVaO5iOUKVFEKdE9PFc=.2fd5f08e-45cd-4c93-9b9f-09fb9b4e3afb@github.com>
Message-ID: <5JSNfp3HQJp86bdSxKe0Zgl4TCZ9HgU44vvBtyqb9n0=.db9550dd-1a27-42ef-9534-7c65b1cafb43@github.com>

On Wed, 26 Apr 2023 01:06:37 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Small refactoring to avoid redundant test.
>>  - Fix typo in comment.
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 5591:
> 
>> 5589:         }
>> 5590: 
>> 5591:         // Check for proper placement of super()/init() calls.
> 
> Suggestion:
> 
>         // Check for proper placement of super()/this() calls.

Thanks for catching that - fixed in 0e638da2daa.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 2859:
> 
>> 2857:                         letInit(tree.pos(), sym);
>> 2858:                 }
>> 2859:             }
> 
> The?common `isConstructor`?check can?be?moved to?an?enclosing `if`?statement:
> 
> Suggestion:
> 
>             if (isConstructor) {
>                 // If super(): at this point all initialization blocks will execute
>                 Name name = TreeInfo.name(tree.meth);
>                 if (name == names._super) {
>                     forEachInitializer(classDef, false, def -> {
>                         scan(def);
>                         clearPendingExits(false);
>                     });
>                 }
> 
>                 // If this(): at this point all final uninitialized fields will get initialized
>                 else if (name == names._this) {
>                     for (int address = firstadr; address < nextadr; address++) {
>                         VarSymbol sym = vardecls[address].sym;
>                         if (isFinalUninitializedField(sym) && !sym.isStatic())
>                             letInit(tree.pos(), sym);
>                     }
>                 }
>             }

Yep, thanks - applied in 0e638da2daa.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177249124
PR Review Comment: https://git.openjdk.org/jdk/pull/13656#discussion_r1177249633

From abimpoudis at openjdk.org  Wed Apr 26 15:28:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Wed, 26 Apr 2023 15:28:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables [v2]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <hJBIUmsRA-v21ASBKKejBwV_cdxl0QkdcSQQNPAcL3k=.1b800b39-838e-4f27-9e91-cbcce8372d7f@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Introduce new flag to track unnamed variables
  
  - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/6e3f495e..624d3f4f

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

  Stats: 308 lines in 16 files changed: 278 ins; 10 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From cstein at openjdk.org  Wed Apr 26 15:55:00 2023
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 26 Apr 2023 15:55:00 GMT
Subject: RFR: 8306560: Add TOOLING.jsh load file [v2]
In-Reply-To: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>
References: <D_Y5zRi3BVl6f2nknM9eXorEPdSK6NooGk4mf5j3e3U=.9f242609-33f7-4edf-b7d2-ea7e51ff238e@github.com>
Message-ID: <7RChGscBY8dup0BwH07KmqQqpKw5i7yE4FZD9U36938=.460372ec-111e-4f79-935c-db9d77579caf@github.com>

> This PR adds the `TOOLING.jsh` load file for being used in `jshell TOOLING` commands.
> 
> _Man page update is pending..._

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Improve help text

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13609/files
  - new: https://git.openjdk.org/jdk/pull/13609/files/03e2ca7c..36eae334

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

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

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

From darcy at openjdk.org  Wed Apr 26 17:52:53 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 26 Apr 2023 17:52:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables [v2]
In-Reply-To: <hJBIUmsRA-v21ASBKKejBwV_cdxl0QkdcSQQNPAcL3k=.1b800b39-838e-4f27-9e91-cbcce8372d7f@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hJBIUmsRA-v21ASBKKejBwV_cdxl0QkdcSQQNPAcL3k=.1b800b39-838e-4f27-9e91-cbcce8372d7f@github.com>
Message-ID: <f2Nvfzov-ihfxye-mQx35YJWAbr4yJQ4_001UE2BojI=.2117e868-3451-4047-83e3-c116fc733c1e@github.com>

On Wed, 26 Apr 2023 15:28:24 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Introduce new flag to track unnamed variables
>   
>   - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName()

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 716:

> 714:      * @since 21
> 715:      */
> 716:     default boolean hasEmptyName(Element element) {

Updating some suggestions from an off-list discussion, ModuleElement and PackageElement both have an isUnnamed predicate. VariableElement could get an isUnnamed predicate (as a default method returning false and an implSpec tag requiring that) or Elements.isUnnamed(VariableElement) could be added similarly.

Presumably, at least any newly-defined methods should get marked as some category of preview method.

Also, please file a issue against core-libs/javax.lang.model for javax.lang.model support for this JEP; having a separate issue makes doing the JSR 269 maintenance release work easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1178201512

From jlaskey at openjdk.org  Thu Apr 27 14:11:30 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 14:11:30 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v64]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <fVWfTck67lnBJ5lbxifBwKLQe4fq4wJ5vtNHN3Vb7uE=.4c8007b7-4a31-4979-869f-9c673a8f56d8@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 83 commits:

 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - HexDigits -> OctalDigits
 - Remove preview feature on package private java.util.Digits
 - Recommended changes
 - Merge branch 'master' into 8285932
 - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
 - ... and 73 more: https://git.openjdk.org/jdk/compare/96cdf93b...5c182232

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63
  Stats: 9276 lines in 73 files changed: 9179 ins; 23 del; 74 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 abimpoudis at openjdk.org  Thu Apr 27 14:16:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 27 Apr 2023 14:16:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables [v3]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address javax.lang.model comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/624d3f4f..19f1fc32

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

  Stats: 21 lines in 5 files changed: 18 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From abimpoudis at openjdk.org  Thu Apr 27 14:35:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 27 Apr 2023 14:35:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables [v2]
In-Reply-To: <f2Nvfzov-ihfxye-mQx35YJWAbr4yJQ4_001UE2BojI=.2117e868-3451-4047-83e3-c116fc733c1e@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hJBIUmsRA-v21ASBKKejBwV_cdxl0QkdcSQQNPAcL3k=.1b800b39-838e-4f27-9e91-cbcce8372d7f@github.com>
 <f2Nvfzov-ihfxye-mQx35YJWAbr4yJQ4_001UE2BojI=.2117e868-3451-4047-83e3-c116fc733c1e@github.com>
Message-ID: <NqSOXmJXghmsv3fmSHhjtXBq65ePbUnOOPiXDY-vHWE=.0b7a924a-e288-43f4-8cef-604fd1ddc570@github.com>

On Wed, 26 Apr 2023 17:36:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Introduce new flag to track unnamed variables
>>   
>>   - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName()
>
> src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 716:
> 
>> 714:      * @since 21
>> 715:      */
>> 716:     default boolean hasEmptyName(Element element) {
> 
> Updating some suggestions from an off-list discussion, ModuleElement and PackageElement both have an isUnnamed predicate. VariableElement could get an isUnnamed predicate (as a default method returning false and an implSpec tag requiring that) or Elements.isUnnamed(VariableElement) could be added similarly.
> 
> Presumably, at least any newly-defined methods should get marked as some category of preview method.
> 
> Also, please file a issue against core-libs/javax.lang.model for javax.lang.model support for this JEP; having a separate issue makes doing the JSR 269 maintenance release work easier.

PR updated. Thanks for the review!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179253720

From abimpoudis at openjdk.org  Thu Apr 27 14:56:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Thu, 27 Apr 2023 14:56:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Update test files with JDK 8307007 bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/19f1fc32..cbe4c31b

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

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

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

From vromero at openjdk.org  Thu Apr 27 15:33:25 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 27 Apr 2023 15:33:25 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v3]
In-Reply-To: <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>
Message-ID: <xWlwJC92eItl_tCdvGbJG3Vv2znQBdbuK-pXipEcdvk=.ee1c5769-bc0c-411e-977f-50df182977a8@github.com>

On Thu, 27 Apr 2023 14:16:30 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address javax.lang.model comments

src/jdk.compiler/share/classes/com/sun/source/tree/AnyPatternTree.java line 2:

> 1: /*
> 2:  * Copyright (c) 2017, 2019, Oracle and/or its affiliates. All rights reserved.

nit: copy year should be 2023? new file

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278:

> 276: 
> 277:     /**
> 278:      * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed.

question: cant we infer this from the name itself instead of consuming a flag?

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Preview.java line 215:

> 213:             //When real preview features will be added, this method can be implemented to return 'true'
> 214:             //for those selected features, and 'false' for all the others.
> 215:             case UNNAMED_VARIABLES -> true;

the comment above should apply to the default case I think

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179247824
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179251556
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179252709

From jlaskey at openjdk.org  Thu Apr 27 17:21:23 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 27 Apr 2023 17:21:23 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v65]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@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:

  CSR recommendations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/5c182232..fb406d23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63-64

  Stats: 115 lines in 3 files changed: 71 ins; 27 del; 17 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 darcy at openjdk.org  Thu Apr 27 17:33:22 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 27 Apr 2023 17:33:22 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
Message-ID: <4UQim1BWRWMhwV7OeVCPnWOlM7KnoHSa_S8e_b4n40Y=.ef821c49-5ec5-443c-9c54-086915e440b7@github.com>

On Thu, 27 Apr 2023 14:56:53 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test files with JDK 8307007 bug id

src/java.compiler/share/classes/javax/lang/model/element/VariableElement.java line 106:

> 104:      * false} otherwise}
> 105:      *
> 106:      * @jls 6.1 Declarations

Please include an implSpec tag for returning false by default.

src/java.compiler/share/classes/javax/lang/model/util/Elements.java line 714:

> 712:     /**
> 713:      * {@return {@code true} if the element has an empty name, {@code false} otherwise}
> 714:      *

Please include an implSpec tag for returning false by default.

For testing the default method, see the use of VaccuousElements in tests in files like

test/langtools/tools/javac/processing/model/util/elements/TestRecordPredicates.java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179474266
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1179481934

From mcimadamore at openjdk.org  Fri Apr 28 09:45:55 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Apr 2023 09:45:55 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v3]
In-Reply-To: <xWlwJC92eItl_tCdvGbJG3Vv2znQBdbuK-pXipEcdvk=.ee1c5769-bc0c-411e-977f-50df182977a8@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>
 <xWlwJC92eItl_tCdvGbJG3Vv2znQBdbuK-pXipEcdvk=.ee1c5769-bc0c-411e-977f-50df182977a8@github.com>
Message-ID: <vSJfM09xs14nK5muLU-PaU_IaqRC-lBG-28sloepzR8=.08ed221c-c341-496d-b51b-9c946b039b00@github.com>

On Thu, 27 Apr 2023 14:30:22 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address javax.lang.model comments
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278:
> 
>> 276: 
>> 277:     /**
>> 278:      * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed.
> 
> question: cant we infer this from the name itself instead of consuming a flag?

I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180155474

From mcimadamore at openjdk.org  Fri Apr 28 09:46:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Apr 2023 09:46:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v4]
In-Reply-To: <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <hnd9UyOUlz7cDrjBGvM0cDikvHsUGUPHH5_PW47SJQ8=.65a06139-496b-47a5-832a-62f0367d35f2@github.com>
Message-ID: <KWkhcjT0YrtpQbu3TRuBU-vbeE-N2jR_L9iwXYu1uNY=.83e2aebb-7dbe-4558-a57c-254d5a213918@github.com>

On Thu, 27 Apr 2023 14:56:53 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
>> 
>> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/
>
> Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test files with JDK 8307007 bug id

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 240:

> 238:         RECORD_PATTERNS(JDK21, Fragments.FeatureDeconstructionPatterns, DiagKind.PLURAL),
> 239:         WARN_ON_ILLEGAL_UTF8(MIN, JDK21),
> 240:         UNNAMED_VARIABLES(JDK21, Fragments.FeatureUnnamedVariables, DiagKind.PLURAL),

While the JEP unifies unnamed variables and unnamed patterns, would it make sense, at the code level, to split between the two?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Attr.java line 1777:

> 1775:                                 log.error(guard.pos(), Errors.GuardHasConstantExpressionFalse);
> 1776:                             }
> 1777:                         } else if (guard != null) {

I guess this is caused by something like:

case _ when ...

If now a guard can appear regardless of how many labels there are, should be refactor this code so that if `guard != null` it is always attributed? And then we do other stuff in case `labels.tail.isEmpty()` ? Note that the code for attributing the guard is slightly different in the two cases in this patch: the original code creates a nested scope - while the new code doesn't.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 746:

> 744: 
> 745:         sealed interface PatternDescription {
> 746:             public static PatternDescription from(Types types, Type selectorType, JCPattern pattern, Symtab syms) {

Optional comment: the fact that this factory needs so much compiler state makes me think that perhaps a better place for it would be as an instance method of Flow, rather than a static method in PatternDescription.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/MemberEnter.java line 295:

> 293:                 : tree.vartype.type;
> 294:         Name name;
> 295:         if (Feature.UNNAMED_VARIABLES.allowedInSource(source) && (tree.mods.flags & UNNAMED) != 0) {

Not 100% sure what this code does. E.g. shouldn't we just set the name of the variable as the name stored in the tree? It seems more economical if we could just set in the parser the name as empty (if preview features are enabled etc.) - and then all these special cases can disappear. After all, you still have the flag (and even then, do we need a flag? Can't we just see whether the name is empty to see that it's unnamed?)

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 826:

> 824:                 //type test pattern:
> 825:                 UnnamedDetails result = identOrFlagUnderscore(mods);
> 826:                 JCVariableDecl var = toP(F.at(result.varPos()).VarDef(mods, result.name(), e, null));

Do you think we can delegate to `variableDeclarator` here?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 839:

> 837:     }
> 838: 
> 839:     private UnnamedDetails identOrFlagUnderscore(JCModifiers mods) {

I'm not 100% sure this is required - the main use seems to be in `variableDeclarator` - but in that method you already have a token to look at, and a set of modifiers that you can augment - so why not just doing everything in that method (instead of preprocessing it?)

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3555:

> 3553:      */
> 3554:     JCVariableDecl variableDeclarator(JCModifiers mods, JCExpression type, boolean reqInit, Comment dc, boolean localDecl) {
> 3555:         UnnamedDetails result = identOrFlagUnderscore(mods);

Why do we need to get the "unnamed details" here, instead of letting the code flow to `variableDeclaratorRest` and do it there?

src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java line 3660:

> 3658:         int pos = token.pos;
> 3659:         Name name;
> 3660:         if (allowThisIdent ||

I note that now the error re. underscore on lambda is no longer given even if preview features are disabled. But I guess that's ok. (instead you will probably get an error that unnamed parameters are a preview feature)

test/langtools/tools/javac/TryWithResources/TwrLintUnderscore.java line 22:

> 20:         return;
> 21:     }
> 22: }

Add a newline at the end of this file (also check others)

test/langtools/tools/javac/patterns/Unnamed.java line 148:

> 146:     }
> 147: 
> 148:     // JEP

This comment looks odd - either we also add JEP number, or we can just drop it.

test/langtools/tools/javac/patterns/Unnamed.java line 153:

> 151:     record ColoredPoint(Point p, Color c) { }
> 152: 
> 153:     void jep(ColoredPoint r) {

Same as above for this method name

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180130293
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180139794
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180158709
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180153920
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180123845
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180124901
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180125696
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180128207
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180164818
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180168228
PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180168421

From duke at openjdk.org  Fri Apr 28 14:19:54 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 28 Apr 2023 14:19:54 GMT
Subject: RFR: 8305714 : JShell crashes when trying to throw a non-exist
 exception in certain lambdas
Message-ID: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>

testing for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.

This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.

Reviewer: @coffeys @lahodaj

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

Commit messages:
 - test for undefined class

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

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

From coffeys at openjdk.org  Fri Apr 28 15:52:53 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Fri, 28 Apr 2023 15:52:53 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <RRNfk9NT_tl6349o6oAPM3W9Yo9CAt4FSjFa9zlPUmE=.331f7df8-83b9-4e48-8908-7d8dbd5821ec@github.com>

On Fri, 28 Apr 2023 13:47:40 GMT, Weibing Xiao <duke at openjdk.org> wrote:

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

test/langtools/jdk/jshell/UndefinedClassTest.java line 26:

> 24: /**
> 25:  * @test
> 26:  * @bug 8305714

8292755 would be the bug ID here since it refers to the product bug. 

Is there a reason why you couldn't fold this test into the test/langtools/jdk/jshell/ClassesTest.java test ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13719#discussion_r1180556572

From duke at openjdk.org  Fri Apr 28 16:20:24 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 28 Apr 2023 16:20:24 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v2]
In-Reply-To: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
Message-ID: <zjm8VwExtNx-yK6UEniF3NgwHSkHvD9Tz-8OzlUaDig=.cc6ce6a0-8b80-4665-b3cc-6a5b230bfcd3@github.com>

> Add a testing case for undefined classes in Java JShell to make sure JShell does not crash when an undefined class is used.
> 
> This test was passed for Linux, MacOS, and Windows by mach5 build and test in Oracle.
> 
> Reviewer: @coffeys @lahodaj

Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:

  modify bug id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13719/files
  - new: https://git.openjdk.org/jdk/pull/13719/files/571f2360..5750a105

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

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

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

From abimpoudis at openjdk.org  Fri Apr 28 16:20:30 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 28 Apr 2023 16:20:30 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v5]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <xHFX8jxWhdLyH-E_8DpzqpxRfkoKFSrSLZiHaEvGSso=.ac6dbe2d-dd9f-4a6f-9c7f-665f63adf2a6@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Fix field error detection

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/cbe4c31b..59910b94

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

  Stats: 32 lines in 3 files changed: 15 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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

From duke at openjdk.org  Fri Apr 28 16:20:26 2023
From: duke at openjdk.org (Weibing Xiao)
Date: Fri, 28 Apr 2023 16:20:26 GMT
Subject: RFR: 8305714 : Add an extra test for JDK-8292755 [v2]
In-Reply-To: <RRNfk9NT_tl6349o6oAPM3W9Yo9CAt4FSjFa9zlPUmE=.331f7df8-83b9-4e48-8908-7d8dbd5821ec@github.com>
References: <Qgv51p9m_Qj9-1EW_Ehh75Fgij7jOA-PFeEAW1Xndls=.18de61e9-f15a-44f4-9b43-05284b4c82df@github.com>
 <RRNfk9NT_tl6349o6oAPM3W9Yo9CAt4FSjFa9zlPUmE=.331f7df8-83b9-4e48-8908-7d8dbd5821ec@github.com>
Message-ID: <fu0aGEtYj-knqSAOOZxW0Jn-H2qiBuTX_Et4UMoF_wY=.f9213fc0-139c-43c6-b31a-382315744a8d@github.com>

On Fri, 28 Apr 2023 15:35:00 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> Weibing Xiao has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   modify bug id
>
> test/langtools/jdk/jshell/UndefinedClassTest.java line 26:
> 
>> 24: /**
>> 25:  * @test
>> 26:  * @bug 8305714
> 
> 8292755 would be the bug ID here since it refers to the product bug. 
> 
> Is there a reason why you couldn't fold this test into the test/langtools/jdk/jshell/ClassesTest.java test ?

Updated the bug ID.

Assuming ClassesTest is to verify the definition of Class.

With this patch, I can catch the following error message described in the attached file in JShell Console. 
![image](https://user-images.githubusercontent.com/66648564/235197717-bcc8e314-e7f3-4fa3-8431-95335717ab89.png)


Without the patch of 8292755 for JDK17,  JShell will crash with this test case. After applying this patch in JDK17U, JShell console will print something like below, 

Exception in thread "main" java.lang.InternalError: Exception during analyze - java.lang.AssertionError: isSubtype UNKNOWN
at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.analyze(TaskFactory.java:415)
at jdk.jshell/jdk.jshell.TaskFactory$AnalyzeTask.<init>(TaskFactory.java:406)
at jdk.jshell/jdk.jshell.TaskFactory.lambda$analyze$1(TaskFactory.java:178)
at jdk.jshell/jdk.jshell.TaskFactory.lambda$runTask$4(TaskFactory.java:213)
at jdk.compiler/com.sun.tools.javac.api.JavacTaskPool.getTask(JavacTaskPool.java:193)
at jdk.jshell/jdk.jshell.TaskFactory.runTask(TaskFactory.java:206)
at jdk.jshell/jdk.jshell.TaskFactory.analyze(TaskFactory.java:175)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13719#discussion_r1180586234

From abimpoudis at openjdk.org  Fri Apr 28 17:09:53 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Fri, 28 Apr 2023 17:09:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v3]
In-Reply-To: <vSJfM09xs14nK5muLU-PaU_IaqRC-lBG-28sloepzR8=.08ed221c-c341-496d-b51b-9c946b039b00@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>
 <xWlwJC92eItl_tCdvGbJG3Vv2znQBdbuK-pXipEcdvk=.ee1c5769-bc0c-411e-977f-50df182977a8@github.com>
 <vSJfM09xs14nK5muLU-PaU_IaqRC-lBG-28sloepzR8=.08ed221c-c341-496d-b51b-9c946b039b00@github.com>
Message-ID: <dUgdLcPqklkLSfF1Kdv5KSu4L_nc-g8hoh1SOGJ5M9Q=.7a9ab665-b362-40c9-9781-a0b8b6b521a6@github.com>

On Fri, 28 Apr 2023 09:17:29 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/code/Flags.java line 278:
>> 
>>> 276: 
>>> 277:     /**
>>> 278:      * Flag that indicates that a local variable, a lambda parameter, or an unnamed pattern variable is unnamed.
>> 
>> question: cant we infer this from the name itself instead of consuming a flag?
>
> I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-)

Initially, the check was based on the name but that became confusing since the symbol may hold either the empty name or the underscore (coming from the tree) depending on whether we are in the new feature or not. The reason is that while the Tree API will continue to return (`_`), `VariableElement.getSimpleName()` needs to return `names.empty` ([JDK-8307007](https://bugs.openjdk.org/browse/JDK-8307007)).

Up until here, everything is ok, however adding the `isUnnamed` in the Symbol we cannot simply return a boolean based on simply checking the name. We would need to check the version again but this time in the Symbol (to take account whether or not we are in the Unnamed feature). 

Thus the flag seems cleaner. WDYT?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180629713

From mcimadamore at openjdk.org  Fri Apr 28 23:17:53 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 28 Apr 2023 23:17:53 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v3]
In-Reply-To: <dUgdLcPqklkLSfF1Kdv5KSu4L_nc-g8hoh1SOGJ5M9Q=.7a9ab665-b362-40c9-9781-a0b8b6b521a6@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
 <ewx7hVRkPDFBnFXe5OZlkBwjyweT2HdSbcJQwnDU05s=.18d49975-f51a-4f89-8c45-0dc5863ad852@github.com>
 <xWlwJC92eItl_tCdvGbJG3Vv2znQBdbuK-pXipEcdvk=.ee1c5769-bc0c-411e-977f-50df182977a8@github.com>
 <vSJfM09xs14nK5muLU-PaU_IaqRC-lBG-28sloepzR8=.08ed221c-c341-496d-b51b-9c946b039b00@github.com>
 <dUgdLcPqklkLSfF1Kdv5KSu4L_nc-g8hoh1SOGJ5M9Q=.7a9ab665-b362-40c9-9781-a0b8b6b521a6@github.com>
Message-ID: <iuFDNO7L-b3YTSzkgpyGT6IxekB4juXTIfmcMG6dLZk=.f1be08f2-0a53-429a-bc04-2bffaa3b14d4@github.com>

On Fri, 28 Apr 2023 16:56:34 GMT, Aggelos Biboudis <abimpoudis at openjdk.org> wrote:

>> I have the same feeling. Flags are a scarce resource - if we can avoid using one that would be best :-)
>
> Initially, the check was based on the name but that became confusing since the symbol may hold either the empty name or the underscore (coming from the tree) depending on whether we are in the new feature or not. The reason is that while the Tree API will continue to return (`_`), `VariableElement.getSimpleName()` needs to return `names.empty` ([JDK-8307007](https://bugs.openjdk.org/browse/JDK-8307007)).
> 
> Up until here, everything is ok, however adding the `isUnnamed` in the Symbol we cannot simply return a boolean based on simply checking the name. We would need to check the version again but this time in the Symbol (to take account whether or not we are in the Unnamed feature). 
> 
> Thus the flag seems cleaner. WDYT?

I guess what I'm kind of questioning is: why are we using `_` for the variable name?  The way I see it is that `_` is a token that is used to say "I don't want to specify a name". So the program element declared using `_` becomes effectively "unnamed" (as the JEP says). This would be consistent with looking for `_` in the parser, and then replace them with `names.empty` - which would then be consistent with the rest of the compiler (as you wouldn't need to filter out things). Or, is there a concrete use case where keeping the `_` around is useful?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13528#discussion_r1180870835

From abimpoudis at openjdk.org  Sat Apr 29 08:05:24 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 29 Apr 2023 08:05:24 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v6]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <H7x3xA7h4LOsKvxGoT92bnhjxnVD9Aq4BMVFvhRRSWY=.942fa687-b9f7-48cd-abf2-c02e05ae9363@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request incrementally with one additional commit since the last revision:

  Address comments around javax.lang

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13528/files
  - new: https://git.openjdk.org/jdk/pull/13528/files/59910b94..e95e4166

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

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

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

From abimpoudis at openjdk.org  Sat Apr 29 08:15:55 2023
From: abimpoudis at openjdk.org (Aggelos Biboudis)
Date: Sat, 29 Apr 2023 08:15:55 GMT
Subject: RFR: 8302344: Compiler Implementation for Unnamed patterns and
 variables (Preview) [v7]
In-Reply-To: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
References: <qXNMVhHFyI4YjN51Pj6BLmkkSEZmH0jCY_4uEcrBJh8=.bf2a9a28-7796-41fe-9899-5efcf36b2a9c@github.com>
Message-ID: <H2hS6vU2wjCyTcax2xd8i9ww3eUOIcSDfyh5OPk-EVQ=.65926d01-2375-4562-a759-c2723ae32abb@github.com>

> This PR implements [JEP 443](https://openjdk.org/jeps/443), the preview feature for Unnamed Patterns and Variables in Java.
> 
> Draft Spec: https://cr.openjdk.org/~abimpoudis/unnamed/latest/

Aggelos Biboudis has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits:

 - Merge branch 'JDK-8300543' into unnamed
 - Address comments around javax.lang
 - Fix field error detection
 - Update test files with JDK 8307007 bug id
 - Address javax.lang.model comments
 - Introduce new flag to track unnamed variables
   
   - Return underscore for Tree API and empty name for javax.lang.model.element.VariableElement.getSimpleName()
 - Fix indentation in JavacParser
 - Merge branch 'JDK-8300543' into unnamed
 - Fix top level type pattern with underscore
 - Introduce source in MemberEnter (javadoc uses MemberEnter)
 - ... and 20 more: https://git.openjdk.org/jdk/compare/3b3bcbcc...e39dd6dd

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

Changes: https://git.openjdk.org/jdk/pull/13528/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13528&range=06
  Stats: 1132 lines in 44 files changed: 945 ins; 60 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/13528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13528/head:pull/13528

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