From jlahoda at openjdk.org  Thu Mar  2 08:31:27 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 2 Mar 2023 08:31:27 GMT
Subject: Integrated: 8297587: Upgrade JLine to 3.22.0
In-Reply-To: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
References: <Y2xdMkQ3uIpXOWBKdAlVyEiGEmDF4YsAWqV0Tf_dp9A=.200485d2-cc87-41bf-86dc-ad85c25d4f0e@github.com>
Message-ID: <YGBdCITUfPiTyxIYfMtTIZQ9EL4L_ZOo-3cZgUUkOvY=.dd96f07d-b1a7-4252-bb4f-38254a88f861@github.com>

On Fri, 17 Feb 2023 10:20:46 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a proposal to upgrade the JLine inside JDK to 3.22.0. It was done by:
> -for shared/classes, taking a diff between JLine 3.20.0 and the existing JDK version, copying the JLine 3.22.0 into the JDK, repackaing, re-appling the patch (including trailing space removal, UTF-8 characters replacement, addition of inputStreamWrapper), and adjusting TerminalProvider
> -for Windows, mostly copying the JLine 3.22.0 code into the JDK, and adjusting based on old changes

This pull request has now been integrated.

Changeset: 4619e8ba
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4619e8bae838abd1f243c2c65a538806d226b8e8
Stats:     1763 lines in 54 files changed: 1055 ins; 452 del; 256 mod

8297587: Upgrade JLine to 3.22.0

Reviewed-by: vromero

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

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

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

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

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

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

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

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

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

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

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

Alex

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

Correct and thank you. 

?

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

From duke at openjdk.org  Fri Mar  3 19:00:29 2023
From: duke at openjdk.org (duke)
Date: Fri, 3 Mar 2023 19:00:29 GMT
Subject: Withdrawn: 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: <DP1FRb_9YckiOxedMLVcVVUBihdV11mLWUFCdruCPZU=.20185306-2f3d-4ac6-b916-1c90f8c84617@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 been closed without being integrated.

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

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

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

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

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

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

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

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

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

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

Split into two sentences.

Suggestion:

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

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

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

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

     * supplied {@link StringTemplate} object.

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

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

Suggestion:

 * embedded expression that immediately follows, without whitespace, the

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

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

Suggestion:

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

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

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

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

Suggestion:

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

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

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

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

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

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

Suggestion:

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

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

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

Suggestion:

     *          specifier is incompatible with the given arguments,

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

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

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

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

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

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

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

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

Suggestion:

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

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

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

Suggestion:

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

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

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

From duke at openjdk.org  Mon Mar  6 02:45:00 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Mar 2023 02:45:00 GMT
Subject: RFR: 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java
 fail with -Xcomp
Message-ID: <NdskZRNlq86qQ5MIlxr3IXb8T5znS8W3uJ_d8tUvtPM=.9f10c8aa-8ec4-4c9e-aa87-ce4fe5e05408@github.com>

This tests failed with VM_OPTIONS=-Xcomp and CONF=fastdebug on the LOONGARCH64 architecture because JdiExecutionControlProvider`s timeout.
jdk/jshell/JdiFailingLaunchExecutionControlTest.java
jdk/jshell/JdiFailingListenExecutionControlTest.java

This PR fix the issue, Please help review it.

Thanks.

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

Commit messages:
 - 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java fail with -Xcomp

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

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

From duke at openjdk.org  Mon Mar  6 08:56:05 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Mon, 6 Mar 2023 08:56:05 GMT
Subject: RFR: 8303625: jdk/jshell/JdiFailingLaunchExecutionControlTest.java
 fail with -Xcomp
In-Reply-To: <NdskZRNlq86qQ5MIlxr3IXb8T5znS8W3uJ_d8tUvtPM=.9f10c8aa-8ec4-4c9e-aa87-ce4fe5e05408@github.com>
References: <NdskZRNlq86qQ5MIlxr3IXb8T5znS8W3uJ_d8tUvtPM=.9f10c8aa-8ec4-4c9e-aa87-ce4fe5e05408@github.com>
Message-ID: <nmO3RTTQum3eoK01jRTAxwZMEMVQiZY64YM--fhkvOA=.1c09efdf-adbb-4697-9eb3-20de6ea263c9@github.com>

On Mon, 6 Mar 2023 02:38:19 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> This tests failed with VM_OPTIONS=-Xcomp and CONF=fastdebug on the LOONGARCH64 architecture because JdiExecutionControlProvider`s timeout.
> jdk/jshell/JdiFailingLaunchExecutionControlTest.java
> jdk/jshell/JdiFailingListenExecutionControlTest.java
> 
> This PR fix the issue, Please help review it.
> 
> Thanks.

GHA test/hotspot/jtreg/compiler/vectorization/runner/LoopRangeStrideTest.java failure is not related to this patch.

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

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

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

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

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

Changing.

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

Changing

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

Changing

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

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

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

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

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

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

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

Changing

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

Changing

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

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

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

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

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

Changing

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

Changing

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

Changing

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

Changing

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

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

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

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

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

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

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

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

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

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

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

> Adding support for MarkDown javadoc in the JShell

This pull request has been closed without being integrated.

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

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

From asotona at openjdk.org  Thu Mar  9 17:41:26 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 9 Mar 2023 17:41:26 GMT
Subject: RFR: 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl
 uses ASM to instrument classes
Message-ID: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>

8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
This patch converts it to use Classfile API.

Please review.
Thanks,
Adam

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

Commit messages:
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'JDK-8294982' into JDK-8294974
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
 - Merge branch 'master' into JDK-8294982
 - fixed new lines at end of file
 - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant
 - fixed CodeRelabeler javadoc
 - ... and 182 more: https://git.openjdk.org/jdk/compare/cdcf5c1e...cfcfb077

Changes: https://git.openjdk.org/jdk/pull/11413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8294974
  Stats: 54 lines in 2 files changed: 11 ins; 21 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413

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

From asotona at openjdk.org  Fri Mar 10 08:51:45 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 08:51:45 GMT
Subject: RFR: 8294974: jdk.jshell
 jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v2]
In-Reply-To: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
Message-ID: <gisjl6SqgRZnQ-BBtMPMkjn9SGurDwcvVuCeHZ1f6Do=.cd4b6146-84a4-4bb6-835b-77f769db1e4e@github.com>

> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

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

 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'JDK-8294982' into JDK-8294974
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
 - Merge branch 'master' into JDK-8294982
 - fixed new lines at end of file
 - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant
 - ... and 183 more: https://git.openjdk.org/jdk/compare/e26cc526...f9fb8998

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

Changes: https://git.openjdk.org/jdk/pull/11413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=01
  Stats: 54 lines in 2 files changed: 11 ins; 21 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413

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

From asotona at openjdk.org  Fri Mar 10 12:35:31 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 12:35:31 GMT
Subject: RFR: 8294974: jdk.jshell
 jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v3]
In-Reply-To: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
Message-ID: <aLfxnLoqcFkQJeUwpwCtuJ_KrxCLpzgR5u9va5nJB_Y=.61ddb39b-2266-4e55-b3b1-48315b5c7972@github.com>

> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

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

 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'JDK-8294982' into JDK-8294974
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
 - Merge branch 'master' into JDK-8294982
 - fixed new lines at end of file
 - ... and 184 more: https://git.openjdk.org/jdk/compare/b1d89f30...070be0a8

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

Changes: https://git.openjdk.org/jdk/pull/11413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=02
  Stats: 55 lines in 2 files changed: 11 ins; 22 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/11413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413

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

From jlahoda at openjdk.org  Fri Mar 10 13:01:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 Mar 2023 13:01:19 GMT
Subject: RFR: 8294974: jdk.jshell
 jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v3]
In-Reply-To: <aLfxnLoqcFkQJeUwpwCtuJ_KrxCLpzgR5u9va5nJB_Y=.61ddb39b-2266-4e55-b3b1-48315b5c7972@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
 <aLfxnLoqcFkQJeUwpwCtuJ_KrxCLpzgR5u9va5nJB_Y=.61ddb39b-2266-4e55-b3b1-48315b5c7972@github.com>
Message-ID: <O7BSvyOVQSQcPVkDBS6nmsFK7FD8axc52W-rYoaMSb4=.f868ee0d-4f42-4c9b-9b2f-f498c305200a@github.com>

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

>> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
>> This patch converts it to use Classfile API.
>> 
>> Please review.
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 194 commits:
> 
>  - Merge branch 'master' into JDK-8294974-jshell
>  - Merge branch 'master' into JDK-8294974-jshell
>  - Merge branch 'master' into JDK-8294974-jshell
>  - Merge branch 'JDK-8294982' into JDK-8294974
>  - removed obsolete javadoc from implementation classes
>  - minor fix in CodeBuilder and added test cases to LDCTest
>  - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
>  - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
>  - Merge branch 'master' into JDK-8294982
>  - fixed new lines at end of file
>  - ... and 184 more: https://git.openjdk.org/jdk/compare/b1d89f30...070be0a8

Looks good to me, with a nit in java.base's module-info.

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

> 382:     exports sun.util.resources to
> 383:         jdk.localedata;
> 384: 

Nit: I'd suggest to preserve the empty line (since there's no other change near).

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

Marked as reviewed by jlahoda (Reviewer).

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

From asotona at openjdk.org  Fri Mar 10 13:09:09 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 13:09:09 GMT
Subject: RFR: 8294974: jdk.jshell
 jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v4]
In-Reply-To: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
Message-ID: <6LaKFBr-SCYJpC1Zc0r_zjPCdZjrxd95BL4PuOM2keI=.c1ea387d-e654-435a-9b8d-dfd380d803aa@github.com>

> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

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

  fixed empty line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11413/files
  - new: https://git.openjdk.org/jdk/pull/11413/files/070be0a8..f5ce307e

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

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

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

From asotona at openjdk.org  Fri Mar 10 13:09:12 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 10 Mar 2023 13:09:12 GMT
Subject: RFR: 8294974: jdk.jshell
 jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes [v2]
In-Reply-To: <O7BSvyOVQSQcPVkDBS6nmsFK7FD8axc52W-rYoaMSb4=.f868ee0d-4f42-4c9b-9b2f-f498c305200a@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
 <aLfxnLoqcFkQJeUwpwCtuJ_KrxCLpzgR5u9va5nJB_Y=.61ddb39b-2266-4e55-b3b1-48315b5c7972@github.com>
 <O7BSvyOVQSQcPVkDBS6nmsFK7FD8axc52W-rYoaMSb4=.f868ee0d-4f42-4c9b-9b2f-f498c305200a@github.com>
Message-ID: <JKIqhL2pUJ6itrKFuye9RCclWdZ8A3TeJFKNvZoI9TE=.2c790fa2-087e-482c-b28b-62ff0d812d70@github.com>

On Fri, 10 Mar 2023 12:58:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 193 commits:
>> 
>>  - Merge branch 'master' into JDK-8294974-jshell
>>  - Merge branch 'master' into JDK-8294974-jshell
>>  - Merge branch 'JDK-8294982' into JDK-8294974
>>  - removed obsolete javadoc from implementation classes
>>  - minor fix in CodeBuilder and added test cases to LDCTest
>>  - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
>>  - fixed CodeBuilder:constantInstruction for -0.0d and -0.0f values and added test
>>  - Merge branch 'master' into JDK-8294982
>>  - fixed new lines at end of file
>>  - package jdk.internal.classfile.jdktypes moved to jdk.internal.classfile.java.lang.constant
>>  - ... and 183 more: https://git.openjdk.org/jdk/compare/e26cc526...f9fb8998
>
> src/java.base/share/classes/module-info.java line 384:
> 
>> 382:         jdk.jshell;
>> 383:     exports jdk.internal.classfile.instruction to
>> 384:         jdk.jshell;
> 
> Nit: I'd suggest to preserve the empty line (since there's no other change near).

fixed, thanks.

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

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

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

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

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

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

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

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

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

From jlahoda at openjdk.org  Fri Mar 10 20:08:30 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 10 Mar 2023 20:08:30 GMT
Subject: RFR: 8299934: LocalExecutionControl replaces default uncaught
 exception handler
Message-ID: <mP7SjLQS9NvZJq2KVoD_VrW2lNi3CHBANSmc4RRWmH0=.f4ae105e-b3a1-4b2e-b547-dde595b3d206@github.com>

The JShell's `LocalExecutionControl` set the global default uncaught exception handler, causing problems to external code that might rely on it (even if only for logging/debugging purposes).

The proposal here is to do what the bug is suggesting, and only handling the exception inside the `ThreadGroup` that JShell creates. The patch does not strive to do further changes to how the exception handling is done.

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

Commit messages:
 - 8299934: LocalExecutionControl replaces default uncaught exception handler

Changes: https://git.openjdk.org/jdk/pull/12982/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12982&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8299934
  Stats: 179 lines in 2 files changed: 165 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/12982.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/12982/head:pull/12982

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

From asotona at openjdk.org  Mon Mar 13 11:10:32 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Mar 2023 11:10:32 GMT
Subject: RFR: 8294974: Convert
 jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API
 to instrument classes [v5]
In-Reply-To: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
Message-ID: <EzA-lRf_HXY-B44bkTjGPPEq5sl6eWfNg-SF7CNmd9o=.b10532c7-d437-4320-a4c6-a14b405e164d@github.com>

> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

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

 - increased jtreg maxOutputSize for Classfile API tests
 - Merge branch 'master' into JDK-8294974
   
   # Conflicts:
   #	src/java.base/share/classes/module-info.java
 - fixed empty line
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'master' into JDK-8294974-jshell
 - Merge branch 'JDK-8294982' into JDK-8294974
 - removed obsolete javadoc from implementation classes
 - minor fix in CodeBuilder and added test cases to LDCTest
 - EntryMap::nextPowerOfTwo delegates to Long:numberOfLeadingZeros
 - ... and 187 more: https://git.openjdk.org/jdk/compare/25e7ac22...9ddfefb0

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

Changes: https://git.openjdk.org/jdk/pull/11413/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=11413&range=04
  Stats: 55 lines in 3 files changed: 11 ins; 21 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/11413.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11413/head:pull/11413

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

From asotona at openjdk.org  Mon Mar 13 15:56:36 2023
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 13 Mar 2023 15:56:36 GMT
Subject: Integrated: 8294974: Convert
 jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API
 to instrument classes
In-Reply-To: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
References: <v4V6ulOZx2Ecb1g8HgXMPve4zKZZ14TG353LBNZSsOQ=.8563fb93-4cd3-486e-95ab-ad12f3f4f9d6@github.com>
Message-ID: <Z20Pf4NjPW5wlIMVBhwt30LnXNWPGGbeWLkpSNUjM5A=.9ec2710e-b3d9-4411-be06-fc33fddaa370@github.com>

On Tue, 29 Nov 2022 12:27:15 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> 8294974: jdk.jshell jdk.jshell.execution.LocalExecutionControl uses ASM to instrument classes
> This patch converts it to use Classfile API.
> 
> Please review.
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: a95bc7ac
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a95bc7acd091b287af02485434e1e55ba1e0369d
Stats:     55 lines in 3 files changed: 11 ins; 21 del; 23 mod

8294974: Convert jdk.jshell/jdk.jshell.execution.LocalExecutionControl to use the Classfile API to instrument classes

Reviewed-by: jlahoda

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

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

From jlu at openjdk.org  Wed Mar 15 16:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:03 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8 native
Message-ID: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>

This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.

In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

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

Commit messages:
 - Write to ASCII
 - Read in .properties as UTF-8, but write to LRB .java as ISO-8859-1
 - Compile class with ascii (Not ready to make system wide change)
 - Toggle UTF-8 for javac option in JavaCompilation.gmk
 - CompileProperties converts in UTF-8
 - Convert .properties from ISO-8859-1 to UTF-8

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

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

From jjg at openjdk.org  Wed Mar 15 16:08:06 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 15 Mar 2023 16:08:06 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

make/langtools/tools/compileproperties/CompileProperties.java line 252:

> 250:             try {
> 251:                 writer = new BufferedWriter(
> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));

Using ISO_8859_1 seems strange.
Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.

Or else just stay with ascii; no one should be looking at these files!

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

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

From jlu at openjdk.org  Wed Mar 15 16:08:07 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 15 Mar 2023 16:08:07 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <q2pKX-KywWQZs0Dt6LlnQAKfePfoFNyVcUum4-nkNA4=.d4a102fa-4edf-4c1b-b0bc-959d08fc2276@github.com>
Message-ID: <_dP9N3UNWa82tfLVEapoSFJjbvMmlyP21ZbuL0NjTDU=.3685af0b-31a0-42aa-86b0-5098bda72766@github.com>

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

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> make/langtools/tools/compileproperties/CompileProperties.java line 252:
> 
>> 250:             try {
>> 251:                 writer = new BufferedWriter(
>> 252:                         new OutputStreamWriter(new FileOutputStream(outputPath), StandardCharsets.ISO_8859_1));
> 
> Using ISO_8859_1 seems strange.
> Since these are generated files, you could write them as UTF-8 and then override the default javac option for ascii when compiling _just_ these files.
> 
> Or else just stay with ascii; no one should be looking at these files!

Will stick with your latter solution, as since the .properties files were converted via native2ascii, it makes sense to write out via ascii.

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

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

From duke at openjdk.org  Wed Mar 15 16:21:33 2023
From: duke at openjdk.org (Archie L. Cobbs)
Date: Wed, 15 Mar 2023 16:21:33 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:

> 1: #

This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

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

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

From naoto at openjdk.org  Wed Mar 15 20:23:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Mar 2023 20:23:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>

On Thu, 23 Feb 2023 09:04:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:

> 154: zh=\u00A4
> 155: zh_CN=\uFFE5
> 156: zh_HK=HK$

Why are they not encoded into UTF-8 native?

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

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

From jlahoda at openjdk.org  Thu Mar 16 07:28:21 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 16 Mar 2023 07:28:21 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v2]
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: <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@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 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/b71e3113...d58e53f1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11695/files
  - new: https://git.openjdk.org/jdk/pull/11695/files/5cc0831f..d58e53f1

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

  Stats: 328327 lines in 4885 files changed: 161065 ins; 120883 del; 46379 mod
  Patch: https://git.openjdk.org/jdk/pull/11695.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/11695/head:pull/11695

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

From jlaskey at openjdk.org  Thu Mar 16 12:07:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 16 Mar 2023 12:07:57 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v45]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <sh500oB5itOA9tw-xJ8Nc8TwUJevtYbTjkieBnPeaLs=.744931f5-a5a6-4dfb-ba37-77f613ac1d24@github.com>

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

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

 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Javadoc corrections and bug fix for StringTemplate::combine
 - Tighten up reporting of string template errors (fewer messages)
 - Merge branch 'master' into 8285932
 - Merge branch 'master' into 8285932
 - Minor correction to javadoc
 - Merge branch 'master' into 8285932
 - ... and 52 more: https://git.openjdk.org/jdk/compare/7277bb19...d6947fd4

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

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

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

From jlu at openjdk.org  Thu Mar 16 18:19:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:19:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with four additional commits since the last revision:

 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/1e798f24..6d6bffe8

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

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

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

From jlu at openjdk.org  Thu Mar 16 18:21:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:40 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <Zr4PH4KO0vVw0K9EKOIguvzwn2WoGKRkoABy1RYKVRk=.59f6fe50-091d-4855-9988-b2a79c586905@github.com>
Message-ID: <CRTgRmg-NKyRb1XyeIcUdbz-JgoZE9nUJ6hBHsRIvLk=.c4614e2d-ec44-40fa-a88d-41c2b94b12bb@github.com>

On Thu, 16 Mar 2023 18:19:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

Conversion did not work as expected, addressing right now.

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

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

From jlu at openjdk.org  Thu Mar 16 18:21:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:43 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <jOze8zywvSR9833Z66uHlKXAp1jqXT_XETIRjsRluQQ=.e091bc8b-8f1a-4d81-ac36-a9218f01444d@github.com>
Message-ID: <Pns4G-crmY2QuscU_BkwBA2hXFMN3VQMdzc-UWVKPDU=.d20ab56a-ca0f-45aa-9a2d-361b532281ed@github.com>

On Wed, 15 Mar 2023 20:19:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 156:
> 
>> 154: zh=\u00A4
>> 155: zh_CN=\uFFE5
>> 156: zh_HK=HK$
> 
> Why are they not encoded into UTF-8 native?

Not sure, thank you for catching it. Working on it right now.

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

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

From jlu at openjdk.org  Thu Mar 16 18:21:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:21:46 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v2]
In-Reply-To: <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <1I9v8d2OiyLfQVCozGYVRhAi3AotqGuRUhsNj0VCsUk=.e673ca33-d24f-4aab-908e-a5c0bfa3bf7c@github.com>
Message-ID: <_6WBGo5CQBseDEjMv16qCWmodFlYOO4gsT9WbON7ddA=.f94339a4-8893-47e4-8bb1-f28a8807ad9d@github.com>

On Wed, 15 Mar 2023 16:18:44 GMT, Archie L. Cobbs <duke at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Bug6204853 should not be converted
>>  - Copyright year for CompileProperties
>>  - Redo translation for CS.properties
>>  - Spot convert CurrencySymbols.properties
>
> test/jdk/java/util/ResourceBundle/Bug6204853.properties line 1:
> 
>> 1: #
> 
> This file should probably be excluded because it's used in a test that relates to UTF-8 encoding (or not) of property files.

Thank you, removed the changes for this file

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

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

From jlu at openjdk.org  Thu Mar 16 18:35:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:51 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/6d6bffe8..7119830b

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

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

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

From jlu at openjdk.org  Thu Mar 16 18:35:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 16 Mar 2023 18:35:54 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v3]
In-Reply-To: <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <a41nIhmfHdPsaBc-z7QgeougsL4rI1ua8CKB7hkyQYg=.e454b5ce-cfca-4cad-851e-3823819d5b39@github.com>
Message-ID: <XFZBHgkji9zthsA9wOP-bDqbf7PTVoKJzNXHDR1pThQ=.a99810cd-d764-40ee-9699-b234d6583007@github.com>

On Thu, 16 Mar 2023 18:31:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties

test/jdk/java/text/Format/NumberFormat/CurrencySymbols.properties line 1:

> 1: #

CurrencySymbols.properties is fully converted to UTF-8 now

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

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

From vromero at openjdk.org  Thu Mar 16 21:12:53 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 16 Mar 2023 21:12:53 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v2]
In-Reply-To: <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
 <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@github.com>
Message-ID: <boZs4eWZdWJ6HFE2Nvwj0KXDTGRt452vslHIpdHqqoU=.4ff90dea-78f8-4387-bce0-1077441f3840@github.com>

On Thu, 16 Mar 2023 07:28:21 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
>
> 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/f93704f2...d58e53f1

looks sensible

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

Marked as reviewed by vromero (Reviewer).

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

From jlu at openjdk.org  Fri Mar 17 20:28:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 20:28:13 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Adjust CF test to read in with UTF-8 to fix failing test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/7119830b..007c78a7

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

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

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

From angorya at openjdk.org  Fri Mar 17 20:34:00 2023
From: angorya at openjdk.org (Andy Goryachev)
Date: Fri, 17 Mar 2023 20:34:00 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:

> 224:         Properties p = new Properties();
> 225:         try {
> 226:             FileInputStream input = new FileInputStream(propertiesPath);

Should this stream be closed in a finally { } block?

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

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

From naoto at openjdk.org  Fri Mar 17 21:05:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Mar 2023 21:05:18 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <-3wtWK_Pdt1fqDnSjbS6JTGLwboJi7Tw2sV0v7LQ3Os=.7036d0b0-2524-43bc-a82d-640f29fd35a0@github.com>
Message-ID: <qJO-EntPnPd5u6rdRknlaAFlfED0JHmr5CXahe0N4oY=.fae98578-e8b4-4387-bd72-acf3cf871a40@github.com>

On Fri, 17 Mar 2023 20:31:27 GMT, Andy Goryachev <angorya at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 226:
> 
>> 224:         Properties p = new Properties();
>> 225:         try {
>> 226:             FileInputStream input = new FileInputStream(propertiesPath);
> 
> Should this stream be closed in a finally { } block?

or better be `try-with-resources`?

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

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

From weijun at openjdk.org  Fri Mar 17 21:52:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:52:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
Message-ID: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>

On Fri, 17 Mar 2023 20:28:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Adjust CF test to read in with UTF-8 to fix failing test

make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:

> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
> 326:                         outBuffer.append(toHex(aChar & 0xF));

Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

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

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

From weijun at openjdk.org  Fri Mar 17 21:56:23 2023
From: weijun at openjdk.org (Weijun Wang)
Date: Fri, 17 Mar 2023 21:56:23 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v4]
In-Reply-To: <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <ycrcMknRc5J23KTl_6lvtYdOD13f13thYjexpcMoagM=.02ba3ca8-655a-41ae-b99b-b92d0893fafd@github.com>
 <1JBZe7nrM-HsVEItfK-3GPeXoX_glyM9SL4ZACUbLwk=.3a3cf62b-0960-4b03-80aa-2756bd1636dc@github.com>
Message-ID: <whhHbwzCZGIvBavtXFqc5Ari9SWIQg-BwdyP3t89Rcg=.d8dc3f56-857d-4265-a54d-9fdb5a59c96a@github.com>

On Fri, 17 Mar 2023 21:49:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Adjust CF test to read in with UTF-8 to fix failing test
>
> make/jdk/src/classes/build/tools/compileproperties/CompileProperties.java line 326:
> 
>> 324:                         outBuffer.append(toHex((aChar >> 8) & 0xF));
>> 325:                         outBuffer.append(toHex((aChar >> 4) & 0xF));
>> 326:                         outBuffer.append(toHex(aChar & 0xF));
> 
> Sorry I don't know when this tool is called, but why is it still writing in `\unnnn` style?

I probably understand it now, source code still needs escaping. When can we put in UTF-8 there as well?

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

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

From jlu at openjdk.org  Fri Mar 17 22:27:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Mar 2023 22:27:48 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  Close streams when finished loading into props

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12726/files
  - new: https://git.openjdk.org/jdk/pull/12726/files/007c78a7..19b91e6b

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

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

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

From jlahoda at openjdk.org  Mon Mar 20 12:17:19 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 20 Mar 2023 12:17:19 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test
Message-ID: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>

If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.

The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

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

Commit messages:
 - 8304498: JShell does not switch to raw mode when there is no /bin/test

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

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

From alanb at openjdk.org  Mon Mar 20 13:29:21 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 20 Mar 2023 13:29:21 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test
In-Reply-To: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
Message-ID: <-WMZa6Pk0lidOnX1xJzmEkRu-GsoPzSS0fyya5dz4to=.8a4fd091-0019-4702-b787-e233af5368bb@github.com>

On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

As a general point, we probably need to change jline to not create sub-processes. If we needs to introspect the environment then it will need to do it in the current VM.

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

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

From jlaskey at openjdk.org  Mon Mar 20 20:31:46 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 20 Mar 2023 20:31:46 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>

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

Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:

 - Tidy javadoc
 - Rename StringTemplate classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/d6947fd4..9ba6400d

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

  Stats: 2086 lines in 54 files changed: 874 ins; 1075 del; 137 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From aturbanov at openjdk.org  Tue Mar 21 08:58:54 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 21 Mar 2023 08:58:54 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v2]
In-Reply-To: <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@github.com>
References: <K_stdNZsrI_lTOanZjEzeJqrNYQs2kZ2TIzGe9Z1fGw=.f1a5d91d-2b27-4dc6-8fe8-c9287745361d@github.com>
 <lAoEwLJdsEpUfAbgvq3rPdRwSnNoDZqOB-DArb2GwzM=.95495bfe-aca9-4ea0-9128-38ea794c0f48@github.com>
Message-ID: <A4LwKXqsKg0IAW-5SyAryndaR1bMiRk5_7sc7zyH0XE=.e369b8a2-2b43-462f-8d72-c45b37869c6d@github.com>

On Thu, 16 Mar 2023 07:28:21 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
>
> 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/1140c946...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) {

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

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

From jlahoda at openjdk.org  Tue Mar 21 10:15:33 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Mar 2023 10:15:33 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v3]
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: <0i3747-V83ZCV1uPgFHus4TRI9vMx2hOiYnOEtgG8o4=.091d7063-3143-4284-b637-b1b7a4b142b5@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:

  Changing ExecutionEnv.console() to Optional, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/11695/files
  - new: https://git.openjdk.org/jdk/pull/11695/files/d58e53f1..cc9c6f74

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

  Stats: 18 lines in 3 files changed: 7 ins; 0 del; 11 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  Tue Mar 21 10:25:38 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 21 Mar 2023 10:25:38 GMT
Subject: RFR: 8296454: System.console() shouldn't return null in jshell
 [v4]
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: <gFQ4RDQabbtVrp2QyKkOS_L-31GxeZHmtTEg7urP57M=.e08767f4-9724-4c4c-b5d8-6d17b3d718a5@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:

  Update src/jdk.jshell/share/classes/jdk/jshell/execution/impl/ConsoleImpl.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

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

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

  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 mcimadamore at openjdk.org  Tue Mar 21 14:55:32 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

I like the new naming scheme!

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

> 26: package java.lang;
> 27: 
> 28: import java.lang.Object;

You might want to do another pass to check for unused imports

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

> 42:  * {@link StringTemplate} is the run-time representation of a string template or
> 43:  * text block template in a template expression.
> 44:  *

Extra newline?

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

> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
> 56:  * first produces an instance of {@link StringTemplate}, representing the template

The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

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

> 67:  * List<Object> values = st.values();
> 68:  * }
> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},

This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

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

> 322:      * assert Objects.equals(sc, "abcxyz");
> 323:      * }
> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first

I was playing with this example in jshell:

jshell> var st1 = RAW."{1}"
st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }

jshell> var st2 = RAW."{2}"
st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }

jshell> StringTemplate.combine(st1, st2);
$7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }


The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:

Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next

I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

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

> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
> 430:      */
> 431:     static final StringProcessor STR = StringTemplate::interpolate;

`static final` is redundant here (we are in an interface)

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

> 452:      * This interface describes the methods provided by a generalized string template processor. The
> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.

nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

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

> 45:  */
> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 47: interface ReferenceKey<T> {

This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:

> 224:                         List.nil(), expressions);
> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,

nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:

> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
> 251:             }
> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,

What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:

> 279:             make.at(tree.pos);
> 280: 
> 281:             if (processor == null || isNamedProcessor(names.RAW)) {

is `processor == null` still a thing?

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1350457321
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143370713
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143371242
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143373826
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143379210
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143441733
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143444292
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143448931
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143484050
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143501675
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143507003
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1143487363

From mcimadamore at openjdk.org  Tue Mar 21 14:55:33 2023
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Mar 2023 14:55:33 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>

On Tue, 21 Mar 2023 13:31:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
> 
>> 67:  * List<Object> values = st.values();
>> 68:  * }
>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
> 
> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.

The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

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

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

From jlaskey at openjdk.org  Wed Mar 22 14:43:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
Message-ID: <juvO66YNEB-H7csE6Nz1LSPCTeCs9MfH2t6ICg9FDJs=.7b639e70-729e-4ce2-8d1b-54e2e1d98aa3@github.com>

On Tue, 21 Mar 2023 13:25:58 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 28:
> 
>> 26: package java.lang;
>> 27: 
>> 28: import java.lang.Object;
> 
> You might want to do another pass to check for unused imports

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 44:
> 
>> 42:  * {@link StringTemplate} is the run-time representation of a string template or
>> 43:  * text block template in a template expression.
>> 44:  *
> 
> Extra newline?

Changing

> src/java.base/share/classes/java/lang/StringTemplate.java line 56:
> 
>> 54:  * {@link StringTemplate} is primarily used in conjunction with a template processor
>> 55:  * to produce a string or other meaningful value. Evaluation of a template expression
>> 56:  * first produces an instance of {@link StringTemplate}, representing the template
> 
> The "template of the template expression" - is this nomenclature official (e.g. backed by any text in the JLS?). I must admit I find it a tad jarring.

"representing the right hand side of the template expression"

> src/java.base/share/classes/java/lang/StringTemplate.java line 324:
> 
>> 322:      * assert Objects.equals(sc, "abcxyz");
>> 323:      * }
>> 324:      * the last character {@code "c"} from the first string is juxtaposed with the first
> 
> I was playing with this example in jshell:
> 
> jshell> var st1 = RAW."{1}"
> st1 ==> StringTemplate{ fragments = [ "", "" ], values = [1] }
> 
> jshell> var st2 = RAW."{2}"
> st2 ==> StringTemplate{ fragments = [ "", "" ], values = [2] }
> 
> jshell> StringTemplate.combine(st1, st2);
> $7 ==> StringTemplate{ fragments = [ "", "", "" ], values = [1, 2] }
> 
> 
> The result is obviously well-formed - but I'm not sure I can derive what the method does just by reading the javadoc. The javadoc says:
> 
> Fragment lists from the StringTemplates are combined end to end with the last fragment from each StringTemplate concatenated with the first fragment of the next
> 
> I think I see what you want to say - (e.g. the end fragment of string template `N` is concatenated with the starting fragment of string template `N + 1`).

okay

> src/java.base/share/classes/java/lang/StringTemplate.java line 431:
> 
>> 429:      * Java compilation unit.<p>The result of interpolation is not interned.
>> 430:      */
>> 431:     static final StringProcessor STR = StringTemplate::interpolate;
> 
> `static final` is redundant here (we are in an interface)

Did not know that.

> src/java.base/share/classes/java/lang/StringTemplate.java line 454:
> 
>> 452:      * This interface describes the methods provided by a generalized string template processor. The
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 
> nit: `{@link StringTemplate StringTemplate's}` will probably not render as you'd expect (as it will all be preformat, including the `'s`).

works for me

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 47:
> 
>> 45:  */
>> 46: @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 47: interface ReferenceKey<T> {
> 
> This (and other) class are package-private. Do we still need @PreviewFeature for stuff like this, since it's not meant to be used publicly?

Informative incase some one wants to use elsewhere in the JDK. My plan is to move this class to java.util at some point.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 226:
> 
>> 224:                         List.nil(), expressions);
>> 225:                 valuesArray.type = new ArrayType(syms.objectType, syms.arrayClass);
>> 226:                 return bsmCall(names.process, names.newLargeStringTemplate, syms.stringTemplateType,
> 
> nit: the indy name is irrelevant here - that said, `process` is a tad confusing, since it's also the name of a StringTemplate method.

Tracks well in javah

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 252:
> 
>> 250:                 staticArgsTypes = staticArgsTypes.append(syms.stringType);
>> 251:             }
>> 252:             return bsmCall(names.process, names.processStringTemplate, tree.type,
> 
> What happens if we have too many fragments here? (e.g. > 200). That case seems handled in the RAW case.

Criteria in isLinkageProcessor() prevents this from being called.


        boolean isLinkageProcessor() {
            return processor != null &&
                   !useValuesList &&  <=====
                   types.isSubtype(processor.type, syms.linkageType) &&
                   processor.type.isFinal() &&
                   TreeInfo.symbol(processor) instanceof VarSymbol varSymbol &&
                   varSymbol.isStatic() &&
                   varSymbol.isFinal();
        }

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 281:
> 
>> 279:             make.at(tree.pos);
>> 280: 
>> 281:             if (processor == null || isNamedProcessor(names.RAW)) {
> 
> is `processor == null` still a thing?

I deliberately left this to track free standing templates. Will be phased out in next preview/final.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144898843
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144899315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144902350
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144907969
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144911867
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144916768
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144915315
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144920121
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144924240
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1144918724

From jlaskey at openjdk.org  Wed Mar 22 14:43:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 22 Mar 2023 14:43:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <gRPU6mJGzRXFuI3XZK7jdqSQg1Cg5k2Fts_lYFa_NOk=.7ebd0a6d-ab29-4d51-bb03-d25ad824cfdb@github.com>
 <O0-vETFmb9QVUctuy3C3nA8RISu0Z8AQ6BcnNYGgdlo=.d86b1814-6e0f-4515-adb8-7d2499973678@github.com>
Message-ID: <xPCBJE3YSx1AVxj2eP5Z0-mbJxz40uiXK2kfbn-VOQU=.2ed3ed2e-3bbb-44c0-8a80-897c50729a66@github.com>

On Tue, 21 Mar 2023 13:37:02 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 69:
>> 
>>> 67:  * List<Object> values = st.values();
>>> 68:  * }
>>> 69:  * The value of {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
>> 
>> This is a bit hard to parse, due to the use of `the value of` (which then becomes problematic in the next para, as we are talking about `values`). Either change the name of the variable `values` in the snippet, or use some other locution, like "the list {@code fragments} is equivalent to ..." etc.
>
> The above comment also applies to the javadoc of the `fragments` and `values` methods, which use a similar way to describe their results.

* {@code fragments} will be equivalent to {@code List.of("", " + ", " = ", "")},
 * which includes the empty first and last fragments. {@code values} will be the
 * equivalent of {@code List.of(10, 20, 30)}.

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

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

From coffeys at openjdk.org  Wed Mar 22 14:42:33 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 22 Mar 2023 14:42:33 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test
In-Reply-To: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
Message-ID: <Rdr5GkpgY_V84-Ekm9278oWX78BD9u5zr5o7HY2Lxs0=.136ec1ae-e28a-44d0-a24a-f89ed41b4200@github.com>

On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

src/jdk.internal.le/share/classes/jdk/internal/org/jline/utils/OSUtils.java line 108:

> 106:     private static boolean isTestCommandValid(String command) {
> 107:         try {
> 108:             Process p = new ProcessBuilder(command, "-z", "").inheritIO().start();

is there a reason why you chose to spin up a process here ? Would a test for an executable file be sufficient ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13100#discussion_r1144922827

From jlahoda at openjdk.org  Wed Mar 22 18:38:08 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 22 Mar 2023 18:38:08 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
Message-ID: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

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

  Checking the executable flags instead of running the program, as suggested.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13100/files
  - new: https://git.openjdk.org/jdk/pull/13100/files/159ef1a0..f7631210

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

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

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

From liach at openjdk.org  Thu Mar 23 01:52:31 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:31 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

> 447:      * statically imported explicitly.
> 448:      */
> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;

Should we omit the modifiers `static final`, which are implicit for all interface fields?

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

> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
> 455:      *

Paragraph break intended here?

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

> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
> 549:      * }
> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}

Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

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

> 590:          */
> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 592:         public sealed interface Linkage permits FormatProcessor {

I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

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

> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 678:     @FunctionalInterface
> 679:     public interface StringProcessor extends SimpleProcessor<String> {

Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:

static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}

which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:

> 1049:      * @param ptypes    list of expression types
> 1050:      *
> 1051:      * @return {@link MethodHandle}

Suggestion:

     * @return the {@link MethodHandle} for concatenation

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:

> 1167:      * have an extra {@link String} slot for the result from the previous
> 1168:      * {@link MethodHandle}.
> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}

Suggestion:

     * {@link #makeConcatWithTemplate}

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1246:

> 1244:      * This method creates a {@link MethodHandle} expecting one input, the
> 1245:      * receiver of the supplied getters. This method uses
> 1246:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplateCluster}

Suggestion:

     * {@link #makeConcatWithTemplateCluster}

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

> 368:          */
> 369:         private static Map<MethodType, CarrierElements>
> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());

Suggestion:

                methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

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

> 419:          */
> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
> 421:             this.primitives = createPrimitivesArray(primitiveCount );

Suggestion:

            this.primitives = createPrimitivesArray(primitiveCount);

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

> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
> 775:          */
> 776:         static CarrierElements of(Class < ? >...ptypes) {

Suggestion:

        static CarrierElements of(Class<?>... ptypes) {

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

> 822:         private CarrierElements() {
> 823:             throw new AssertionError("private constructor");
> 824:         }

Suggestion:

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

> 47: interface ReferenceKey<T> {
> 48:     /**
> 49:      * {@return the value of the unwrapped key.}

Suggestion:

     * {@return the value of the unwrapped key}

Inline return tag generates a period already.

src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:

> 125:     @SuppressWarnings("unchecked")
> 126:     static <K, V> ReferencedKeyMap<K, V>
> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {

What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

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

> 38:  * <p>
> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
> 40:  * and sharing of value shapes without creating a new class for each shape.

Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

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

> 63:      * {@link java.lang.invoke.CallSite CallSite}.
> 64:      */
> 65:     private final MethodHandle valuesMH;

I don't think `java.lang.runtime` is a package where final fields are [trusted](https://github.com/openjdk/jdk/blob/91f407d6fe285c44bcc25c1acdf5dc0c43be0172/src/hotspot/share/ci/ciField.cpp#L226), so these method handles might have a performance overhead. However, records appear to be optimized and eligible for inlining.

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

> 86:      *
> 87:      * @param fragments  string template fragments
> 88:      * @param type       method type

Suggestion:

     * @param type method type accepting values' types and returning a StringTemplate

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

> 167:      * @return StringTemplate composed from fragments and values
> 168:      */
> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {

I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

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

> 202:             Object[] values
> 203:     ) throws Throwable {
> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));

Suggestion:

        List<Object> asList = List.of(values);

For defensive copy.
Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

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

> 231:      */
> 232:     private static StringTemplate fromArrays(String[] fragments, Object[] values) {
> 233:         return StringTemplateImplFactory.newStringTemplate(fragments, values);

Should perform defensive copying for the input arrays, specifically `values` (fragments is passed to `List.of`, which is already safe)

In addition, I recommend renaming methods that don't perform defensive copies to like `ofTrusted`, so we can better avoid such problems.

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

> 66:      */
> 67:     final class DecimalDigits implements Digits {
> 68:         private static final short[] DIGITS;

Can add `@Stable` to speed up array element access. Same for below.

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

> 155:         Objects.requireNonNull(stringTemplate);
> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);

Suggestion:

        Object[] values = stringTemplate.values().toArray();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500281
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145500568
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145503416
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145582334
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145509343
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145511968
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145520158
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145521984
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145532679
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145528633
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531061
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145531547
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145533037
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145534263
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145566980
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145555878
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145567708
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145576079
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145577290
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145570455
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145578159
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1145579950

From liach at openjdk.org  Thu Mar 23 01:52:32 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 01:52:32 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
Message-ID: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>

On Fri, 28 Oct 2022 20:05:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> Disagree.
>
> As i said above, i consider this thread as resolved

Suggestion:

     * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

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

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

From jlaskey at openjdk.org  Thu Mar 23 11:49:18 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:49:18 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <p_X2VwL8FULtj_Uc8EpMJdBF5min1UtyXow7dgSfm08=.4d5b5224-daef-4c01-9139-38382382426b@github.com>

On Wed, 22 Mar 2023 23:12:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 449:
> 
>> 447:      * statically imported explicitly.
>> 448:      */
>> 449:     static final SimpleProcessor<StringTemplate> RAW = st -> st;
> 
> Should we omit the modifiers `static final`, which are implicit for all interface fields?

Already changed.

> src/java.base/share/classes/java/lang/StringTemplate.java line 455:
> 
>> 453:      * primary method {@link Processor#process(StringTemplate)} is used to validate
>> 454:      * and compose a result using a {@link StringTemplate StringTemplate's} fragments and values lists.
>> 455:      *
> 
> Paragraph break intended here?

Changed

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

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

From jlaskey at openjdk.org  Thu Mar 23 11:52:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 11:52:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <QU206yI0AfLSRZu-8MGtN95EdFTAmGIHbDIkw5Igv9w=.effa8829-ed13-42c3-b881-9bdfff403779@github.com>

On Wed, 22 Mar 2023 23:16:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 550:
> 
>> 548:      * SimpleProcessor<JSONObject> jsonProcessor = st -> new JSONObject(st.interpolate());
>> 549:      * }
>> 550:      * @implNote The Java compiler automatically imports {@link StringTemplate#STR}
> 
> Does this note belong here? And does this come with a rule in the Java Language Specification, which can be linked?

This is in the changes JLS defined in https://bugs.openjdk.org/browse/JDK-8296302 . I'll be updating the @jls links when finalized.

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

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

From jlaskey at openjdk.org  Thu Mar 23 12:16:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:16:39 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>

On Wed, 22 Mar 2023 23:23:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
> 
>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 678:     @FunctionalInterface
>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
> 
> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
> 
> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
> 
> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.

Worth considering. Thank you.

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

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

From jlaskey at openjdk.org  Thu Mar 23 12:20:04 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:20:04 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>

On Thu, 23 Mar 2023 01:33:59 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
> 
>> 202:             Object[] values
>> 203:     ) throws Throwable {
>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
> 
> Suggestion:
> 
>         List<Object> asList = List.of(values);
> 
> For defensive copy.
> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.

The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

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

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

From jlaskey at openjdk.org  Thu Mar 23 12:28:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:28:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RsngCPLETmmciRbbJmWhucmKxdY6wywBZYkxO3OlGmw=.8f251d95-7d25-467a-9e6f-68e0f68ffb3f@github.com>

On Thu, 23 Mar 2023 01:45:54 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 592:
> 
>> 590:          */
>> 591:         @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 592:         public sealed interface Linkage permits FormatProcessor {
> 
> I fail to see any reason a user would call `linkage`; is there anything that's not covered by `TemplateRuntime::processStringTemplate`? And if users can't use this, this can just be relocated to one of the `jdk.internal` packages.

Linkage is unfinished business for the first preview. What we are working on is a managed construction of the BSM, a ProcessorFactory per se. The hope is that this will be flushed out for the next round.

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

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

From jlaskey at openjdk.org  Thu Mar 23 12:24:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:24:12 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <fnsA_D74g7fDjymHpEjRggSEoo_59PBHF1NK8PwLhjo=.dd834f1d-5566-47a9-a59f-38ad822100fb@github.com>

On Thu, 23 Mar 2023 01:36:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/util/Digits.java line 68:
> 
>> 66:      */
>> 67:     final class DecimalDigits implements Digits {
>> 68:         private static final short[] DIGITS;
> 
> Can add `@Stable` to speed up array element access. Same for below.

Changing

> src/java.base/share/classes/java/util/FormatProcessor.java line 157:
> 
>> 155:         Objects.requireNonNull(stringTemplate);
>> 156:         String format = stringTemplateFormat(stringTemplate.fragments());
>> 157:         Object[] values = stringTemplate.values().toArray(new Object[0]);
> 
> Suggestion:
> 
>         Object[] values = stringTemplate.values().toArray();

Changing

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

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

From jlaskey at openjdk.org  Thu Mar 23 12:44:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 12:44:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <_OQ7lbvgmuySOqu5i6NIihfPAee6VjBxoyhwv_lV7cw=.b7735595-141b-4f96-b9f4-605ecfce62aa@github.com>

On Thu, 23 Mar 2023 01:31:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 169:
> 
>> 167:      * @return StringTemplate composed from fragments and values
>> 168:      */
>> 169:     static StringTemplate newStringTemplate(List<String> fragments, Object[] values) {
> 
> I recommend renaming this one and the above methods (taking Object[] for values) `newTrustedStringTemplate` to indicate these two trust the passed values array.

I don't disagree, I will consider.

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

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

From coffeys at openjdk.org  Thu Mar 23 13:06:45 2023
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 23 Mar 2023 13:06:45 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: <bUtncDsZxaLFOHitDy6f--AGWw0kY3Uf7LsL8XTPaM4=.8a411b5d-8cd1-4d7b-873d-6bcd4d9ce440@github.com>

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

LGTM

the test call seems to be only used in one method where JLine attempts to test the tty fd value (AFAICT) - they're hacking into java.lang.ProcessBuilder$RedirectPipeImpl for that purpose.

wonder if there's anything else the JDK libs can offer.

https://github.com/openjdk/jdk/blob/master/src/jdk.internal.le/share/classes/jdk/internal/org/jline/terminal/impl/exec/ExecTerminalProvider.java#L120

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13100#pullrequestreview-1354582322

From jlaskey at openjdk.org  Thu Mar 23 13:07:05 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 13:07:05 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v47]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <F7PO-Fpe6hQGkA70LwmKQ_EfnjmN_p9Ui_fjRO_U3BM=.4df1b97b-72eb-43c8-ac3b-200742e3e5f5@github.com>

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

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Review recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/9ba6400d..6f95d953

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

  Stats: 36 lines in 6 files changed: 6 ins; 15 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Thu Mar 23 14:42:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 14:42:27 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
Message-ID: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>

On Thu, 23 Mar 2023 12:12:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/StringTemplate.java line 679:
>> 
>>> 677:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>>> 678:     @FunctionalInterface
>>> 679:     public interface StringProcessor extends SimpleProcessor<String> {
>> 
>> Just curious, what's the rationale of a `SimpleProcessor` or `StringProcessor` as opposed to:
>> 
>> static <T> TemplateProcessor<T, RuntimeException> simple(Function<StringTemplate, T> function) {...}
>> static TemplateProcessor<String, RuntimeException> string(Function<StringTemplate, String> function) {...}
>> 
>> which avoids the requirement of specifying the type of the template processor local variable; users can use `var` instead.
>
> Worth considering. Thank you.

You can, of course, reduce this to;


interface Processor {
 
    ...
    
    static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
        return function::apply;
    }
    
    ...

}


since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

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

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

From jlaskey at openjdk.org  Thu Mar 23 15:05:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:05:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
Message-ID: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>

On Thu, 23 Mar 2023 14:39:39 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Worth considering. Thank you.
>
> You can, of course, reduce this to;
> 
> 
> interface Processor {
>  
>     ...
>     
>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>         return function::apply;
>     }
>     
>     ...
> 
> }
> 
> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
> var string = Processor.of(StringTemplate::interpolate);
> 
> 
> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.

On the flip side, for those that don't use `var`;


Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);


vs.


SimpleProcessor<JSONObject> simple = Processor.of(st-> new JSONObject(st.interpolate()));
StringProcessor string = Processor.of(StringTemplate::interpolate);

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

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

From jlaskey at openjdk.org  Thu Mar 23 15:53:26 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 15:53:26 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
Message-ID: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>

On Thu, 23 Mar 2023 15:01:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> You can, of course, reduce this to;
>> 
>> 
>> interface Processor {
>>  
>>     ...
>>     
>>     static <T> StringTemplate.Processor<T, RuntimeException> of(Function<StringTemplate, T> function) {
>>         return function::apply;
>>     }
>>     
>>     ...
>> 
>> }
>> 
>> var simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> var string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> since String is just a type. This proposal has merit and worth some thought. -2 interfaces, +1 method.
>
> On the flip side, for those that don't use `var`;
> 
> 
> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
> 
> 
> vs.
> 
> 
> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
> StringProcessor string = StringTemplate::interpolate;

It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

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

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

From forax at openjdk.org  Thu Mar 23 16:38:43 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:38:43 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
Message-ID: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>

On Thu, 23 Mar 2023 15:49:37 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> On the flip side, for those that don't use `var`;
>> 
>> 
>> Processor<JSONObject, RuntimeException> simple = Processor.of(st-> new JSONObject(st.interpolate()));
>> Processor<String, RuntimeException> string = Processor.of(StringTemplate::interpolate);
>> 
>> 
>> vs.
>> 
>> 
>> SimpleProcessor<JSONObject> simple = st-> new JSONObject(st.interpolate());
>> StringProcessor string = StringTemplate::interpolate;
>
> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.

Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.

It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

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

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

From liach at openjdk.org  Thu Mar 23 16:39:16 2023
From: liach at openjdk.org (Chen Liang)
Date: Thu, 23 Mar 2023 16:39:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
Message-ID: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>

On Mon, 20 Mar 2023 20:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

> 180:      */
> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));

Suggestion:

        return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());

per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

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

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

From forax at openjdk.org  Thu Mar 23 16:39:44 2023
From: forax at openjdk.org (=?UTF-8?B?UsOpbWk=?= Forax)
Date: Thu, 23 Mar 2023 16:39:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
Message-ID: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>

On Thu, 23 Mar 2023 12:17:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/runtime/TemplateRuntime.java line 204:
>> 
>>> 202:             Object[] values
>>> 203:     ) throws Throwable {
>>> 204:         List<Object> asList = Collections.unmodifiableList(new ArrayList<>(Arrays.asList(values)));
>> 
>> Suggestion:
>> 
>>         List<Object> asList = List.of(values);
>> 
>> For defensive copy.
>> Don't think processors are harmed by the null-hostile behavior of these list, for many template implementations already use null-hostile lists.
>
> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.

There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
so

  List<Object> asList = Arrays.stream(values).toList();

is what you are looking for.

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

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

From jlaskey at openjdk.org  Thu Mar 23 17:09:14 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:14 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <yc6ux1LgP-2SpYTNRPOxis8_b3_qUWRwJfur0RhKU3I=.c307b4bf-89b1-4bdf-9bda-cc0eaa129a2a@github.com>
Message-ID: <mmAY9J3CZffkVQAoOMfuuQAn6e1W-CV9WTQmzXl-wcE=.1e74658f-a7cd-4ed7-8d81-91c5aec5122b@github.com>

On Thu, 23 Mar 2023 16:30:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 182:
> 
>> 180:      */
>> 181:     static StringTemplate newStringTemplate(List<String> fragments, List<?> values) {
>> 182:         return new SimpleStringTemplate(List.copyOf(fragments), toList(values.stream().toArray()));
> 
> Suggestion:
> 
>         return new SimpleStringTemplate(List.copyOf(fragments), values.stream().toList());
> 
> per https://github.com/openjdk/jdk/pull/10889#discussion_r1146455491

Changed

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

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

From jlaskey at openjdk.org  Thu Mar 23 17:09:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:09:16 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <t4SsEBQhNlsp8pHAF_cYspNq8n4almGEUqaxmLXxdgE=.f62c76d7-4733-4622-8009-dc8d689e6305@github.com>
 <SCTth8bYq9NQybI9jAOCYks7hufuVD_DKXmQwrLF3nY=.aeb092a4-7ba5-45b0-8f6c-9406bddfd269@github.com>
Message-ID: <tRwCH5_g2UXF4dKHNXUHBnI7WSwtoIa25a-GGVUv848=.c98cd493-c687-498a-98e3-337d1ff529a4@github.com>

On Thu, 23 Mar 2023 16:25:22 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> The values list can't be null-hostile for the same reason that string concatenation can't be null-hostile. Please point to examples of null-hostile lists (other that fragments) being used in the template code. Apologies if I misinterpreted your meaning.
>
> There is a trick to do a defensive copy in case the list can contains a null, you can use `stream.toList()`,
> so
> 
>   List<Object> asList = Arrays.stream(values).toList();
> 
> is what you are looking for.

Changed

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

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

From jlaskey at openjdk.org  Thu Mar 23 17:12:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:12:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v48]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <bx0_rNhNOOZtZFTD1o1Kyh0epp_vd3cXYvvgXdw654Y=.75542bb1-2326-4eaa-b8a9-1590237604b3@github.com>

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

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Clean up list construction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/6f95d953..96752c64

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

  Stats: 12 lines in 2 files changed: 4 ins; 5 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Thu Mar 23 17:24:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 23 Mar 2023 17:24:54 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
 <51X9oW6MmwKpahlHg8VVULoHBgaaI6kqAAefYyfbQe8=.cec29854-1afb-4ae7-ab4b-5b4996a92411@github.com>
 <ovQEobG5DXz3TR53ULHoaRqURFktcnIeLrsgQ8IpXkc=.f1d8499b-7f09-4fb6-9022-ce69e564793e@github.com>
 <C_l_qta7JnhtDHtFn9jielyByssF51S26nBQ0e7wZ8U=.3a532555-cc69-49f1-8b35-37b497bcfd9c@github.com>
 <5mzBgTz3eo9ZuTM7_WLDW_Y-DC8dnn8pfSfylOAOh0o=.68b7c46c-5faf-41c5-9c0f-0033d33cb574@github.com>
 <UynbMJViS0swR2O_btcSvrOslupdIedcWm47Dyzx0Z4=.9011deb3-1228-4fe3-ade1-c1c9266e9fcd@github.com>
Message-ID: <Xs8mcQOFKLdtbKIiMuYaZVAhn0F_LEA38YjAQTljriQ=.6130e9f7-58e6-4dae-abf1-ccef25a56510@github.com>

On Thu, 23 Mar 2023 16:21:56 GMT, R?mi Forax <forax at openjdk.org> wrote:

>> It's coming back to me why we didn't do this in the first place (these projects tend to go on for months and years). `SimpleProcessor` exists because of that ugly second parameter, `E`, in `Processor<R, E>`, when a majority of the time `E` will be the unchecked `RuntimeException`. `StringProcessor` exists because 90+% of template processors will produce strings. From there, we originally had `Process.of`, `SimpleProcessor.of` and `StringProcessor.of`. We realized that the `@FunctionalInterface` route was cleaner and there was no need for `of` -- keep interfaces simple. I would argue that if you are creating a template processor, it is better to expose the result type and not bury in a `var`.
>
> Not a lot of people will write a processor and among those few, most of them will create a class that implement `Processor` (to have a proper name and a place to put documentation) so providing several reified names (`SimpleProcessor` and `StringProcessor`) is not that useful for implementers. For users, it's not something necessary to understand how processors work or how a specific processor should be used.
> 
> It looks like a loose loose situation for me, implementers do not need them and users will find them confusing (especially the difference between a processor and a simple processor).

"Not a lot of people will write a processor" I am not as confident as you. Once the cat is out of the bag that you can do magic (pending Guide to String Templates), processors will become a common idiom for designating string literals, especially text blocks.

But, I do agree that a majority will do old school classes with `process` methods along with several supporting methods. On the other  hand, the API itself uses function interfaces to define STR and RAW. I guess I'll have to do a pro/con chart.

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

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

From jlaskey at openjdk.org  Fri Mar 24 15:43:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:37 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v3]
In-Reply-To: <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <Y7bgowTYsilflYezOx1afG-zd1qi8z2ke6eslfDFJ-E=.78fa826c-f3f4-4957-b5cb-99e37dc8a457@github.com>
 <wN_IyeiYUMOosdVWoqjGtlOi2hk2euA1vp2LvYswsqk=.164938ca-f6d7-495c-8f7c-44d4dc742b01@github.com>
 <jo5GI5KUSh4CZNvbursMHousbV9yE7UYmDTD8FGxkT8=.2eac5672-d13e-4e3b-8dbe-b35b01166907@github.com>
 <9vQMc2mMDyHm5uoAKuvtqGm4pyJdVdSRIKGmfrEBQvI=.f7cd331b-4185-4f9b-9e94-0893090d0e53@github.com>
 <QRfsnqZuJOmZK0Xoegbzo7ke-wjzHStS2MqCkIiw6Yo=.08d08244-9c07-4843-a7b8-a33f72e25e0d@github.com>
Message-ID: <rYN35QVpwQyTCYLdyjrhAReLGXJaJJ2Q8J3foqyXJBk=.79a0e847-4dba-4c6e-b38b-522bea0e8950@github.com>

On Wed, 22 Mar 2023 23:26:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> As i said above, i consider this thread as resolved
>
> Suggestion:
> 
>      * to {@value #MAX_INDY_CONCAT_ARG_SLOTS}.

Changing

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

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

From jlaskey at openjdk.org  Fri Mar 24 15:43:45 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:43:45 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <RxrEhssrnI3LiefQdgqBY4GomOVQsL4ekmpvSeNujeU=.e2baec72-a21f-4b99-9847-c324d0914cc3@github.com>

On Wed, 22 Mar 2023 23:27:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1051:
> 
>> 1049:      * @param ptypes    list of expression types
>> 1050:      *
>> 1051:      * @return {@link MethodHandle}
> 
> Suggestion:
> 
>      * @return the {@link MethodHandle} for concatenation

Changing

> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 1169:
> 
>> 1167:      * have an extra {@link String} slot for the result from the previous
>> 1168:      * {@link MethodHandle}.
>> 1169:      * {@link java.lang.invoke.StringConcatFactory#makeConcatWithTemplate}
> 
> Suggestion:
> 
>      * {@link #makeConcatWithTemplate}

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 370:
> 
>> 368:          */
>> 369:         private static Map<MethodType, CarrierElements>
>> 370:                 methodTypeCache = ReferencedKeyMap.create(() -> new ConcurrentHashMap<>());
> 
> Suggestion:
> 
>                 methodTypeCache = ReferencedKeyMap.create(ConcurrentHashMap::new);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 421:
> 
>> 419:          */
>> 420:         protected CarrierObject(int primitiveCount, int objectCount) {
>> 421:             this.primitives = createPrimitivesArray(primitiveCount );
> 
> Suggestion:
> 
>             this.primitives = createPrimitivesArray(primitiveCount);

Changing

> src/java.base/share/classes/java/lang/runtime/Carriers.java line 776:
> 
>> 774:          * @throws IllegalArgumentException if number of component slots exceeds maximum
>> 775:          */
>> 776:         static CarrierElements of(Class < ? >...ptypes) {
> 
> Suggestion:
> 
>         static CarrierElements of(Class<?>... ptypes) {

Changing

> src/java.base/share/classes/java/lang/runtime/ReferenceKey.java line 49:
> 
>> 47: interface ReferenceKey<T> {
>> 48:     /**
>> 49:      * {@return the value of the unwrapped key.}
> 
> Suggestion:
> 
>      * {@return the value of the unwrapped key}
> 
> Inline return tag generates a period already.

Changing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147750445
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752071
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757381
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147752347
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147755043
PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1147757878

From jlaskey at openjdk.org  Fri Mar 24 15:51:17 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:51:17 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <WAU8fcqQiwVjG9k-aZS7r0XP4KN_R3qho0XhzjAZewA=.5256da3e-3d3f-4d42-9fc6-aae4a222f985@github.com>

On Wed, 22 Mar 2023 23:56:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/ReferencedKeyMap.java line 127:
> 
>> 125:     @SuppressWarnings("unchecked")
>> 126:     static <K, V> ReferencedKeyMap<K, V>
>> 127:     create(boolean isSoft, Supplier<Map<?, ?>> supplier) {
> 
> What prevents this to take `Supplier<Map<ReferencedKey<K>, V>>`? Same for below.

Remnants of when I was have issues with param types. Changed.

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

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

From jlaskey at openjdk.org  Fri Mar 24 15:58:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 24 Mar 2023 15:58:13 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v46]
In-Reply-To: <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <eQnMNlemZf8nHIIhCC_K0dOeIj9ScF9rRjQJ1bJrUTc=.dfc32e62-37f0-4f8f-92da-11da1b797cc0@github.com>
 <HDvUPBBradKU4h2XJHch8WKrOc0jdE5Py4E71EIvEpY=.4928ee6a-f9f2-4b63-9d48-7ac522b2369b@github.com>
Message-ID: <pugiPyGFAbHHDjJAkRR85ZzhOuXVeRcvMaUg164VzGc=.ebc126d8-3cbf-457b-a30f-444552472355@github.com>

On Thu, 23 Mar 2023 01:12:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Tidy javadoc
>>  - Rename StringTemplate classes
>
> src/java.base/share/classes/java/lang/runtime/StringTemplateImpl.java line 40:
> 
>> 38:  * <p>
>> 39:  * Values are stored by subclassing {@link Carriers.CarrierObject}. This allows specializations
>> 40:  * and sharing of value shapes without creating a new class for each shape.
> 
> Just curious, what specific benefits does subclassing offer over having `CarrierObject` as a field? I don't see how a new class is ever created for each shape in that scenario, as shapes are only used to construct the 2 MHs in the factory.

About a 15-20% performance gain by not having two levels of indirection.

> src/java.base/share/classes/java/lang/runtime/StringTemplateImplFactory.java line 88:
> 
>> 86:      *
>> 87:      * @param fragments  string template fragments
>> 88:      * @param type       method type
> 
> Suggestion:
> 
>      * @param type method type accepting values' types and returning a StringTemplate

Changing

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

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

From vromero at openjdk.org  Mon Mar 27 15:38:57 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Mon, 27 Mar 2023 15:38:57 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: <Rq400GFaONCqI9u3GOYI5WE2b7JiHHyd1nfJKWX_o-E=.83f6faf8-58b1-4210-8c79-d266058277f0@github.com>

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

looks sensible

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13100#pullrequestreview-1359340541

From jlaskey at openjdk.org  Mon Mar 27 16:17:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 27 Mar 2023 16:17:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v49]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <m87R9KqgHRFWTaSkiHHK9nbPl0Q9dnSrR0phYMEJpFg=.19cf87ba-2f6a-476c-83e3-e89ff7ba77c3@github.com>

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

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Requested review changes.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/96752c64..58eeb319

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

  Stats: 179 lines in 12 files changed: 31 ins; 116 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From jlaskey at openjdk.org  Tue Mar 28 15:14:44 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 28 Mar 2023 15:14:44 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v50]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <WrElbf-3B1iF4yBMQt2_QmSQ5IBKu1lp9-E2nSZba0s=.69bd2cf1-435b-4bef-ba76-19cac9b5ac5b@github.com>

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

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update StringTemplate.combine javadoc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/58eeb319..c9696c2b

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

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

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

From jlahoda at openjdk.org  Tue Mar 28 17:00:26 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 28 Mar 2023 17:00:26 GMT
Subject: Integrated: 8304498: JShell does not switch to raw mode when there is
 no /bin/test
In-Reply-To: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
Message-ID: <CLf5RLdkvm0zELSV7378PKuJCSR9j9eekW88MzDBnHQ=.d74c47af-a3bc-4f4f-a6c8-e205144133dc@github.com>

On Mon, 20 Mar 2023 12:10:04 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
> 
> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.

This pull request has now been integrated.

Changeset: fab23577
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fab23577ab7fb88f90df638588e14da6bb620a3a
Stats:     59 lines in 2 files changed: 58 ins; 0 del; 1 mod

8304498: JShell does not switch to raw mode when there is no /bin/test

Reviewed-by: coffeys, vromero

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

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

From aturbanov at openjdk.org  Tue Mar 28 18:36:57 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 28 Mar 2023 18:36:57 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
Message-ID: <JBNn0Geng0GRA2jAkYspQNRlgcjHgRhhk4wqJb62jNk=.03ca633a-6dc9-4018-b630-e00ce4e91126@github.com>

On Wed, 22 Mar 2023 18:38:08 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> If JShell is run on a system that does not have `/bin/test` (which is, apparently, possible for some systems, which only have `/usr/bin/test`), it won't switch the terminal into the raw mode, and the input will not work properly.
>> 
>> The proposed fix herein is to detect whether `test` existing in `/usr/bin/test`, and if yes, use that location. Use the existing `/bin/test` otherwise.
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Checking the executable flags instead of running the program, as suggested.

@lahodaj was the issue reported to the upstream?

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

PR Comment: https://git.openjdk.org/jdk/pull/13100#issuecomment-1487419384

From jlaskey at openjdk.org  Wed Mar 29 14:57:06 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 14:57:06 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v51]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <LVcp5vWdUuUSkMzbbbOdDjYLooIKU_5IpS1jTnwauLA=.59afa583-063e-4194-98f6-d2e06e2004c3@github.com>

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

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

 - Merge branch 'master' into 8285932
 - Update StringTemplate.combine javadoc
 - Requested review changes.
 - Clean up list construction
 - Review recommended changes
 - Tidy javadoc
 - Rename StringTemplate classes
 - Merge branch 'master' into 8285932
 - Correction
 - Merge branch 'master' into 8285932
 - ... and 59 more: https://git.openjdk.org/jdk/compare/50a995f0...3e1cc74a

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=50
  Stats: 9255 lines in 75 files changed: 9156 ins; 24 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From jlahoda at openjdk.org  Wed Mar 29 15:15:40 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 29 Mar 2023 15:15:40 GMT
Subject: RFR: 8304498: JShell does not switch to raw mode when there is no
 /bin/test [v2]
In-Reply-To: <JBNn0Geng0GRA2jAkYspQNRlgcjHgRhhk4wqJb62jNk=.03ca633a-6dc9-4018-b630-e00ce4e91126@github.com>
References: <nkB_6vWARruaCkkT4qZRvpgPzxZJM4YVJTMAm-N323U=.64f4ba5c-cd48-452f-bb9e-4273e57abafe@github.com>
 <3zqgbZ1T9WHdEQxojLFpW1eJ0_iqxRnmkyGgu2YiMXw=.cb6b356a-fb3c-484c-aca3-3f09304e30c8@github.com>
 <JBNn0Geng0GRA2jAkYspQNRlgcjHgRhhk4wqJb62jNk=.03ca633a-6dc9-4018-b630-e00ce4e91126@github.com>
Message-ID: <LWYLfwls31wsTxWy-3BxEtMbqEvqHS1VFKN4jvI8uKw=.dfd1ed09-4408-4770-8268-4eecd75cccac@github.com>

On Tue, 28 Mar 2023 18:33:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> @lahodaj was the issue reported to the upstream?

I've just filled:
https://github.com/jline/jline3/issues/839

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

PR Comment: https://git.openjdk.org/jdk/pull/13100#issuecomment-1488819982

From jlaskey at openjdk.org  Wed Mar 29 15:46:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 29 Mar 2023 15:46:34 GMT
Subject: RFR: JDK-8285932 Implementation of JEP 430 String Templates
 (Preview) [v52]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <TC3w3VrcgeJyYDiYGehji419QgXo0wmkd6sqPZ0k-L0=.29b2c5e8-48d3-432d-980a-1e6062a11ed2@github.com>

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

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Update combine example

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

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

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

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

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

From jlu at openjdk.org  Fri Mar 31 21:41:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 31 Mar 2023 21:41:17 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <UC_eXLH1ZYj0NDyQ-MSY5oRvejr6HAHIznL3Lh7rwOY=.4cb34fe7-3979-454d-8d49-b07b248a5cf7@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Something thing to consider is that Intellj defaults .properties files to ISO 8859-1. 

https://www.jetbrains.com/help/idea/properties-files.html#encoding

So users of Intellj / (other IDEs that default to ISO 8859-1 for .properties files) will need to change the default encoding to utf-8 for such files. Or ideally, the respective IDEs can change their default encoding for .properties files if this change is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492640306

From naoto at openjdk.org  Fri Mar 31 22:48:29 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 31 Mar 2023 22:48:29 GMT
Subject: RFR: 8301991: Convert l10n properties resource bundles to UTF-8
 native [v5]
In-Reply-To: <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <KfA4T5hvP3LGNRRSoHOrCLIvFPxRW-8xEzJtRqGjAYs=.6c1a51ed-3d1f-4ec1-9c44-30f6253071ff@github.com>
Message-ID: <G-JuA4B7q1ygFjywx4FOwGfJX2Ud-Jf4BwgrzPykvXg=.61ddf6ba-5a7d-45a2-87aa-4613ec3dfb3b@github.com>

On Fri, 17 Mar 2023 22:27:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Close streams when finished loading into props

Hmm, I just wonder why they are sticking to ISO-8859-1 as the default. I know j.u.Properties defaults to 8859-1, but PropertyResourceBundle, which is their primary use defaults to UTF-8 since JDK9 (https://openjdk.org/jeps/226)

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1492682703