From iris at openjdk.org  Sat Apr  1 02:51:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Sat, 1 Apr 2023 02:51:21 GMT
Subject: <i18n dev> RFR: JDK-8305206: Add @spec tags in java.base/java.*
 (part 1) [v3]
In-Reply-To: <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
 <AzM9yIt0ic_LC_pI2Qi4oVMumARhGVjLVNoAM53uT28=.2d9a6869-38b8-421a-99c8-7e2155e8701b@github.com>
Message-ID: <9xeOR9nFP1Pv9OxHLOkbzYTOjIkJxOZnB9M4zKAxJgU=.1d896a82-0139-434b-a6a3-ce4650914727@github.com>

On Fri, 31 Mar 2023 22:07:26 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
>> 
>> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
>> 
>> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
>> 
>> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
>> 
>> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
>> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert removing @see tags where the URL was not the same as the @spec URL

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13248#pullrequestreview-1367798667

From duke at openjdk.org  Sun Apr  2 07:20:23 2023
From: duke at openjdk.org (M4ximumPizza)
Date: Sun, 2 Apr 2023 07:20:23 GMT
Subject: <i18n dev> RFR: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <aRDlPuULrQkNmxr5fhL8rPfCms1JjIQ8Xd-6x7AraOw=.e7704361-3425-40b8-a798-1eea7ea20ad6@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

Marked as reviewed by M4ximumPizza at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13275#pullrequestreview-1368032982

From naoto at openjdk.org  Mon Apr  3 16:56:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 16:56:12 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider
Message-ID: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>

This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

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

Commit messages:
 - clean-up
 - Added @implNote. Check "JRE" as well. Clean-up
 - Spec change to LocaleServiceProvider
 - clean-up
 - added a test
 - 8304982: Emit warning for removal of `COMPAT` provider

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

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

From alanb at openjdk.org  Mon Apr  3 17:28:58 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 17:28:58 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>

On Mon, 3 Apr 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 123:

> 121:  * {@link System#setProperty(String, String)} is discouraged and it may not affect
> 122:  * the order.
> 123:  * @implNote Java Runtime Environment provides the following four locale providers:

The change looks okay and I agree that this section should be changed to be an implNote. In several other areas, the wording is "The JDK Reference Implementation" rather than "Java Runtime Environment" in implNote text so we might have to adjust that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156247831

From naoto at openjdk.org  Mon Apr  3 18:11:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 18:11:03 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Replaced "Java Runtime Environment" with "JDK Reference Implementation"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13302/files
  - new: https://git.openjdk.org/jdk/pull/13302/files/95a46b61..d613600f

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

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

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

From naoto at openjdk.org  Mon Apr  3 18:11:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 18:11:06 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <Mclqz7aiAy9PVJMWybbtAUnvfadP9uzJjc87ADcRKuU=.a8a61d3d-489c-467d-85ef-f6e7a403c018@github.com>
Message-ID: <iEV94nJGeRBF10hvO_jCgC0m89fSHCbys2DZG5-OMuQ=.14583332-4afa-42bb-9a0a-5e35a5b6ea2b@github.com>

On Mon, 3 Apr 2023 17:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 123:
> 
>> 121:  * {@link System#setProperty(String, String)} is discouraged and it may not affect
>> 122:  * the order.
>> 123:  * @implNote Java Runtime Environment provides the following four locale providers:
> 
> The change looks okay and I agree that this section should be changed to be an implNote. In several other areas, the wording is "The JDK Reference Implementation" rather than "Java Runtime Environment" in implNote text so we might have to adjust that.

Replaced the wording as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156287411

From alanb at openjdk.org  Mon Apr  3 19:59:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 3 Apr 2023 19:59:00 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
Message-ID: <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>

On Mon, 3 Apr 2023 18:11:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"

src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:

> 118:  * the locale sensitive services separated by a comma. As this property value is
> 119:  * read and cached only at the initialization of this class, users should specify the
> 120:  * property on the java launcher command line. Setting it at runtime with

I may have missed it but does LocalServiceProvider's description of "java.locale.providers" say what the value of the system property is? If providers don't have names then I'm wondering if this system property can be used to select control ordering if I deploy my own provider. If not, then it makes me wonder if the definition of this system property needs to move to the implNote section.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156398749

From naoto at openjdk.org  Mon Apr  3 20:19:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 3 Apr 2023 20:19:03 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
Message-ID: <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>

On Mon, 3 Apr 2023 19:56:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replaced "Java Runtime Environment" with "JDK Reference Implementation"
>
> src/java.base/share/classes/java/util/spi/LocaleServiceProvider.java line 120:
> 
>> 118:  * the locale sensitive services separated by a comma. As this property value is
>> 119:  * read and cached only at the initialization of this class, users should specify the
>> 120:  * property on the java launcher command line. Setting it at runtime with
> 
> I may have missed it but does LocalServiceProvider's description of "java.locale.providers" say what the value of the system property is? If providers don't have names then I'm wondering if this system property can be used to select control ordering if I deploy my own provider. If not, then it makes me wonder if the definition of this system property needs to move to the implNote section.

Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156415773

From ysatowse at openjdk.org  Mon Apr  3 23:21:47 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:21:47 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
Message-ID: <0GIS0cB7XTY14P9SfaKlPz6LoTGxk-f6X9hpp02XBmk=.f9ee9de0-5a7d-4479-a4f0-8f7a00501a05@github.com>

On Fri, 31 Mar 2023 22:05:01 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 1996, 2033, Oracle and/or its affiliates. All rights reserved.
> 
> Wrong year.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156538844

From ysatowse at openjdk.org  Mon Apr  3 23:21:51 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:21:51 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <1VwO7D4lktZKW64DaX6vLHnmPcA9NjjS38Keru9HuC8=.6d236924-f398-4067-9e85-2c739fdd766c@github.com>
Message-ID: <lWWxOP6SzjE4LNGZMlqIgHQOF0afmhLqBnQIBauyyN0=.8190be32-83c0-453c-8617-795d877a7d29@github.com>

On Fri, 31 Mar 2023 16:44:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/data/tzdata/antarctica line 1:
> 
>> 1:  #
> 
> Extra space

Thanks!

> src/java.base/share/data/tzdata/northamerica line 1:
> 
>> 1: src/java.base/share/data/tzdata/northamerica #
> 
> ??? copy/paste error?

It's likely. Thanks for the catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156538477
PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156537246

From ysatowse at openjdk.org  Mon Apr  3 23:29:12 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:29:12 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <g7ZoUMeB75XYwOMS9w6PnUxZGievJ_310fvgNer5LBo=.216c004f-a73f-49c8-8714-0582741fe2fd@github.com>
Message-ID: <rJbHEtOPTJ9joR8VatPhGQAv9GsaJLor9E-1jUESArA=.cd7577e0-21fc-4823-b412-2c8f379d2c54@github.com>

On Fri, 31 Mar 2023 22:06:34 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java line 742:
> 
>> 740: 
>> 741:         return new ZoneInfo(zoneId, rawOffset, dstSavings, checksum, transitions,
>> 742:                 offsets, params, willGMTOffsetChange);
> 
> do we need to change it here?

No need.  It was reformatted by IntelliJ editor.  The original code is better from perspective of the OpenJDK's standard code style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13255#discussion_r1156543028

From ysatowse at openjdk.org  Mon Apr  3 23:34:05 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:34:05 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c [v2]
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <egXTJDiDBSUPeDPuKm5gHa-sPnsHIPUm1Vz5Hb_3S_U=.1fccc622-ce10-4daf-b9b0-32c195ac60ea@github.com>

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  fixing some typos

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13255/files
  - new: https://git.openjdk.org/jdk/pull/13255/files/c754a33e..b29bb679

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

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

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

From ysatowse at openjdk.org  Mon Apr  3 23:40:05 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Mon, 3 Apr 2023 23:40:05 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Revert formatted code in ZoneInfoFile.java
 - fixing typo again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13255/files
  - new: https://git.openjdk.org/jdk/pull/13255/files/b29bb679..30c575e5

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

  Stats: 23 lines in 1 file changed: 15 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/13255.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13255/head:pull/13255

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

From jjg at openjdk.org  Tue Apr  4 00:13:20 2023
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 4 Apr 2023 00:13:20 GMT
Subject: <i18n dev> Integrated: JDK-8305206: Add @spec tags in
 java.base/java.* (part 1)
In-Reply-To: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
References: <PgTUCZ62gep17-KQTJLQsSvwUbU4ai-aQhtVy5nYxe0=.c4a05469-2e3c-4d52-9e8a-dc2f29789f40@github.com>
Message-ID: <cU6-hY-ZFAn7XQ83SgGaTT-BsgqIhTus_Sj-XdFSzPE=.21e82408-ae57-4f06-9e51-cebd10d1efa5@github.com>

On Thu, 30 Mar 2023 17:24:11 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a change to add `@spec` tags (and remove some equivalent `@see` tags) to the main "core-libs" packages in `java.base` module.
> 
> This is similar to, and a subset of, PR #11073.   That PR was withdrawn, and based on the ensuing discussion and suggestion, is now being handled with a series of PRs for various separate parts of the system.  Follow-up PRs will be provided for the rest of `java.base`, for `java.desktop`, and for XML APIs.  The "LangTools" modules have already been updated.  The "External Specifications" page has been temporarily [disabled][] until this work is complete.
> 
> While the primary content of the change was automated, I've manually adjusted the formatting, to break long lines.
> 
> It is clear there is significant inconsistency in the ordering of block tags in doc comment.   We might want to (separately) consider normalizing the order of the tags, perhaps according to the order defined for the tags in the generated output, as given [here][]
> 
> [here]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L68
> [disabled]: https://github.com/openjdk/jdk/blob/83cf28f99639d80e62c4031c4c9752460de5f36c/make/Docs.gmk#L115

This pull request has now been integrated.

Changeset: c6bd489c
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c6bd489cc8d30fb6eec865b3dab1cf861e25c8d7
Stats:     270 lines in 60 files changed: 268 ins; 2 del; 0 mod

8305206: Add @spec tags in java.base/java.* (part 1)

Reviewed-by: alanb, naoto, darcy, lancea, dfuchs, iris, mchung

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

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

From iris at openjdk.org  Tue Apr  4 01:54:14 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 01:54:14 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <F61ux3s5-tBmXOa3RQ54mLcuG78LcElipew0-bgQ6Yk=.7865ae75-a5a6-46b5-a39e-e6cf660bbfde@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Associated CSR also Reviewed.

test/jdk/java/util/regex/RegExTest.java line 3827:

> 3825:                 POSIX_ASCII.isCntrl(cp)   != cntrl.reset(str).matches()  ||
> 3826:                 POSIX_Unicode.isCntrl(cp) != cntrlU.reset(str).matches() ||
> 3827:                 (CONTROL == type) != cntrlP.reset(str).matches() ||

I think this line may have lost the intended alignment of the "!=".

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1370046964
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1156628640

From alanb at openjdk.org  Tue Apr  4 06:58:04 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 06:58:04 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
Message-ID: <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>

On Mon, 3 Apr 2023 20:15:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?

There are two parts to this PR. One part is the deprecation of "COMPAT" with a warning if used, no issue there. The second part changes the text from "The JDK Reference Implementation .." to the end of the class description to be an implNote.  My concern is that is the system property "java.locale.providers" is introduced in the normative section but it doesn't say anything about values. It just says that it can be used to configure the user's preferred order. The possible names and everything about ordering is in the implNote section. To make this work is going to need some expansion of the text in the normative section to say that the value is a sequence of strings, separated by a comma. It will also need to say something about the names as they are implementation specific. Also what happens if I deploy two custom locale providers on the class path, which one is used as I don't think the system property covers that.

Maybe the right thing here is to drop "@implNote" (just the tag) from this PR so that the deprecation, warning, and the small adjustments to the class description are pushed out of the way. A follow-up PR could re-examine the class description and the description of the "java.locale.providers" property.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1156808106

From aturbanov at openjdk.org  Tue Apr  4 13:48:06 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 4 Apr 2023 13:48:06 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <y4OhV7jF8wscCbGEAVqH7fXG6cpRC-RaZRDm7DwI4-0=.65e27044-74fc-4971-bad9-e1b61eb72d64@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

test/jdk/java/util/regex/RegExTest.java line 3774:

> 3772:         Matcher emojiPP = Pattern.compile("\\p{IsEmoji_Presentation}").matcher("");
> 3773:         Matcher emojiMP = Pattern.compile("\\p{IsEmoji_Modifier}").matcher("");
> 3774:         Matcher emojiMBP = Pattern.compile("\\p{IsEmoji_Modifier_Base}").matcher("");

Let's align to this assignment. Or remove alignments completely.

test/jdk/java/util/regex/RegExTest.java line 3851:

> 3849:                 POSIX_Unicode.isJoinControl(cp) != joinCrtl.reset(str).matches() ||
> 3850:                 // Emoji properties
> 3851:                 isEmoji(cp)     != emojiP.reset(str).matches() ||

Suggestion:

                isEmoji(cp) != emojiP.reset(str).matches() ||

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157280360
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157280914

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

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

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

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

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

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

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

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

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

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

On Tue, 4 Apr 2023 15:16:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

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

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

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

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

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

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

see above

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

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

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

On Tue, 4 Apr 2023 15:16:19 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

The wildcards are missing :)

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

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

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

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

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

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

Changing

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

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

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

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

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

Changing

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

Changing

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

Changing

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

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

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

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

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

  Recommended changes

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

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

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

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

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

From andrew at openjdk.org  Tue Apr  4 16:21:37 2023
From: andrew at openjdk.org (Andrew John Hughes)
Date: Tue, 4 Apr 2023 16:21:37 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <1ATbpv7Q-diFv252WtjRSpLN1fbXHjMsMQQIta7junU=.d3edb88a-fe7b-4752-94fd-36eab10a974d@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

Looks good to me. Interesting that `TimeZoneNames.java` already has the `MSK` change for the other timezone that was changed, `Europe/Volgograd`

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

Marked as reviewed by andrew (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371346092

From naoto at openjdk.org  Tue Apr  4 16:49:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 16:49:12 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <5hGSIiG3mi9eIPNFV2IMhnkdlGKqmKQMzElwVbZ1bTA=.4657e94f-8c03-4de0-a95b-8677c879965c@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371389824

From naoto at openjdk.org  Tue Apr  4 17:10:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:10:09 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v2]
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13314/files
  - new: https://git.openjdk.org/jdk/pull/13314/files/7a8a821c..41cfe460

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

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

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

From naoto at openjdk.org  Tue Apr  4 17:10:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:10:27 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <XOPmRyPdwhuCh139oRJVCH9wu1sTDax-UjQfw-cY2tQ=.9390d89c-657b-4423-833b-480d71e5c85a@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Thanks, Iris, Andrey. Alignment corrected.

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

PR Comment: https://git.openjdk.org/jdk/pull/13314#issuecomment-1496318682

From naoto at openjdk.org  Tue Apr  4 17:30:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:30:00 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v3]
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Removed @implNote for now

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13302/files
  - new: https://git.openjdk.org/jdk/pull/13302/files/d613600f..5eeb1ab0

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

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

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

From naoto at openjdk.org  Tue Apr  4 17:35:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 17:35:05 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
 <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
Message-ID: <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>

On Tue, 4 Apr 2023 06:54:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?
>
>> Locale providers provided by users can all be loaded in the name of `SPI`, as they are the real implementation of `LocaleServiceProvider` class, so the order of the preference can be specified against JDK's `CLDR` provider. Does this answer your question?
> 
> There are two parts to this PR. One part is the deprecation of "COMPAT" with a warning if used, no issue there. The second part changes the text from "The JDK Reference Implementation .." to the end of the class description to be an implNote.  My concern is that is the system property "java.locale.providers" is introduced in the normative section but it doesn't say anything about values. It just says that it can be used to configure the user's preferred order. The possible names and everything about ordering is in the implNote section. To make this work is going to need some expansion of the text in the normative section to say that the value is a sequence of strings, separated by a comma. It will also need to say something about the names as they are implementation specific. Also what happens if I deploy two custom locale providers on the class path, which one is used as I don't think the system property covers that.
> 
> Maybe the right thing here is to drop "@implNote" (just the tag) from this PR so that the deprecation, warning, and the small adjustments to the class description are pushed out of the way. A follow-up PR could re-examine the class description and the description of the "java.locale.providers" property.

Good point. Removed the @implNote tag for now and filed a separate issue to clarify the system property: https://bugs.openjdk.org/browse/JDK-8305595

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1157565170

From alanb at openjdk.org  Tue Apr  4 18:22:08 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:22:08 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v3]
In-Reply-To: <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <uq37oZroZ0N3SASt0EQ9lAkYYb9TfZuxjzNIcTBT0n8=.028106b7-c850-4763-9461-51b86294fcd4@github.com>
Message-ID: <WOA5AnWNCgmUcj-rm6acPqrsg0blkDcN40VgXF3MBeE=.07166567-eefe-4fe3-9ef4-886c5d6e796b@github.com>

On Tue, 4 Apr 2023 17:30:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed @implNote for now

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13302#pullrequestreview-1371538145

From alanb at openjdk.org  Tue Apr  4 18:22:10 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 4 Apr 2023 18:22:10 GMT
Subject: <i18n dev> RFR: 8304982: Emit warning for removal of `COMPAT`
 provider [v2]
In-Reply-To: <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
 <CTu8GEr7M96qN2VqCX0pcgkIgQnOLawY-9DvCTBqjjY=.00282dfc-2d97-40a3-b6ec-6efad774d573@github.com>
 <KrPf7Cdx49LrETjy7N__lBWsXbmji93laRgUpErHGVQ=.3d70ebd7-35c1-4c54-8343-d59ee4df7d77@github.com>
 <DAPIvBszP49fQ1q_9v_onndEIpjFX2waXY_FA4-vups=.cd268216-7359-4071-aefd-543a1923cfdb@github.com>
 <pI6XSenNXSeDkGiioQ-1DCOEOpYBKxW47eF90uKTaHQ=.de3c3b1e-f1e2-48f6-9616-a22d8663adea@github.com>
 <AYWcQJ7odD8tJMqfNY8ucKVgDghy7TxCOFSSW978ooo=.a921e48e-98cd-46b0-8cc4-a365c6073c5f@github.com>
Message-ID: <FNgksSyX3kBuP7Uk9fvRt2ORHWad8uNxE-9SUxp4Bn0=.f1c772eb-6644-43a5-8c89-fa8c866c37a3@github.com>

On Tue, 4 Apr 2023 17:32:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Good point. Removed the @implNote tag for now and filed a separate issue to clarify the system property: https://bugs.openjdk.org/browse/JDK-8305595

Okay, that works for me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13302#discussion_r1157610558

From serb at openjdk.org  Tue Apr  4 18:31:10 2023
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 4 Apr 2023 18:31:10 GMT
Subject: <i18n dev> RFR: 8305113: (tz) Update Timezone Data to 2023c [v3]
In-Reply-To: <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
 <vTLYpNzwdiTkdNdsHyDC9iRA8GMLIov2-ASJi8ARaiY=.6797783d-5bd7-4093-910b-e4da9691817f@github.com>
Message-ID: <DTLIN9wvY3pjdZhq4I4wCjeOMro3QzaIH6MPhxAEMrc=.4d64e3e1-f78c-4073-82a4-54ac30f2abab@github.com>

On Mon, 3 Apr 2023 23:40:05 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Pleases review this PR. 
>> The PR includes the following changes.
>> - tzdata 2023c
>> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.
>
> Yoshiki Sato has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert formatted code in ZoneInfoFile.java
>  - fixing typo again

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13255#pullrequestreview-1371553159

From rriggs at openjdk.org  Tue Apr  4 19:31:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:31:02 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some modules
Message-ID: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>

With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
This PR exports jdk.internal.util to:
 - java.prefs,
 - java.security.jgss,
 - java.smartcardio,
 - jdk.charsets,
 - jdk.net,
 - jdk.zipfs

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

Commit messages:
 - In jdk.prefs module, Replace os.name with OperatingSystem enum
 - Use OperatingSystem methods instead of system property os.name

Changes: https://git.openjdk.org/jdk/pull/13335/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13335&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8304911
  Stats: 131 lines in 13 files changed: 24 ins; 54 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/13335.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13335/head:pull/13335

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

From rriggs at openjdk.org  Tue Apr  4 19:35:08 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 19:35:08 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v2]
In-Reply-To: <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
Message-ID: <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>

On Tue, 4 Apr 2023 17:10:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation

Changes requested by rriggs (Reviewer).

test/jdk/java/util/regex/RegExTest.java line 64:

> 62: import java.util.stream.Stream;
> 63: 
> 64: import static java.lang.Character.*;

These static imports make the uses of the methods harder to recognize as from the Character class.

test/jdk/java/util/regex/RegExTest.java line 967:

> 965:         for (int i=0; i<1000; i++) {
> 966:             char c = (char)generator.nextInt();
> 967:             check("{javaLowerCase}", c, isLowerCase(c));

There are more readable with the explicit Character class reference; with them one has to hunt around for the named method. It also makes it explicit what is being tested.

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

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1371648289
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157676720
PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157677335

From naoto at openjdk.org  Tue Apr  4 20:15:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:15:52 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v3]
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Revert static import of Character.*

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13314/files
  - new: https://git.openjdk.org/jdk/pull/13314/files/41cfe460..5fd43d9e

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

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

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

From naoto at openjdk.org  Tue Apr  4 20:17:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:17:09 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v2]
In-Reply-To: <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <dXZYF3W2xBs1XKuQIyFSXSE6312C807ORXNmdXiwXOU=.d3cbcfcc-bc11-43a2-be83-15128d55b1a8@github.com>
 <azrc3PGKCGEGi6cken-j-5XEmIHZY5KQf2Qf2D8OC8s=.e710ddb7-26eb-4d39-8175-4b09ba9951d6@github.com>
Message-ID: <yu_gR26yn6qR8CLy6jyJMtWHq1G36mapgnyRJlwcxVg=.286224a7-149b-43bc-b038-9b9cd504084c@github.com>

On Tue, 4 Apr 2023 19:31:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation
>
> test/jdk/java/util/regex/RegExTest.java line 967:
> 
>> 965:         for (int i=0; i<1000; i++) {
>> 966:             char c = (char)generator.nextInt();
>> 967:             check("{javaLowerCase}", c, isLowerCase(c));
> 
> There are more readable with the explicit Character class reference; with them one has to hunt around for the named method. It also makes it explicit what is being tested.

I thought it was apparent since this is testing the *Character* properties and reduces the complexity, but if you think so maybe not. Reverting static import as I don't have a strong opinion on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13314#discussion_r1157717351

From naoto at openjdk.org  Tue Apr  4 20:46:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Apr 2023 20:46:08 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <PLVQO12D6OpNUM1D631lpeCa-XG2ppj8-yFutinjzo4=.8419be80-c474-4f80-b348-9248b49f12fc@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371756979

From lancea at openjdk.org  Tue Apr  4 20:54:09 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 4 Apr 2023 20:54:09 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <jmYozHgCwkNFcK_M5EWxKGZ9iHABZ-RdMAOeDjBGNGk=.348c92c5-fb19-410f-9991-d7ab772ac914@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

The changes look good

Please add a Noreg-XXX label to the bug

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371768336

From iris at openjdk.org  Tue Apr  4 21:00:10 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 4 Apr 2023 21:00:10 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <w--1bkwl6V1e7G7aGwcv4NlboudQn_noNPCyD03SAYM=.0c98f3d4-d4a1-43ca-b239-20d6658172a5@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1371776265

From jlu at openjdk.org  Tue Apr  4 21:05:24 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Apr 2023 21:05:24 GMT
Subject: <i18n dev> Integrated: 8225641: Calendar.roll(int field) does not
 work correctly for WEEK_OF_YEAR
In-Reply-To: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
References: <T5X_NLj7R0BZIfs1B_PB1zT0psonWiiJiJ6I-vAfCVY=.5336ba22-5349-4b8e-85d2-6f6ceac4b92d@github.com>
Message-ID: <EMy9c6RMyhfDZLAZr0MypZPMpSAleTzm7CD5AN4gPCo=.3d9e5130-ae91-4570-9640-85c36faf6c1d@github.com>

On Tue, 14 Mar 2023 22:16:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes the bug which occurred when `Calendar.roll(WEEK_OF_YEAR)` rolled into a minimal first week with an invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> For example, Rolling _Monday, 30 December 2019_ by 1 week produced _Monday, 31 December 2018_, which is incorrect. This is because `WEEK_OF_YEAR` is rolled from 52 to 1, and the original `DAY_OF_WEEK` is 1. However, there is no Monday in week 1 of 2019. This is exposed when a future method calls `Calendar.complete()`, which eventually calculates a `fixedDate` with the invalid `WEEK_OF_YEAR` and `DAY_OF_WEEK` combo.
> 
> To prevent this, a check is added for rolls into week 1, which determines if the first week is minimal. If it is indeed minimal, then it is checked if  `DAY_OF_WEEK` exists in that week, if not, `WEEK_OF_YEAR` must be incremented by one.
> 
> After the fix, Rolling _Monday, 30 December 2019_ by 1 week produces _Monday, 7 January 2019_

This pull request has now been integrated.

Changeset: a324fa26
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a324fa2639d29f0c5b2928e7f15ec67e396c2648
Stats:     188 lines in 2 files changed: 186 ins; 0 del; 2 mod

8225641: Calendar.roll(int field) does not work correctly for WEEK_OF_YEAR

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Tue Apr  4 21:06:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Apr 2023 21:06:18 GMT
Subject: <i18n dev> Integrated: 8305400: ISO 4217 Amendment 175 Update
In-Reply-To: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
References: <y9rYoYaCVHLiwhu8ICNuTAxpqWA7DO6dHBjtEVVLrAo=.8b660491-b48e-4092-9e3f-0cc1e90e0b31@github.com>
Message-ID: <o8zgneyOJIPMuLPncXmFHjmlNHorRWeJ08ZOxfxP4bE=.d649b9e0-5b51-41ae-ab2c-366227601378@github.com>

On Fri, 31 Mar 2023 21:38:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review the ISO 4217 amendment 175 update.
> 
> There are no meaningful code changes, but the version number should be updated accordingly to be in sync.

This pull request has now been integrated.

Changeset: 7cf24d1c
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cf24d1c06142a3bab9cce5cd0ba34b8bbccf00f
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8305400: ISO 4217 Amendment 175 Update

Reviewed-by: naoto

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

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

From rriggs at openjdk.org  Tue Apr  4 21:10:07 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 4 Apr 2023 21:10:07 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v3]
In-Reply-To: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
Message-ID: <iBV9uRW4J5WamBUvy_DgeYxdElkFOGndcHnb47qxcpU=.1622f6b1-baad-4f8f-a3d3-1bd7b08e813d@github.com>

On Tue, 4 Apr 2023 20:15:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert static import of Character.*

LGTM; thanks for the updates

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1371788528

From ysatowse at openjdk.org  Wed Apr  5 01:22:30 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 5 Apr 2023 01:22:30 GMT
Subject: <i18n dev> Integrated: 8305113: (tz) Update Timezone Data to 2023c
In-Reply-To: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
References: <FD4mAAcj9MDDAVTWl15pzblw1LJr4y7Dk5fkykiolaE=.53546fca-4761-4f40-a640-cd6865f0e49f@github.com>
Message-ID: <CSfCOwf-MVivq29WBb4gTvs6K17Czwq3G-l_uTz0eEs=.fd155a3b-28a3-4872-8180-dbad58ff4d46@github.com>

On Fri, 31 Mar 2023 00:02:02 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Pleases review this PR. 
> The PR includes the following changes.
> - tzdata 2023c
> - Hack code to deal with Cairo's DST end, which is same as done in 2014g([JDK-8049343](https://bugs.openjdk.org/browse/JDK-8049343)).  To work around the the limitation of JSR 310 compiler, where the time 24:00 is recognized as 0:00 in the previous day.

This pull request has now been integrated.

Changeset: ed9592c6
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Andrew John Hughes <andrew at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed9592c6e81f82e2bf6508ce45ba15aad8232181
Stats:     330 lines in 18 files changed: 188 ins; 25 del; 117 mod

8305113: (tz) Update Timezone Data to 2023c

Reviewed-by: naoto, andrew, serb

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

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

From jlu at openjdk.org  Wed Apr  5 05:08:03 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Apr 2023 05:08:03 GMT
Subject: <i18n dev> RFR: 6241286: (cal) API: Calendar.DAY_OF_WEEK definition
 is wrong
Message-ID: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>

This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

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

Commit messages:
 - Redudant wording
 - Adjust doc

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

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

From duke at openjdk.org  Wed Apr  5 05:11:08 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 05:11:08 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <aQYAwMrrJcqk4ATxMUuvnQswH8AxHgye4L34iE3UTG4=.5c1f5324-846f-4833-8828-16b3c6067a46@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 105:

> 103:                                 case WINDOWS -> // Full path needed, DLL is in jre/bin
> 104:                                         new String[]{StaticProperty.javaHome()
> 105:                                                 + "\\bin\\sspi_bridge.dll"};

Suggestion:

                                        new String[]{ StaticProperty.javaHome()
                                                + "\\bin\\sspi_bridge.dll" };

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158027900

From jpai at openjdk.org  Wed Apr  5 05:45:17 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 5 Apr 2023 05:45:17 GMT
Subject: <i18n dev> RFR: 8305107: Emoji related binary properties in
 RegEx [v3]
In-Reply-To: <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
 <9_W23fwebJpTu-mWF0iLRqPZwZyGh127TQgZGtTg8aE=.1f203e4f-9f24-4216-a084-ea6277dfdc8e@github.com>
Message-ID: <H0Y8hgnWufqWjUkrIQ6ck7CvuRlq2nb-DMmcWsnV1AI=.bade62c4-95f9-47f7-b119-0ebf5c699bce@github.com>

On Tue, 4 Apr 2023 20:15:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert static import of Character.*

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13314#pullrequestreview-1372187317

From alanb at openjdk.org  Wed Apr  5 08:42:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 08:42:16 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:

> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
> 406:                 default -> new PlatformSocketOptions();

For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:

> 2880:                     elenNTFS = 36;           // total 36 bytes
> 2881:                 } else {                     // Extended Timestamp otherwise
> 2882:                     elenEXTT = 9;            // only mtime in cen

It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158209156
PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158206710

From rriggs at openjdk.org  Wed Apr  5 14:11:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:11:18 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <F8Jr6kezM5OXPwzssO4GuD_FFHdkruuTw955hwPJ9Kc=.fb2ede42-7b0d-4221-9c87-bfa0df005123@github.com>

On Wed, 5 Apr 2023 08:39:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.net/share/classes/jdk/net/ExtendedSocketOptions.java line 406:
> 
>> 404:                 case MACOS -> newInstance("jdk.net.MacOSXSocketOptions");
>> 405:                 case WINDOWS -> newInstance("jdk.net.WindowsSocketOptions");
>> 406:                 default -> new PlatformSocketOptions();
> 
> For another issue, but I assume this could be refactored to not need PlatformSocketOptions, in which case the mapping of OS name to implementation class would go away.

Created an issue to track the possible refactoring, will keep this change until then.
https://bugs.openjdk.org/browse/JDK-8305661

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158574021

From rriggs at openjdk.org  Wed Apr  5 14:22:29 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:22:29 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
Message-ID: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>

On Wed, 5 Apr 2023 08:37:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 2882:
> 
>> 2880:                     elenNTFS = 36;           // total 36 bytes
>> 2881:                 } else {                     // Extended Timestamp otherwise
>> 2882:                     elenEXTT = 9;            // only mtime in cen
> 
> It might be better to drop ZipFileSystem from this patch and instead create a bug to re-examine this code. I would have expected it use NFTS when the timestamp is beyond the range of an extended timestamp. It shouldn't be looking at the current OS name.

Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
Will revert.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158587949

From rriggs at openjdk.org  Wed Apr  5 14:32:03 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 14:32:03 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v2]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert chanes to ZipFileSystem to defer refactoring.
  Reformatted expression to match switch expression formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/72cff1ed..aadf5bbd

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

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

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

From alanb at openjdk.org  Wed Apr  5 14:36:16 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 5 Apr 2023 14:36:16 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v2]
In-Reply-To: <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <gTlAzwEeyKvd1VE16bMzkUhtdXY62__24KolZ7zLwmU=.5b249c3d-1d54-4362-b92e-011f38651d91@github.com>
 <GKbr8qOEym791fnbOadgQhjW8wVFdWzXFj7iLXFgxv0=.3b848e97-7d14-4f51-969c-f54d3fc31aac@github.com>
Message-ID: <hoTsG4Le90HdJbdN-yAOFAYCjwwLn4avbyJBS6VViR8=.7e769d74-a829-4621-8229-8722dc7c50df@github.com>

On Wed, 5 Apr 2023 14:18:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Created [JDK-8305662](https://bugs.openjdk.org/browse/JDK-8305662) to track refactoring.
> Will revert.

Thanks, you can revert the qualified export in module-info and the additional grant in default.policy too.

The interesting thing about this PR is that each change begs the question on whether the code should be refactored, that would take time of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158609098

From duke at openjdk.org  Wed Apr  5 14:45:15 2023
From: duke at openjdk.org (ExE Boss)
Date: Wed, 5 Apr 2023 14:45:15 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v2]
In-Reply-To: <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <di3Ff8SfMiCj2gtD3VVcz3f1QHTEShmlProg9qzQza4=.0b3d8874-c6dc-4809-951a-429120f064fc@github.com>
Message-ID: <Osp9DN7X8Ep5PtaZ0V8E7kf3vDZRpxHnrsKmj4NAjPg=.e2fadf20-cd2e-4596-a78d-73e75af04eab@github.com>

On Wed, 5 Apr 2023 14:32:03 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert chanes to ZipFileSystem to defer refactoring.
>   Reformatted expression to match switch expression formatting.

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 103:

> 101:                                         "/usr/lib/sasl2/libgssapiv2.2.so",
> 102:                                 };
> 103:                                 case WINDOWS -> new String[]{ // Full path needed, DLL is in jre/bin

Suggestion:

                                case WINDOWS -> new String[]{
                                        // Full path needed, DLL is in jre/bin

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1158620967

From rriggs at openjdk.org  Wed Apr  5 15:48:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 5 Apr 2023 15:48:02 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v3]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Backout unneeded changes to module-info and default.policy.
  Fixup formatting.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/aadf5bbd..5546b824

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

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

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

From naoto at openjdk.org  Wed Apr  5 16:07:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Apr 2023 16:07:49 GMT
Subject: <i18n dev> Integrated: 8305107: Emoji related binary properties in
 RegEx
In-Reply-To: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
References: <WioC_XG7VMuwStzc1qJVikIJrDq1rLI7-3yVb2FIO44=.b8cf0480-4d94-4062-8211-77f81b99f617@github.com>
Message-ID: <QpPuWK1bPRiJjP1X4hE3j32MZm-kaHcUvW9--CdwY14=.e3b1268c-b3c9-44a0-a504-a5dbfc30be56@github.com>

On Mon, 3 Apr 2023 22:58:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Introducing new regex constructs that match those 6 new Unicode Emoji properties implemented in the `Character` class (https://bugs.openjdk.org/browse/JDK-8303018). A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: ee302335
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee3023359caed3be4fe4cd829f04ede99d17ae86
Stats:     55 lines in 3 files changed: 49 ins; 3 del; 3 mod

8305107: Emoji related binary properties in RegEx

Reviewed-by: iris, rriggs, jpai

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

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

From naoto at openjdk.org  Wed Apr  5 16:09:39 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 5 Apr 2023 16:09:39 GMT
Subject: <i18n dev> Integrated: 8304982: Emit warning for removal of
 `COMPAT` provider
In-Reply-To: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
References: <BfmvB3sZkMyqHAY1zWg-_Bx8ordTfd9XLIiymMxj5Mc=.8bdfcfbd-573a-4336-9e87-ae3981e8a708@github.com>
Message-ID: <oxEnaA7Trmwprk_xcnZ-x6rUt5U2hGwqkC7i_ngIK_s=.2290197f-d762-4f55-ad91-a9cce7861ad1@github.com>

On Mon, 3 Apr 2023 16:47:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a precursor to the future removal of the `COMPAT` locale data provider. Before the actual removal of the provider, warn the users who explicitly specify `COMPAT` at the command line in order for their smooth migration to CLDR. A CSR has also been drafted.

This pull request has now been integrated.

Changeset: 44f33ad1
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/44f33ad1a9617fc23864c9ba5f063b3fc2f1e18c
Stats:     92 lines in 4 files changed: 83 ins; 1 del; 8 mod

8304982: Emit warning for removal of `COMPAT` provider

Reviewed-by: alanb

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

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

From iris at openjdk.org  Wed Apr  5 16:27:21 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 5 Apr 2023 16:27:21 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <yNqK4eZqzxXtzGKEYf4MbbAaVHOB0Y785UAn1LuTvcs=.525903c3-871b-48b0-ab80-36917b999098@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1373282111

From naoto at openjdk.org  Thu Apr  6 23:15:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Apr 2023 23:15:45 GMT
Subject: <i18n dev> RFR: 6241286: (cal) API: Calendar.DAY_OF_WEEK
 definition is wrong
In-Reply-To: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
References: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
Message-ID: <ocyiBNq0sAqYa6y-6h0FqRElo4lRNuWS3YzN1HfOts0=.8671988d-fafd-468b-b509-e9b6e8da1d98@github.com>

On Mon, 3 Apr 2023 21:56:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13311#pullrequestreview-1375674071

From jpai at openjdk.org  Fri Apr  7 05:59:46 2023
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 7 Apr 2023 05:59:46 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <P8j4Sb_G26s5EnX3hMY-OkBfW7izQLv1uflhTkdV6sM=.1688b147-9689-4eb1-aebb-9cc0a83b1cd8@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

Looks ok to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13335#pullrequestreview-1375851004

From aturbanov at openjdk.org  Fri Apr  7 08:09:46 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 7 Apr 2023 08:09:46 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v3]
In-Reply-To: <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
 <8J4TmE1-gK_TAAZO7vdv-a9Oc5x65tRaTUMGZzQAleM=.6f65fb06-bc91-4dd1-aa40-92b8fb973307@github.com>
Message-ID: <MoRaAV2bfkpmtql8WLLyCK7oZuW7oIWJDzLSgmBAEvU=.e90d7846-8e32-4dba-a63e-1d9a2d69fc7e@github.com>

On Wed, 5 Apr 2023 15:48:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
>> This PR exports jdk.internal.util to:
>>  - java.prefs,
>>  - java.security.jgss,
>>  - java.smartcardio,
>>  - jdk.charsets,
>>  - jdk.net,
>>  - jdk.zipfs
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Backout unneeded changes to module-info and default.policy.
>   Fixup formatting.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 299:

> 297:         String platformFactory = switch (OperatingSystem.current()) {
> 298:             case WINDOWS -> "java.util.prefs.WindowsPreferencesFactory";
> 299:             case MACOS ->  "java.util.prefs.MacOSXPreferencesFactory";

Suggestion:

            case MACOS -> "java.util.prefs.MacOSXPreferencesFactory";

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13335#discussion_r1160525650

From duke at openjdk.org  Fri Apr  7 08:58:58 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 08:58:58 GMT
Subject: <i18n dev> RFR: 8304245: Speed up CharacterData.of by avoiding
 bit shifting in the latin1 fast-path test [v2]
In-Reply-To: <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
 <4LTvtBGCy0mN2jf74mViiDZ9ci8VQS44uA-hXHjV0KI=.c9715dc2-1d87-4f49-ac4c-ff6fa25bb583@github.com>
Message-ID: <x-bCJ3nQNK3_HAfPx7YPN_Wh0PLOT2Gu56l4tgX1_Ks=.0ba11267-787e-4ff3-9def-73af07e2fc55@github.com>

On Wed, 15 Mar 2023 14:31:03 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

>> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
>> 
>> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
>> 
>> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
>> 
>> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
>> 
>> Baseline:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
>> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
>> 
>> PR:
>> 
>> 
>> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
>> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
>> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op
>
> Eirik Bjorsnos has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update StringLatin1.canEncode to sync with same test in CharacterData.of

I'm withdrawing this PR since its merits seem suspect.

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

PR Comment: https://git.openjdk.org/jdk/pull/13040#issuecomment-1500087677

From duke at openjdk.org  Fri Apr  7 08:59:00 2023
From: duke at openjdk.org (Eirik Bjorsnos)
Date: Fri, 7 Apr 2023 08:59:00 GMT
Subject: <i18n dev> Withdrawn: 8304245: Speed up CharacterData.of by
 avoiding bit shifting in the latin1 fast-path test
In-Reply-To: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
References: <-mhNL4ascuO9KdhZ-L0jRng9dxvp78p_FWNrg6VUaKo=.1f6c5ec1-cde3-4acd-a2c4-c2fd0933c480@github.com>
Message-ID: <OILXrp8R1NJN7jsogPgyH5uw8triGaIB0vL0qJU0WfY=.e2d5522d-5ae0-414a-9f40-9f5b89c20b07@github.com>

On Wed, 15 Mar 2023 11:26:21 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> By avoiding a bit shift operation for the latin1 fast-path test, we can speed up the `java.lang.CharacterData.of` method by ~25% for latin1 code points.
> 
> The latin1 test is currently implemented as `ch >>> 8 == 0`.  We can replace this with `ch >= 0 && ch <= 0xFF` for a noticable performance gain (especially for Latin1 code points):
> 
> This method is called frequently by various property-determining methods in `java.lang.Character` like `isLowerCase`, `isDigit` etc, so one should expect improvements for all these methods.
> 
> Performance is tested using the `Characters.isDigit` benchmark using the digits '0' (decimal 48, in CharacterDataLatin1) and '\u0660' (decimal 1632, in CharacterData00):
> 
> Baseline:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.870 ? 0.011  ns/op
> Characters.isDigit         1632  avgt   15  2.168 ? 0.017  ns/op
> 
> PR:
> 
> 
> Benchmark           (codePoint)  Mode  Cnt  Score   Error  Units
> Characters.isDigit           48  avgt   15  0.654 ? 0.007  ns/op
> Characters.isDigit         1632  avgt   15  2.032 ? 0.019  ns/op

This pull request has been closed without being integrated.

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

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

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

On Tue, 4 Apr 2023 16:07:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

These?should rethrow all?`Error`s:

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

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

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

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

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

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

Suggestion:

        } catch (RuntimeException | Error ex) {

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

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

Suggestion:

        } catch (RuntimeException | Error ex) {

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

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

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

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

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

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

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

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

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

From rriggs at openjdk.org  Fri Apr  7 14:24:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Apr 2023 14:24:37 GMT
Subject: <i18n dev> RFR: 8304911: Use OperatingSystem enum in some
 modules [v4]
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <Usevw300y_mQRvFgSwqQlXsxI8LHs0hb38Xk6PuTx1g=.64512eff-175f-4da7-a1e2-34afd8936b3c@github.com>

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove errant space

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13335/files
  - new: https://git.openjdk.org/jdk/pull/13335/files/5546b824..b9267942

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

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

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

From dnguyen at openjdk.org  Fri Apr  7 17:06:47 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 7 Apr 2023 17:06:47 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v4]
In-Reply-To: <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
Message-ID: <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>

On Tue, 21 Mar 2023 21:07:42 GMT, Jeremy <duke at openjdk.org> wrote:

>> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
>> 
>> In short:
>> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
>> 
>> I left more detailed notes here about the proposed resolution:
>> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
>> 
>> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?
>
> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8303950: adding unit test for legacy window behavior
>   
>   This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
>   
>   This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
>   
>   In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.

src/java.desktop/share/classes/java/awt/Window.java line 3953:

> 3951:                 if (gg instanceof Graphics2D) {
> 3952:                     gg.setColor(getBackground());
> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));

Why was the import for SunHints added if the only edit to this file was adding a space?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160837035

From jlu at openjdk.org  Fri Apr  7 17:27:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 7 Apr 2023 17:27:40 GMT
Subject: <i18n dev> RFR: 6218123: (cal) API: Spec for GregorianCalendar
 constructors and Calendar getInstance is inconsistent.
Message-ID: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>

The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 

This PR updates the javadoc to make this apparent.

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

Commit messages:
 - Adjust wording
 - Document exceptions

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

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

From dnguyen at openjdk.org  Fri Apr  7 18:41:46 2023
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 7 Apr 2023 18:41:46 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v4]
In-Reply-To: <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
 <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
Message-ID: <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>

On Fri, 7 Apr 2023 17:03:56 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> Jeremy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8303950: adding unit test for legacy window behavior
>>   
>>   This test passes in the current JDK. The test criteria don't really reflect a rational expected behavior; they just reflect the current status quo.
>>   
>>   This currently fails in this JDK-8303950 branch (using the new proposed AWTPaintManager), which indicates we've changed behavior.
>>   
>>   In this case it's "window 4" that's failing. We used to get a mostly blue background, and now we're getting a background that's mostly red with a little blue. This isn't necessarily a bad thing; this failure is just documenting a change.
>
> src/java.desktop/share/classes/java/awt/Window.java line 3953:
> 
>> 3951:                 if (gg instanceof Graphics2D) {
>> 3952:                     gg.setColor(getBackground());
>> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
> 
> Why was the import for SunHints added if the only edit to this file was adding a space?

Nevermind I saw this wrong when looking through the commit history.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160887595

From duke at openjdk.org  Fri Apr  7 19:37:45 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 7 Apr 2023 19:37:45 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v5]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <REngv82_1yUCb5D6bJuYXlQTT-JNNXCcQSa2W391uis=.62a1482c-cbad-4f04-969f-7dcf13dbcd7b@github.com>

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

 - 8303950: adding opaque white window under test windows
   
   Since the bottom two windows are translucent: it will help safeguard test results if they're positioned above an opaque white background.
   
   Also adding a couple of text lines to the windows to help explain why they rendered the way they did.
 - 8303950: rolling back unnecessary
   
   This is should have been part of 6a3a9b42bb705273e1ed9b1de0d04370e69c43ca, which rolled back 1991fdac5dbf76ddaf73cc78a9f7c38370c9674c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/bd81761a..c0d80dc6

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

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

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

From duke at openjdk.org  Fri Apr  7 19:41:42 2023
From: duke at openjdk.org (Jeremy)
Date: Fri, 7 Apr 2023 19:41:42 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v4]
In-Reply-To: <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
 <JiA9g77J_RfdJVKDwbj8AggL3tBMhGw1-SGgfTMZKF0=.0d92801b-2e95-4a95-8436-a35e3d8ee15d@github.com>
 <ckIGmBjoUMn47vduBlOgf9J0ur0AU3a88FKfKdx3o8w=.f198c4f2-8515-4d31-8d6a-defba1da8aa7@github.com>
 <sEPL7Cy_059ZuSSL18dUdFCJVy8WkOSIxijJ1n1W0zc=.87aa34bf-09e8-43c0-afa7-cf79c96762b6@github.com>
Message-ID: <i8T8TLDXtke9ScDQoP5VqOxjY9OIQAJIhTm937Qfqnc=.7d181894-d3cb-4360-a44f-6980ea26bfd5@github.com>

On Fri, 7 Apr 2023 18:39:03 GMT, Damon Nguyen <dnguyen at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Window.java line 3953:
>> 
>>> 3951:                 if (gg instanceof Graphics2D) {
>>> 3952:                     gg.setColor(getBackground());
>>> 3953:                     ((Graphics2D) gg).setComposite(AlphaComposite.getInstance(AlphaComposite.SRC));
>> 
>> Why was the import for SunHints added if the only edit to this file was adding a space?
>
> Nevermind I saw this wrong when looking through the commit history.

Thanks for checking, though. I just pushed a change to roll back this diffs. https://github.com/openjdk/jdk/pull/12993/commits/f369ccde6d73537948d6f5007ae5d0a2b847d8ac

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12993#discussion_r1160921482

From naoto at openjdk.org  Fri Apr  7 20:27:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 7 Apr 2023 20:27:43 GMT
Subject: <i18n dev> RFR: 6218123: (cal) API: Spec for GregorianCalendar
 constructors and Calendar getInstance is inconsistent.
In-Reply-To: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
References: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
Message-ID: <r49Q2F95HGDOkjKZ50v0XLfqDCa-Q8SdapEpI_cNHoU=.285627dc-c353-426d-a742-216673732aad@github.com>

On Mon, 3 Apr 2023 21:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 
> 
> This PR updates the javadoc to make this apparent.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13310#pullrequestreview-1376554740

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

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

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

  Clean up Error handling

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

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

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

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

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

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

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

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

Changing

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

Changing

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

Changing

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

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

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

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

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

  Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.

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

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

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

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

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

From stsypanov at openjdk.org  Mon Apr 10 14:01:53 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 10 Apr 2023 14:01:53 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v3]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

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

 - Merge branch 'master' into dtfb
 - 8300818: Add benchmark
 - 8300818: Add benchmark
 - Revert irrelevant change
 - Merge branch 'master' into dtfb
 - Improve padding of DateTimeFormatter

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/322ae9b4..b40de5a8

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

  Stats: 497235 lines in 5533 files changed: 277601 ins; 160858 del; 58776 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

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

From rriggs at openjdk.org  Mon Apr 10 15:53:54 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 10 Apr 2023 15:53:54 GMT
Subject: <i18n dev> Integrated: 8304911: Use OperatingSystem enum in some
 modules
In-Reply-To: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
References: <jj_IKbX0Sg786mAK8C_0llFTEK4PH4as0J4YIfRlVVc=.083c39c3-f90f-4d3e-9c5e-1c08a14b850d@github.com>
Message-ID: <cYBk3ZVUnDppbIZGj79ENgNctV4SjMCgrAXF1Jf_Sd8=.150e8aac-3658-4a6e-876c-9c3147847104@github.com>

On Tue, 4 Apr 2023 19:22:48 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the addition of `jdk.internal.util.OperatingSystem` references to the system property `os.name` can be replaced.
> This PR exports jdk.internal.util to:
>  - java.prefs,
>  - java.security.jgss,
>  - java.smartcardio,
>  - jdk.charsets,
>  - jdk.net,
>  - jdk.zipfs

This pull request has now been integrated.

Changeset: ba90dc77
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba90dc77958c399e4e1fc3c4999dd76680480c7b
Stats:     120 lines in 12 files changed: 20 ins; 50 del; 50 mod

8304911: Use OperatingSystem enum in some modules

Reviewed-by: naoto, lancea, iris, jpai

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

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

From stsypanov at openjdk.org  Mon Apr 10 18:07:47 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 10 Apr 2023 18:07:47 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <EnY_awqZn5wCuzEeNF5-Ano7LX--rxUVH4Ycc8Mbzgw=.b26ff0a2-4c4c-48df-af4d-bdcf3f01a4f0@github.com>
Message-ID: <998qY75KRrTd50nagFo5wLqPOZ7Ka1j4vaKuFnd7lUk=.faf5d4d5-6f79-495b-a417-ab5b653c1e18@github.com>

On Mon, 13 Mar 2023 19:24:38 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> fyi, you might want to wait for https://github.com/openjdk/jdk/pull/12728

@RogerRiggs mentioned PR was merged without suggested repeat-into-position method, so I this code remains as is.

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

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1502128631

From jlu at openjdk.org  Mon Apr 10 21:50:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Apr 2023 21:50:19 GMT
Subject: <i18n dev> Integrated: 6218123: (cal) API: Spec for
 GregorianCalendar constructors and Calendar getInstance is inconsistent.
In-Reply-To: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
References: <Y6sYxUG7fkJL1Lsu4JNIzzbLtwU8BPcm59_QsiURv4o=.1e74a01f-5950-45cc-acec-0217e7fb9094@github.com>
Message-ID: <wR2ig9yHOXuBEu3pQANdvKZEfqTmC6xCVcfN09IOeAM=.5a363866-fde0-4b58-9908-94677e9867b2@github.com>

On Mon, 3 Apr 2023 21:56:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> The GregorianCalendar constructors and Calendar.getInstance() methods that take TimeZone or Locale throw a NullPointerException if any values are null. 
> 
> This PR updates the javadoc to make this apparent.

This pull request has now been integrated.

Changeset: 42965d39
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42965d390c2062c74e2fb9d8125a16513042e857
Stats:     6 lines in 2 files changed: 6 ins; 0 del; 0 mod

6218123: (cal) API: Spec for GregorianCalendar constructors and Calendar getInstance is inconsistent.

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Mon Apr 10 21:51:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 10 Apr 2023 21:51:17 GMT
Subject: <i18n dev> Integrated: 6241286: (cal) API: Calendar.DAY_OF_WEEK
 definition is wrong
In-Reply-To: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
References: <Fe3PdyvyvFi_GNbxowh7Ps4ZhCLcqO2MEmiLD3bddyg=.8e8e6669-6549-49fe-93db-a837427c3515@github.com>
Message-ID: <PdNnYngxU1q2RC83RT8euIYYOJx44ybyzhQkJMG_8wU=.04096e05-81be-4d26-ba2d-a875339ba76c@github.com>

On Mon, 3 Apr 2023 21:56:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the Calendar.DAY_OF_WEEK documentation to make it clear that the field accepts _any_ value if the calendar is lenient and then normalizes it. Only if the calendar is non-lenient, will the field accept only one of SUNDAY ... SATURDAY.

This pull request has now been integrated.

Changeset: 2aeb0e52
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2aeb0e5267fc836a06b8ca2e67ec7550bb372163
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

6241286: (cal) API: Calendar.DAY_OF_WEEK definition is wrong

Reviewed-by: naoto

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

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

From duke at openjdk.org  Tue Apr 11 04:18:58 2023
From: duke at openjdk.org (Jeremy)
Date: Tue, 11 Apr 2023 04:18:58 GMT
Subject: <i18n dev> RFR: JDK-8303950: [macos]Translucent Windows Flicker
 on Repaint [v6]
In-Reply-To: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
References: <vJljFxJi_SkKopPEAFTkOKyovVUp2LzYK0gKCGvIBp4=.e24c68ba-6863-48b8-8fc7-8729ed3c404c@github.com>
Message-ID: <Uwu1lFS9HLngFDFSDolfC9MYHNI3Qnww6Clg8ReEYpo=.0cb03b44-4d44-4ee7-95cf-dc2de22e18d5@github.com>

> I'm confident about the new test case for this ticket, but the resolution is more invasive than I'd like. (It works, though.)
> 
> In short:
> This introduces a new RenderingHint (in SunHints) to bypass the call in Window to `gg2d.fillRect(0, 0, getWidth(), getHeight());`
> 
> I left more detailed notes here about the proposed resolution:
> https://github.com/openjdk/jdk/commit/1991fdac5dbf76ddaf73cc78a9f7c38370c9674c
> 
> I'm open to suggestions if anyone has a more elegant proposal to prevent the monitor from refreshing too soon?

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

  8303950: avoid System.exit(1)
  
  mrserb recommended against this in a separate PR
  
  https://github.com/openjdk/jdk/pull/13408#discussion_r1162182212

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12993/files
  - new: https://git.openjdk.org/jdk/pull/12993/files/c0d80dc6..d9c881e2

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

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

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

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

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

From mchhipa at openjdk.org  Wed Apr 12 16:43:27 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Wed, 12 Apr 2023 16:43:27 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
Message-ID: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>

Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
java/lang/Character/CharPropTest.java
java/lang/Character/CheckProp.java
java/lang/Character/CheckScript.java
java/lang/Character/CheckUnicode.java
java/lang/Character/UnicodeBlock/CheckBlocks.java
java/lang/Character/UnicodeCasingTest.java
java/lang/String/SpecialCasingTest.java
java/lang/String/UnicodeCasingTest.java
java/text/Normalizer/ConformanceTest.java

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

Commit messages:
 - JDK-8305904: java/lang/Character, java/lang/String and java/text/Normalizer tests read the unicode data files from src directories.

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

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

From rriggs at openjdk.org  Wed Apr 12 17:44:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:44:47 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v3]
In-Reply-To: <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
Message-ID: <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>

On Mon, 10 Apr 2023 14:01:53 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' into dtfb
>  - 8300818: Add benchmark
>  - 8300818: Add benchmark
>  - Revert irrelevant change
>  - Merge branch 'master' into dtfb
>  - Improve padding of DateTimeFormatter

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 148:

> 146:         return YEAR_FORMATTER.format(now);
> 147:     }
> 148: 

There benchmarks are run 4 time each because of the @Param that are defined for the pre-existing tests.
I don't know if jmh can be annotated to ignore the params; but to avoid wasting resources create a separate jmh source file for thees new tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1164450924

From rriggs at openjdk.org  Wed Apr 12 17:44:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 12 Apr 2023 17:44:38 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
Message-ID: <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>

On Fri, 24 Mar 2023 19:28:57 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Meant that you should verify that something like this, which just add a little padding, doesn't regress with your changes: 
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>     .appendLiteral("Year:")
>>     .padNext(5)
>>     .appendValue(ChronoField.YEAR)
>>     .toFormatter();
>> ... 
>> dtf.format(LocalDateTime.now());
>> 
>> And similar for effectively no padding (`.padNext(4)` in the above example). As this API might often be used to ensure short 2-4 char fields are correctly padded I think it's important that we're not adding overhead to such use cases.
>
> Added benchmark for this

Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1164453452

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

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

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

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

On Sat, 8 Apr 2023 15:51:36 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

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

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

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

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

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

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

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

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

From aturbanov at openjdk.org  Wed Apr 12 20:54:02 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 12 Apr 2023 20:54:02 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <FaAsa2tK9mqgLaPcRVKNTaAWdKkzr37TmI1bcVH6Eps=.a575aa4b-bc90-4947-8bab-7dde4b180575@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

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

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

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

Can it be made `final` ?

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

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

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

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

Couple of unused imports

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

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

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

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

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

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

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

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

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

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

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

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

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

Suggestion:

    @Override

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

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

Suggestion:

    public String toString() {

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

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

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

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

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

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

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

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

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

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

Updating comments

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

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

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

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

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

Changing

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

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

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

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

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

Changing

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

Changing

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

Changing

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

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

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

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

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

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

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

same

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

same

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

One of those IntelliJ things - ugh.

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

same

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

Changing

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

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

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

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

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

  Recommended changes

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

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

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

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

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

From rriggs at openjdk.org  Thu Apr 13 13:31:48 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 13:31:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v57]
In-Reply-To: <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <ujzp-bNGMl7s1WFkQl7BetZb_GlEra_QtdNkeTYnZbM=.40cb2cfc-a644-40bb-927d-474d591c96dd@github.com>
Message-ID: <9xC6I_K4jt0nkOfBbBxhDMDJ2rdBJuuAKupoW-rKtrI=.9cd35742-ca55-4ad4-aa78-87ae4fc7b2e1@github.com>

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

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

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

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

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

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

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

  Remove preview feature on package private java.util.Digits

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

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

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

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

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

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

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

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

Removing preview feature.

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

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

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

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

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

  HexDigits -> OctalDigits

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

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

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

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

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

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

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

Suggestion:

         * Singleton instance of OctalDigits.

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

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

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

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

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

Nice catch

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

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

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

On Thu, 13 Apr 2023 13:36:57 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

Typo here? "This is specialization is done"

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

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

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

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

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

removing "is"

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

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

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

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

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

  Typo

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

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

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

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

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

From naoto at openjdk.org  Thu Apr 13 17:41:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 17:41:33 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <TI_RZzu0tt9vOe48e932gnCZUZlbCiary4Gu6mVABZc=.2d9259cb-fd03-45ac-a161-0bd6bedb126c@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Hi Mahendra,

What's the point of having the Unicode data files duplicate? That would cause a possible mismatch between the files between src and test.

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

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507365030

From rriggs at openjdk.org  Thu Apr 13 17:55:37 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 13 Apr 2023 17:55:37 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <HmOoAQ_gqY_84pfDJdScCGJa9iSLPA6AatLfOIIX9aU=.189361bf-a1c2-4970-83ee-66951c924c3f@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Are you aware of the uses in the makefiles?  

make/modules/java.base/Gendata.gmk
make/modules/java.base/gendata/GendataBreakIterator.gmk
make/modules/java.base/gensrc/GensrcCharacterData.gmk

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

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507386116

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

On Wed, 12 Apr 2023 19:02:22 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 75 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Change MAX_INDY_CONCAT_ARG_SLOTS to be updatable.
>  - Clean up Error handling
>  - Recommended changes
>  - RuntimeException is the only exception type that can is deduced from a lambda.
>  - Update combine example
>  - Merge branch 'master' into 8285932
>  - Update StringTemplate.combine javadoc
>  - Requested review changes.
>  - Clean up list construction
>  - ... and 65 more: https://git.openjdk.org/jdk/compare/bc151633...f1b187a1

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

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

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

typo: ahd

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

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

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

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

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

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

On Thu, 13 Apr 2023 17:09:13 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

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

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

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

Not related to StringTemplates; could be left as is.

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

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

From naoto at openjdk.org  Thu Apr 13 18:14:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 18:14:34 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <4JLfFmxw_NNLt6ArRgxmxCl7cSfmj0ljX6k77ZDHaac=.69c4ee18-b584-4018-8be7-8ea6258ffb4d@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

Missed that the intended change is not duplicating but moving from src->test. No this is not correct.

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

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1507411392

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

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

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

Will fix.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  Stats: 54 lines in 10 files changed: 30 ins; 23 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

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

On Thu, 13 Apr 2023 19:45:59 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes

Core library files look good to me.

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.org  Thu Apr 13 20:43:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 20:43:22 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0
Message-ID: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>

Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

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

Commit messages:
 - v42 -> v43 in README, .md files
 - release-43
 - Removed sr-Latn (https://unicode-org.atlassian.net/browse/CLDR-16449)
 - release-43-beta5
 - release-43-beta4
 - release-43-beta3
 - release-43-beta1
 - release-43-beta0
 - Fixing IncludeLocalesPluginTest.java not to include below `basic` locales
 - release-43-alpha2
 - ... and 5 more: https://git.openjdk.org/jdk/compare/92521b10...d61ccf0f

Changes: https://git.openjdk.org/jdk/pull/13469/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13469&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8296248
  Stats: 209680 lines in 1036 files changed: 199351 ins; 2906 del; 7423 mod
  Patch: https://git.openjdk.org/jdk/pull/13469.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13469/head:pull/13469

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

From duke at openjdk.org  Thu Apr 13 20:50:37 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 13 Apr 2023 20:50:37 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>

On Thu, 13 Apr 2023 20:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

make/data/cldr/common/main/ken.xml line 19:

> 17: 	</localeDisplayNames>
> 18: 	<characters>
> 19: 		<exemplarCharacters>[a ? ? ? b c d e ? ? ? ? {?\u0301} {?\u0300} {?\u030C} f g {gb} {gh} h i ? {?\u0301} {?\u0300} {?\u030C} j k {kp} m n {ny} ? o ? ? ? ? {?\u0301} {?\u0300} {?\u030C} p r s t u ? ? ? ? {?\u0301} {?\u0300} {?\u030C} w y]</exemplarCharacters>

@naotoj  this is in common/main but not at basic level??is this intentional?

make/data/cldr/common/properties/coverageLevels.txt line 115:

> 113: sq ;	modern ;	Albanian
> 114: sr ;	modern ;	Serbian
> 115: sr_Latn ;	modern ;	Serbian (Latin)

@naotoj BTW this was fixed

src/java.base/share/legal/cldr.md line 1:

> 1: ## Unicode Common Local Data Repository (CLDR) v43

BTW the license is now just named `LICENSE` in the repo starting with v44

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

PR Review: https://git.openjdk.org/jdk/pull/13469#pullrequestreview-1384183612
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009340
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166009761
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166010264

From duke at openjdk.org  Thu Apr 13 20:56:31 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Thu, 13 Apr 2023 20:56:31 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
Message-ID: <2XosFvSf2Grsbxdvt49z4d5JaA4qkgjcJ80kdRsqriU=.b40fb4cc-5ffe-426e-9130-a3a128cc20de@github.com>

On Thu, 13 Apr 2023 20:47:39 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> Marked as reviewed by srl295 at github.com (no known OpenJDK username).

`@srl295 (no known openjdk.org user name / role)` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13469#issuecomment-1507597408

From naoto at openjdk.org  Thu Apr 13 21:42:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 21:42:46 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0
In-Reply-To: <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <zbwxS7_hkDmaDj1DO8wSf9k075dQmeQ8yd-P1YI5hB4=.a110cf9f-3588-4c57-9917-467cc9a31ad2@github.com>
Message-ID: <KxrbbEJ6ISiH2cwrp0OqbwhU41OpnBuBKoE9r-rZBm0=.7c8ce9b4-a662-4031-9fc5-6154a24faacb@github.com>

On Thu, 13 Apr 2023 20:46:10 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> make/data/cldr/common/main/ken.xml line 19:
> 
>> 17: 	</localeDisplayNames>
>> 18: 	<characters>
>> 19: 		<exemplarCharacters>[a ? ? ? b c d e ? ? ? ? {?\u0301} {?\u0300} {?\u030C} f g {gb} {gh} h i ? {?\u0301} {?\u0300} {?\u030C} j k {kp} m n {ny} ? o ? ? ? ? {?\u0301} {?\u0300} {?\u030C} p r s t u ? ? ? ? {?\u0301} {?\u0300} {?\u030C} w y]</exemplarCharacters>
> 
> @naotoj  this is in common/main but not at basic level??is this intentional?

JDK keeps CLDR sources intact. On building JDK, .xml files are transformed into ResourceBundles and those not at the basic level are filtered out.

> make/data/cldr/common/properties/coverageLevels.txt line 115:
> 
>> 113: sq ;	modern ;	Albanian
>> 114: sr ;	modern ;	Serbian
>> 115: sr_Latn ;	modern ;	Serbian (Latin)
> 
> @naotoj BTW this was fixed

Yes. The patch before was removed with this commit: https://github.com/openjdk/jdk/pull/13469/commits/0e3456c8924960dc0bc488b08b9763bd08557a68

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055276
PR Review Comment: https://git.openjdk.org/jdk/pull/13469#discussion_r1166055288

From naoto at openjdk.org  Thu Apr 13 23:45:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Apr 2023 23:45:45 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0 [v2]
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  Short ID test for "America/Ciudad_Juarez"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13469/files
  - new: https://git.openjdk.org/jdk/pull/13469/files/d61ccf0f..7211ffd3

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

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

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

From mchhipa at openjdk.org  Fri Apr 14 13:48:33 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Apr 2023 13:48:33 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <KvCPCLYFl-awg4_XcZcY7AM8w4X1udmd0gFtlm-VzIY=.4f57b572-4f11-445d-8bbf-df2e1c7b2391@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

> 

Hi Roger,
 Sorry I was not aware of uses in makefiles. I will undo the changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1508531123

From mchhipa at openjdk.org  Fri Apr 14 14:38:44 2023
From: mchhipa at openjdk.org (Mahendra Chhipa)
Date: Fri, 14 Apr 2023 14:38:44 GMT
Subject: <i18n dev> Withdrawn: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <wz3luoBfRT9Wdi4vE-Gvhi3al_0emxid1w0eaeSjKzo=.c85b7cbd-774b-42db-970e-68493484f825@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

This pull request has been closed without being integrated.

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

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

From joehw at openjdk.org  Fri Apr 14 15:58:34 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 14 Apr 2023 15:58:34 GMT
Subject: <i18n dev> RFR: 8296248: Update CLDR to Version 43.0 [v2]
In-Reply-To: <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
 <bdQ09nn5FNT4PShAwGqWV6L9gBv5yt7VRNAtpUXshHE=.f4ae637a-f077-4fa6-8b86-2b26589b9178@github.com>
Message-ID: <6KyTNUsXdQvIGrCtUZSRdZDZ22yaBzluKwrpgc6PUwY=.6264c04e-aed7-4b56-addb-2d112b7b1b95@github.com>

On Thu, 13 Apr 2023 23:45:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Short ID test for "America/Ciudad_Juarez"

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13469#pullrequestreview-1385726554

From jlu at openjdk.org  Fri Apr 14 20:33:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 14 Apr 2023 20:33:29 GMT
Subject: <i18n dev> RFR: 4737887: (cal) API: Calendar methods taking field
 should document exceptions
Message-ID: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>

Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.

This PR adds a clause to the class description to make the above apparent.

`Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
`Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

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

Commit messages:
 - Replace method exceptions with a general clause in class description
 - Readjust add and roll to throw IAE (since jCal is private and cannot be specified)
 - Adjust add and roll
 - Adjust Add and Roll spec to use existing wording
 - Add exceptions to Calendar methods

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

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

From naoto at openjdk.org  Fri Apr 14 21:11:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 14 Apr 2023 21:11:34 GMT
Subject: <i18n dev> RFR: 4737887: (cal) API: Calendar methods taking
 field should document exceptions
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <5Mq7KMkqWvLrLu-fPUSxT40qJcKx5MwB7qIoCEgTAhU=.163f98fa-924a-4780-bb21-946f981c2612@github.com>

On Wed, 29 Mar 2023 22:04:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

Looks good, Justin. Nit: copyright year -> 2023

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13234#pullrequestreview-1386182763

From jlu at openjdk.org  Fri Apr 14 21:30:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 14 Apr 2023 21:30:25 GMT
Subject: <i18n dev> RFR: 4737887: (cal) API: Calendar methods taking
 field should document exceptions [v2]
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <9Ki0whashS3r96TLtxDBMHN0wcAggwZ4n54hd78Qkno=.ec6737a3-6b76-4633-9c61-ac393195b9d8@github.com>

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

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

  Copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13234/files
  - new: https://git.openjdk.org/jdk/pull/13234/files/bd6b6e60..9932c204

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

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

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

From duke at openjdk.org  Sat Apr 15 02:01:52 2023
From: duke at openjdk.org (duke)
Date: Sat, 15 Apr 2023 02:01:52 GMT
Subject: <i18n dev> Withdrawn: 8298045: Fix hidden but significant trailing
 whitespace in properties files for core-libs code
In-Reply-To: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
References: <bvHD0iJkn94rriRQVMhAlIqipXi3zVF7tEFj_ThOhLI=.04303df2-d9a0-45cf-926c-b47be322eb94@github.com>
Message-ID: <G6Tw0B0L-RsbxtWAHaDtj3Q11H47PQZYJKw69j5oF9g=.bb2621e8-9cb4-43b8-a12d-a71640263d0c@github.com>

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

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

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Sat Apr 15 08:57:41 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 15 Apr 2023 08:57:41 GMT
Subject: <i18n dev> RFR: 8305904: java/lang/Character,
 java/lang/String and java/text/Normalizer tests read the unicode
 data files from src directories.
In-Reply-To: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
References: <8eMBL8k-kfc7jH1iREK09PTGX4DTXMREKZ25Khz9pZM=.52b8bff6-9c18-49bc-b959-0ca8b4aa34d2@github.com>
Message-ID: <NgYRAM73jSjp6yuyL3nwIhGnWMerp4Be-w30WXYZ9tQ=.11dbdeac-27b1-4075-bd02-b2e5161a5186@github.com>

On Wed, 12 Apr 2023 16:35:19 GMT, Mahendra Chhipa <mchhipa at openjdk.org> wrote:

> Following tests read the unicode data files (http://www.unicode.org/Public/UNIDATA/ ) from src directory. For tests, these files should be in test directories. No source code is using these files. Only tests are using these files. Tests are :
> java/lang/Character/CharPropTest.java
> java/lang/Character/CheckProp.java
> java/lang/Character/CheckScript.java
> java/lang/Character/CheckUnicode.java
> java/lang/Character/UnicodeBlock/CheckBlocks.java
> java/lang/Character/UnicodeCasingTest.java
> java/lang/String/SpecialCasingTest.java
> java/lang/String/UnicodeCasingTest.java
> java/text/Normalizer/ConformanceTest.java

I assume this PR should be closed.

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

PR Comment: https://git.openjdk.org/jdk/pull/13447#issuecomment-1509655420

From stsypanov at openjdk.org  Sun Apr 16 11:20:46 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:20:46 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v4]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: Extract separate benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/b40de5a8..198cb6ae

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

  Stats: 96 lines in 2 files changed: 66 ins; 27 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/12131.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12131/head:pull/12131

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

From stsypanov at openjdk.org  Sun Apr 16 11:20:52 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:20:52 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v3]
In-Reply-To: <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <5e1c0aIHmpueO2gPCS4suJh3Jo0RVhWpSkUnMmnM2uw=.7592dbee-3c4e-4ba7-8c7c-9184fa3ddcbe@github.com>
 <P6G78Sj0a0YnAFiHgvqtfRZGN773tdq1DEdwVwLeubA=.fe8bdf0c-b00d-4b65-969d-ad70385a58a3@github.com>
Message-ID: <V0lc7_4isxYZzPVHzE5QBZIh5wHNRow8TFqIn8MBmLA=.13ef1bd8-2648-4785-9fde-7d6b9ea03004@github.com>

On Wed, 12 Apr 2023 17:39:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Sergey Tsypanov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' into dtfb
>>  - 8300818: Add benchmark
>>  - 8300818: Add benchmark
>>  - Revert irrelevant change
>>  - Merge branch 'master' into dtfb
>>  - Improve padding of DateTimeFormatter
>
> test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 148:
> 
>> 146:         return YEAR_FORMATTER.format(now);
>> 147:     }
>> 148: 
> 
> There benchmarks are run 4 time each because of the @Param that are defined for the pre-existing tests.
> I don't know if jmh can be annotated to ignore the params; but to avoid wasting resources create a separate jmh source file for thees new tests.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1167835249

From stsypanov at openjdk.org  Sun Apr 16 11:47:34 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Sun, 16 Apr 2023 11:47:34 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
Message-ID: <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>

On Wed, 12 Apr 2023 17:41:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Added benchmark for this
>
> Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.

@RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1167869599

From rriggs at openjdk.org  Mon Apr 17 15:24:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 17 Apr 2023 15:24:38 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
 <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
Message-ID: <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>

On Sun, 16 Apr 2023 11:44:52 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Special casing for len == 0 and keeping the existing buf.insert for len == 1 would avoid object creation except when it would improve performance.
>
> @RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?

Yes, I meant on the length of the inserted padding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1168891583

From naoto at openjdk.org  Mon Apr 17 16:38:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 17 Apr 2023 16:38:49 GMT
Subject: <i18n dev> Integrated: 8296248: Update CLDR to Version 43.0
In-Reply-To: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
References: <V2Jz3piihseKlTVKINMYx5eby3edScFRxpqIqh74Co4=.9a6df268-3d95-4bb5-b065-9275e9247385@github.com>
Message-ID: <02MVmGxQ0KhWjNsXuPHSABk-628O_YjPFPZM1i5eVt8=.3b8b07e2-81d3-4947-a11b-72a4b2bb65ef@github.com>

On Thu, 13 Apr 2023 20:20:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to [version 43](https://cldr.unicode.org/index/downloads/cldr-43). This semi-annual release is their `limited-submission` release so I would not expect regressions caused by formatting changes as we had in JDK20/CLDRv42 (https://inside.java/2023/03/28/quality-heads-up/)

This pull request has now been integrated.

Changeset: 4ed933cf
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ed933cf774f8124b18ae68d0bf8cded9244a2e2
Stats:     209683 lines in 1037 files changed: 199352 ins; 2906 del; 7425 mod

8296248: Update CLDR to Version 43.0

Reviewed-by: joehw

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

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

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

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

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

 - Spacing
 - Tidy up

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

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

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

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

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

From naoto at openjdk.org  Tue Apr 18 18:46:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 18 Apr 2023 18:46:50 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
Message-ID: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>

The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

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

Commit messages:
 - 8306323: Update license files in CLDR v43

Changes: https://git.openjdk.org/jdk/pull/13517/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13517&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306323
  Stats: 194 lines in 3 files changed: 98 ins; 90 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13517.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13517/head:pull/13517

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

From stsypanov at openjdk.org  Tue Apr 18 18:49:54 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 18 Apr 2023 18:49:54 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v5]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: special cases

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/198cb6ae..07215c1f

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

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

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

From stsypanov at openjdk.org  Tue Apr 18 18:49:56 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Tue, 18 Apr 2023 18:49:56 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v4]
In-Reply-To: <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <LqYM4DGlvbhjOITWOedQLcKL4B3y4sQ09tIHc_E2vRs=.0cf7cb11-9af0-486b-9a14-14d79b2706ea@github.com>
Message-ID: <fd6hWIdZn5b_g4iEnw6QGQ33KoNbxKHLI31XsVtC22w=.9aced287-4b80-472d-b199-f0814617cfa0@github.com>

On Sun, 16 Apr 2023 11:20:46 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Extract separate benchmark

With latest changes

baseline

Benchmark                                                                     Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding                          thrpt   15   5848.753 ? 223.592  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1070.358 ?  40.881  MB/sec
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    192.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.count                thrpt   15     53.000            counts
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.time                 thrpt   15    479.000                ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding                      thrpt   15  22032.107 ? 481.443  ops/ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   3192.003 ?  69.901  MB/sec
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.count            thrpt   15     83.000            counts
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.time             thrpt   15   1046.000                ms

patch

Benchmark                                                                     Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding                          thrpt   15   7982.747 ? 374.638  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate           thrpt   15   1704.393 ?  80.063  MB/sec
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.alloc.rate.norm      thrpt   15    224.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.count                thrpt   15     64.000            counts
DateTimeFormatterWithPaddingBench.formatWithPadding:?gc.time                 thrpt   15    641.000                ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding                      thrpt   15  22024.559 ? 794.713  ops/ms
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate       thrpt   15   3190.932 ? 115.145  MB/sec
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.alloc.rate.norm  thrpt   15    152.000 ?   0.001    B/op
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.count            thrpt   15     85.000            counts
DateTimeFormatterWithPaddingBench.formatWithZeroPadding:?gc.time             thrpt   15   1019.000                ms

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

PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1513638998

From lancea at openjdk.org  Tue Apr 18 18:50:51 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 18 Apr 2023 18:50:51 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <XFaMZDSL4S4f2WFa_RzQfFsb55z6gWWzDCX_Y8tK7JE=.f15aa5b5-9054-4e36-bcf9-44a751086888@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390742707

From duke at openjdk.org  Tue Apr 18 18:53:44 2023
From: duke at openjdk.org (Steven R. Loomis)
Date: Tue, 18 Apr 2023 18:53:44 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <DmJZDsrUaoxmJxN-r948Ro1LItB1AEQWlDyLKSSEFxM=.86fb4d78-25f1-4178-b6f2-1a7762a665a8@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by srl295 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390749259

From iris at openjdk.org  Tue Apr 18 19:33:46 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 18 Apr 2023 19:33:46 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <9_yDCYhSWH6UDSOTfAQqyGkh8KAU2OCRUAW-D9oKrTY=.c3124de8-e14f-4631-a6f1-c1cd5f8d95f4@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390801345

From srl at openjdk.org  Tue Apr 18 20:18:46 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 18 Apr 2023 20:18:46 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

Marked as reviewed by srl (Committer).

[testing]

Marked as reviewed by srl (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862217
Changes requested by srl (Committer).

PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390862891
PR Review: https://git.openjdk.org/jdk/pull/13517#pullrequestreview-1390863607

From srl at openjdk.org  Tue Apr 18 20:18:48 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 18 Apr 2023 20:18:48 GMT
Subject: <i18n dev> RFR: 8306323: Update license files in CLDR v43
In-Reply-To: <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
 <oWR7w3mvahNSg8zL6U9EMKQvV-gyYFveP-JIJkIBpi0=.c1d98b3d-40a2-4bc1-b5ea-441a10dbffb6@github.com>
Message-ID: <DxSc7sYAFRDBx6liZFBvHKNlvOgxQ65sNh6B-HMnChA=.7b07371e-d43c-41c6-91b7-ce660e843863@github.com>

On Tue, 18 Apr 2023 20:15:32 GMT, Steven Loomis <srl at openjdk.org> wrote:

>> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.
>
> Marked as reviewed by srl (Committer).

- [Steven Loomis](https://openjdk.org/census#srl) (@srl295 - Committer) ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13517#issuecomment-1513743510

From stsypanov at openjdk.org  Wed Apr 19 06:28:45 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Wed, 19 Apr 2023 06:28:45 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v2]
In-Reply-To: <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <MenYmzjK8UGh7uJDVVt-sqJsOKagHL3B4qvj4JIDtdw=.cd5c3177-30ee-4752-bfd4-4d3c8271621c@github.com>
 <KR4jLIdgm_Y49RQkIJ9uNHqemm01aE81GRBVz6XznJ8=.c2e99c6d-2fb2-44ce-b23d-6461fac68ff4@github.com>
 <3Im4RP5-AmauuIjCVgA3V4h0HellqriqIlbTSjXjrWU=.a3b7c98f-276a-423a-8d48-c3415633b2cc@github.com>
 <_gJmYty5eyRbpGo3AIlFE4HDkmGWAWPsAOqwJri3mqo=.70b5927c-2be5-484c-98f4-f21933166c55@github.com>
 <8-pc62MG2Qcj0reM0zl85Kunw2rZlQOMVZHyjKKSSSY=.4af17266-9d26-42e3-a357-fcda22f1fd5b@github.com>
 <MGPD9mADC-45XPxBYAMM6nRIPJ3oKAwwPcOofSkzmiw=.b54f5929-1992-4089-9a6b-743bd2643a2d@github.com>
 <0tZH5cpkJrPjxa3UNQ3MC0LvRkFGIs2W5v21v4GS1pA=.1dd39ae4-d6cd-4356-a9cc-5b83832d4319@github.com>
 <VENDtZkxIpFevgc-FaY3nL-RzOjyoo-ioPEfvLV_USw=.9e4beaae-ed0f-4015-9c37-023b19d09ac8@github.com>
Message-ID: <D0253hmZS62g441iW0vmGh0mPPfbFKznYZlmrLgyMkI=.2520d83c-a677-4213-9f2f-9885c19c39ce@github.com>

On Mon, 17 Apr 2023 15:21:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> @RogerRiggs sorry I don't get it. Maybe you mean speacial casing for `padWidth - len`?
>
> Yes, I meant on the length of the inserted padding.

Done

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1170860774

From pminborg at openjdk.org  Wed Apr 19 07:13:48 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 19 Apr 2023 07:13:48 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <raBAgoUakoc-uMqxotfoehCK8yUqfbgzo-fgeERuTD4=.a9059b99-4d5f-406c-95a2-3c4248256ab5@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Keep alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1514237804

From liach at openjdk.org  Wed Apr 19 13:02:51 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 13:02:51 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <bCgmNILETnu3TOKZKH9QsSMYuyFI2r-LWE_SNp8Fj2Y=.4d32285a-cf0b-43b7-b6a7-2c002a2792ee@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
 <vPOZgVXPdg_rgVjefz-1vOC2lkM1-BVhLgzY5siKMkw=.28efeb0e-414f-4de6-b739-b06f3c4cb4ae@github.com>
 <rUg86GFR5OZEgCHGfuNGM_Jgot88RxxcXPPvQlJn3Yo=.31ef295f-6ebc-4b09-a37d-1c0147984d09@github.com>
 <bCgmNILETnu3TOKZKH9QsSMYuyFI2r-LWE_SNp8Fj2Y=.4d32285a-cf0b-43b7-b6a7-2c002a2792ee@github.com>
Message-ID: <U6fjZANzE_5CIspjg0-ymP17EU_JEIOoRyMZP4gNjRQ=.35a4469b-23b5-491a-9517-3d2cf37c1283@github.com>

On Tue, 21 Mar 2023 13:53:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> It is possible but this keeps the mapper more local and only accessible where it is supposed to be used. For testing purposed, it might be better to have the class as you propose.
>
> If we want it local, I suppose we can convert the whole `ZoneOffsetMapper` local with this singleton in `ofTotalSeconds` static method as well.

What I mean is:

final class LazyZoneOffsetMapper implements IntFunction<ZoneOffset> {
    private static final LazyZoneOffsetMapper INSTANCE = new LazyZoneOffsetMapper();

    @Override
    public ZoneOffset apply(int slot) {
        int totalSeconds = slotToSeconds(slot);
        ZoneOffset newValue = new ZoneOffset(totalSeconds);
        ZoneOffset existing = ID_CACHE.putIfAbsent(newValue.getId(), newValue);
        return existing == null ? newValue : existing;
    }
}

we can inline this local class so we don't declare two classes nested `ZoneOffsetMapper` and local `Holder` for one purpose. This local class is still lazily loaded only if the `INSTANCE` field is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1171302695

From liach at openjdk.org  Wed Apr 19 13:02:55 2023
From: liach at openjdk.org (Chen Liang)
Date: Wed, 19 Apr 2023 13:02:55 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <krg9DVuIDEYGVKd-u1VBI13u1QJI9uJmLutWoeGmAWY=.415fe3ac-94b1-42d1-b135-65a28b92403b@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

src/java.base/share/classes/java/time/ZoneOffset.java line 451:

> 449:             ZoneOffset newValue = new ZoneOffset(totalSeconds);
> 450:             ID_CACHE.putIfAbsent(newValue.getId(), newValue);
> 451:             return newValue;

Suggestion:

            ZoneOffset existing = ID_CACHE.putIfAbsent(newValue.getId(), newValue);
            return existing == null ? newValue : existing;

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12346#discussion_r1171288185

From naoto at openjdk.org  Wed Apr 19 16:07:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 16:07:56 GMT
Subject: <i18n dev> Integrated: 8306323: Update license files in CLDR v43
In-Reply-To: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
References: <r10ngnFB10a9i1RdI_54LpA5xGR9U-birWF_SEIuB_g=.0ba9a40f-ee26-4374-8bf7-4a8edb177f81@github.com>
Message-ID: <3vVwZa-_CWFCdKb7J6-1Z7B_1sFwEgwKQFoLbsDwqhg=.0035c258-f1fd-4dd0-a7c3-bfe7490c7bb2@github.com>

On Tue, 18 Apr 2023 18:40:03 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The upgrade to CLDR v43 was missing the license-related file updates. Here are the supplemental updates.

This pull request has now been integrated.

Changeset: 85de01e6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85de01e67638cf1356d5ad08ebd4a630df6bae03
Stats:     194 lines in 3 files changed: 98 ins; 90 del; 6 mod

8306323: Update license files in CLDR v43

Reviewed-by: lancea, srl, iris

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

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

From rriggs at openjdk.org  Wed Apr 19 17:44:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 19 Apr 2023 17:44:47 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v5]
In-Reply-To: <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <8EBRIAmr9MzpU6U654LjdVS4w54tcsfCDqhnX5HvuHI=.7da22500-928c-4048-a13e-27c15b95c356@github.com>
Message-ID: <QdSgT5wv0x_cDw-eMBv3PcGp9MGb5XpsvMf69MiR43g=.cd518257-b2d6-4ae4-8c31-91f468954203@github.com>

On Tue, 18 Apr 2023 18:49:54 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: special cases

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterBench.java line 122:

> 120:     }
> 121: 
> 122: }

Drop this blank line and there will be no changes.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1171524385

From jlu at openjdk.org  Wed Apr 19 19:59:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Apr 2023 19:59:36 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry to
 Version 2023-04-13
Message-ID: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>

Update the registry and accompanying tests with the **IANA 4/13/2022** update.

This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.

This causes unexpected failures in JDK tests because of how locale equivalencies are created.

eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`

Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following


...
singleEquivMap.put("ar-ajp", "ajp");
singleEquivMap.put("ajp", "ar-ajp");
...
multiEquivsMap.put("apj", new String[] {"apc", "ar-apc"});
multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
...


When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:

`apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`

When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.

To address this, the build process must be adjusted so that the equivalencies are built as 


...
multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
...


As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

Commit messages:
 - Adjust build and test to account for new case
 - ajp should follow apc
 - Fix order of langs
 - Update test with preffered value: ajp
 - Update registry

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

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

From jlu at openjdk.org  Wed Apr 19 20:07:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 19 Apr 2023 20:07:32 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v2]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

  Copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/30e0ef83..e5d332ee

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

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

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

From naoto at openjdk.org  Wed Apr 19 22:54:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Apr 2023 22:54:48 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v2]
In-Reply-To: <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
Message-ID: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>

On Wed, 19 Apr 2023 20:07:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 2:

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

Cannot comment on unmodified lines, but instead of calculating the initial load itself, `HashMap.newHashMap()` can be used for initializing maps.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 144:

> 142:                 boolean foundInOther = false;
> 143:                 final String finalPref = ","+preferred;
> 144:                 final String inbtwnPref = ","+preferred+",";

This could utilize regex?

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 146:

> 144:                 final String inbtwnPref = ","+preferred+",";
> 145:                 // Check if current pref exists inside a value for another pref
> 146:                 List<StringBuilder> doublePrefs = initialLanguageMap.entrySet()

`values()` fits here

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 150:

> 148:                                 e.getValue().toString().contains(inbtwnPref)))
> 149:                         .map(Map.Entry::getValue)
> 150:                         .collect(Collectors.toList());

Can replace `collect()` with `toList()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171923706
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171920639
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171922562
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1171923033

From jlu at openjdk.org  Thu Apr 20 06:14:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:14:46 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v3]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <tB6qWExQrl8J2RXmQH8i0s7R-pgJI5SQNZWt_Ot4Mg0=.64338596-9982-4826-b0ca-f076c9010c96@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

  Improve stream processing and hash map creation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/e5d332ee..4a75417f

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

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

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

From jlu at openjdk.org  Thu Apr 20 06:16:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:16:47 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v2]
In-Reply-To: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
 <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
Message-ID: <u_S5pgXCM8b2DWTOJRRr96D8ZA8kWflLVsQVGP2YkOc=.c14b7e45-cb00-4b00-9f60-2f3dff450e8c@github.com>

On Wed, 19 Apr 2023 22:46:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 144:
> 
>> 142:                 boolean foundInOther = false;
>> 143:                 final String finalPref = ","+preferred;
>> 144:                 final String inbtwnPref = ","+preferred+",";
> 
> This could utilize regex?

Much better that way, fixed

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 146:
> 
>> 144:                 final String inbtwnPref = ","+preferred+",";
>> 145:                 // Check if current pref exists inside a value for another pref
>> 146:                 List<StringBuilder> doublePrefs = initialLanguageMap.entrySet()
> 
> `values()` fits here

fixed

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 150:
> 
>> 148:                                 e.getValue().toString().contains(inbtwnPref)))
>> 149:                         .map(Map.Entry::getValue)
>> 150:                         .collect(Collectors.toList());
> 
> Can replace `collect()` with `toList()`

Changed this, as well as the other existing occurrence

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172122929
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172123278
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172123190

From jlu at openjdk.org  Thu Apr 20 06:36:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:36:47 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v4]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

  Hash map should be initialized with numMappings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/4a75417f..7d3021a4

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

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

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

From jlu at openjdk.org  Thu Apr 20 06:36:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:36:51 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v2]
In-Reply-To: <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <rIjFDs6KOwnkWJTLtfvHYb08re-2STSCQWrSyiTdTuk=.c221d2da-11d8-4ff2-b9ec-0df188092fdc@github.com>
 <FH2rUqpAjgRhVlqZE0VrdSc0H21Qz0b2-BJh0VyyC4o=.ac80c0db-66c5-42d8-847c-193cf6cce217@github.com>
Message-ID: <HtmWoo5fWH8To4Cc4AulVyOtx0Gi_XKQm3didOTIO7k=.3cd5b8c3-719c-47a2-a4ee-09dfa4d61943@github.com>

On Wed, 19 Apr 2023 22:51:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2012, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Cannot comment on unmodified lines, but instead of calculating the initial load itself, `HashMap.newHashMap()` can be used for initializing maps.

Fixed, so they are created with numMappings and not initialLoad

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172135340

From jlu at openjdk.org  Thu Apr 20 06:48:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 06:48:49 GMT
Subject: <i18n dev> RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
Message-ID: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>

Small cleanup / tweak spotted in Calendar to improve readability.

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

Commit messages:
 - Replace ternary with max()

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

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

From stsypanov at openjdk.org  Thu Apr 20 15:05:18 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 20 Apr 2023 15:05:18 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v6]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: Remove blank line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/07215c1f..baa7f92e

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

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

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

From rriggs at openjdk.org  Thu Apr 20 16:06:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 16:06:45 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v6]
In-Reply-To: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
Message-ID: <IlBXvO3HhMcj5bHY-AoAy-xaa2H1N8AqQ8RI9I6xcOw=.a75f0ea1-188c-4d80-a82b-7fd3fc97ef13@github.com>

On Thu, 20 Apr 2023 15:05:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Remove blank line

LGTM;  thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1394327486

From naoto at openjdk.org  Thu Apr 20 17:13:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Apr 2023 17:13:50 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v4]
In-Reply-To: <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
Message-ID: <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>

On Thu, 20 Apr 2023 06:36:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Hash map should be initialized with numMappings

Much better. Some comments follow.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 40:

> 38: import java.util.Locale;
> 39: import java.util.Map;
> 40: import java.util.regex.Pattern;

Nit: sort the imports

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 143:

> 141:                 // eg: ar-ajp has pref ajp which has pref apc
> 142:                 boolean foundInOther = false;
> 143:                 Pattern pattern = Pattern.compile("\\b"+preferred+"\\b");

I think we should explicitly find a pattern with `,` instead of the word boundary. Otherwise, it could match `-` in a tag.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 289:

> 287:                 + sortedLanguageMap2.size() + ");\n"
> 288:                 + "        regionVariantEquivMap = HashMap.newHashMap("
> 289:                 + sortedRegionVariantMap.size() + ");\n\n"

It'd be nice if these messy concatenated strings be converted to a text block, but that would be for another day.

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

PR Review: https://git.openjdk.org/jdk/pull/13501#pullrequestreview-1394424712
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172870938
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172876231
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1172878602

From naoto at openjdk.org  Thu Apr 20 18:16:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Apr 2023 18:16:43 GMT
Subject: <i18n dev> RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <T0XKzBJvxU-olkDrd-ZAZT8K_9VUlJRx-YF5tweSvwg=.f2fde09c-5c71-40af-b1cb-e34579214c12@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394532604

From rriggs at openjdk.org  Thu Apr 20 18:20:44 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 20 Apr 2023 18:20:44 GMT
Subject: <i18n dev> RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <NEKB5puIc4AjPREBiOJQuPJI4uFSlmUJEG3j-tADVy4=.15d6c985-daae-4c21-a3a4-5fc7da18431e@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394537788

From iris at openjdk.org  Thu Apr 20 19:01:43 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 20 Apr 2023 19:01:43 GMT
Subject: <i18n dev> RFR: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <Ka7AZHzAbavPByUYrqFLJ_ouFwy4KACth0DHcljBTo4=.0149ae8a-58b2-4947-9a43-63b3d4c8df1d@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13554#pullrequestreview-1394591566

From jlu at openjdk.org  Thu Apr 20 20:18:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:18:36 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v4]
In-Reply-To: <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <4-zyZv_-bDaqfjsOI6cKOq-GVRC-RTrBeDk2xDEkZzg=.8d0e7bfc-c347-4b88-b4fc-7049c958eab3@github.com>
 <7LNRN900bp0xLdD5znt3XSjJeF0f1Hs-MT_PQpBvPUc=.e7bd6a6c-e821-4a90-8604-11bfcfa02012@github.com>
Message-ID: <Xfpq10GV_IBIC21y2LNe2ogoozmzseDYXeUyteBGdSc=.f7e60e83-b467-4bcc-af7c-5b55a5b77acb@github.com>

On Thu, 20 Apr 2023 17:06:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Hash map should be initialized with numMappings
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 143:
> 
>> 141:                 // eg: ar-ajp has pref ajp which has pref apc
>> 142:                 boolean foundInOther = false;
>> 143:                 Pattern pattern = Pattern.compile("\\b"+preferred+"\\b");
> 
> I think we should explicitly find a pattern with `,` instead of the word boundary. Otherwise, it could match `-` in a tag.

Good point, changed it to match starting with `,` and ending with `,` or end of string boundary

> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 289:
> 
>> 287:                 + sortedLanguageMap2.size() + ");\n"
>> 288:                 + "        regionVariantEquivMap = HashMap.newHashMap("
>> 289:                 + sortedRegionVariantMap.size() + ");\n\n"
> 
> It'd be nice if these messy concatenated strings be converted to a text block, but that would be for another day.

Will file a separate JBS issue for this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1173046730
PR Review Comment: https://git.openjdk.org/jdk/pull/13501#discussion_r1173047129

From jlu at openjdk.org  Thu Apr 20 20:18:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:18:30 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v5]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <TuoYTf_tqxtmJeU3CWaNiGxQ6ka7UGZznMInYpGKw6A=.6e34ee8c-8cc3-4462-8443-aa4c8a1dd017@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

  Match on exact pattern

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/7d3021a4..c3046627

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

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

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

From jlu at openjdk.org  Thu Apr 20 20:22:39 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 20:22:39 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v6]
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

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

  Import ordering

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13501/files
  - new: https://git.openjdk.org/jdk/pull/13501/files/c3046627..b03a51c6

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

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

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

From jlu at openjdk.org  Thu Apr 20 21:14:00 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 21:14:00 GMT
Subject: <i18n dev> Integrated: 4737887: (cal) API: Calendar methods taking
 field should document exceptions
In-Reply-To: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
References: <y65woSohxKGbyGcuLxE9cKokT7YMJIl0uOPpeTiUT0o=.cfdee99e-067b-4139-9802-81def6b81797@github.com>
Message-ID: <YWO-Xi8H9rqmsWtrjIVxmkmFwuKhgpRArZO8RJLH190=.ee1becb7-eb50-427a-8b2e-b7a60214f292@github.com>

On Wed, 29 Mar 2023 22:04:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Many Calendar methods that take in a field parameter should document that they throw an ArrayIndexOutOfBoundsException if field is not between 0 and `Calendar.FIELD_COUNT`.
> 
> This PR adds a clause to the class description to make the above apparent.
> 
> `Calendar.Roll(int, int)`, `Calendar.roll(int, boolean)`, and `Calendar.add(int, int)` should all be documented that they throw an `IllegalArgumentException` if any calendar fields have out-of-range values in non-lenient mode or if field is
> `Calendar.ZONE_OFFSET`, `Calendar.DST_OFFSET`, or unknown.

This pull request has now been integrated.

Changeset: 174c1a6d
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/174c1a6d53d3ea95649a511f4088c7807d80b59b
Stats:     20 lines in 1 file changed: 13 ins; 5 del; 2 mod

4737887: (cal) API: Calendar methods taking field should document exceptions

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Thu Apr 20 21:22:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Apr 2023 21:22:56 GMT
Subject: <i18n dev> Integrated: 8305207: Calendar.aggregateStamp(int,
 int) return value can be simplified
In-Reply-To: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
References: <g-oxxJlvOFdLAHSJskcSoDmbTddRsTSOoAvMgML6pr8=.64978973-217b-486a-959d-5fa7a22b48cd@github.com>
Message-ID: <qPo4XzjQrD5BQ56LJS7qjHeapq5-1uXjAII70xS_iOQ=.4c635786-a350-4c8d-b632-98d43248837a@github.com>

On Thu, 20 Apr 2023 06:32:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Small cleanup / tweak spotted in Calendar to improve readability.

This pull request has now been integrated.

Changeset: ffb2494d
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffb2494de488b77fd017c04531b103d695909c2f
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8305207: Calendar.aggregateStamp(int, int) return value can be simplified

Reviewed-by: naoto, rriggs, iris

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

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

From duke at openjdk.org  Fri Apr 21 08:28:45 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 21 Apr 2023 08:28:45 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v4]
In-Reply-To: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
Message-ID: <7Ipeih3VcHURzvqdfnOJoueuhvn4IPjvDpV4YFILeyk=.e1284bb2-46ba-4733-a124-593111f83b8f@github.com>

On Tue, 28 Feb 2023 07:49:17 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace, remove stream()

Is this ready to merge now?

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

PR Comment: https://git.openjdk.org/jdk/pull/12690#issuecomment-1517466596

From redestad at openjdk.org  Fri Apr 21 14:34:46 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 21 Apr 2023 14:34:46 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v6]
In-Reply-To: <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <_SwKNoENpVe5iTpIFhQl1B7IhNwZZgBz2U-QQ8F4Ids=.64b9014d-3121-48f2-9368-c69b0370286e@github.com>
Message-ID: <qT5hzpWVCNon0KW2ay1SyrgSN7BBQrIID-Q6X4M8zio=.7727a2f9-2522-41d3-8ee7-39c801e9bf45@github.com>

On Thu, 20 Apr 2023 15:05:18 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: Remove blank line

test/micro/org/openjdk/bench/java/time/format/DateTimeFormatterWithPaddingBench.java line 62:

> 60: 
> 61:     @Benchmark
> 62:     public String formatWithZeroPadding() {

Isn't this benchmark now testing a padding of 1 char?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/12131#discussion_r1173847037

From naoto at openjdk.org  Fri Apr 21 17:38:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 17:38:45 GMT
Subject: <i18n dev> RFR: 8306031: Update IANA Language Subtag Registry
 to Version 2023-04-13 [v6]
In-Reply-To: <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
 <RXLecczBt_joz0R9SFMGI79wlPl2OWqA0Ca-m5qdmwk=.b3be3427-ab9c-43d3-950b-6546ebb8c363@github.com>
Message-ID: <SOMFmTTQ69cndrcgzKaipdrlDpYUTVzOTNf7qpgcI24=.3e2b6cf9-d0d2-4a05-b00f-f77c7cbec24b@github.com>

On Thu, 20 Apr 2023 20:22:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
>> 
>> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
>> 
>> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
>> 
>> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
>> 
>> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
>> 
>> 
>> ...
>> singleEquivMap.put("ar-ajp", "ajp");
>> singleEquivMap.put("ajp", "ar-ajp");
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
>> ...
>> 
>> 
>> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
>> 
>> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
>> 
>> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
>> 
>> To address this, the build process must be adjusted so that the equivalencies are built as 
>> 
>> 
>> ...
>> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
>> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
>> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
>> ...
>> 
>> 
>> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Import ordering

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13501#pullrequestreview-1396170956

From stsypanov at openjdk.org  Fri Apr 21 17:45:50 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Fri, 21 Apr 2023 17:45:50 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v7]
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:

  8300818: One more benchmark

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/12131/files
  - new: https://git.openjdk.org/jdk/pull/12131/files/baa7f92e..48a0cc70

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

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

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

From naoto at openjdk.org  Fri Apr 21 18:29:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 21 Apr 2023 18:29:47 GMT
Subject: <i18n dev> RFR: 8302983: ZoneRulesProvider.registerProvider()
 twice will remove provider [v4]
In-Reply-To: <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
 <32bmWmdJSojCpNplpArpbXwn6LD2qHIZSZfOccJKjC4=.9d60aeba-8ae5-40c6-ac78-241ef4002d1a@github.com>
Message-ID: <t9NEDp4oC17BGwH9oFQwKS1fFb5COgxQ_8uln39FnSA=.d688e79f-96e1-4312-b848-789883af7599@github.com>

On Tue, 28 Feb 2023 07:49:17 GMT, Madjosz <duke at openjdk.org> wrote:

>> Fixes JDK-8302983 (and duplicate JDK-8302898)
>
> Madjosz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   whitespace, remove stream()

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12690#pullrequestreview-1396233556

From redestad at openjdk.org  Fri Apr 21 18:45:47 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 21 Apr 2023 18:45:47 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v7]
In-Reply-To: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
Message-ID: <Xwl-cHIcUn5GxopbUcD-VwkKAwfiIjnfth_28yvY5Qg=.aeb2be0b-62d7-4266-90fa-2fcfb9dae03d@github.com>

On Fri, 21 Apr 2023 17:45:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: One more benchmark

Marked as reviewed by redestad (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1396251756

From rriggs at openjdk.org  Fri Apr 21 19:28:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 21 Apr 2023 19:28:47 GMT
Subject: <i18n dev> RFR: 8300818: Reduce complexity of padding with
 DateTimeFormatter [v7]
In-Reply-To: <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
 <FMW9OUs_b1Yc1MfP8va36dgEjkx0S-KufzUIw__EZ6w=.5a23562f-e87b-42ae-82d0-3cbbbd55bf26@github.com>
Message-ID: <NPXXwWjw6CQBGJGdu78gx82hq7B4U_43UyrIBI9_SO4=.d84dd4c5-923d-4f8d-8e5d-2523907c440b@github.com>

On Fri, 21 Apr 2023 17:45:50 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
>> 
>> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>>   .appendLiteral("Date:")
>>   .padNext(20, ' ')
>>   .append(DateTimeFormatter.ISO_DATE)
>>   .toFormatter();
>> String text = dtf.format(LocalDateTime.now());
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8300818: One more benchmark

Marked as reviewed by rriggs (Reviewer).

I added a few more small padding cases and and re-ran on my Mac:

Baseline:

Benchmark                                                    Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding         thrpt   15   5167.611 ?  85.096  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength0  thrpt   15  22004.618 ? 536.207  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength1  thrpt   15  18041.569 ? 142.627  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength2  thrpt   15  15966.853 ? 182.284  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength3  thrpt   15  13472.887 ? 181.794  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength4  thrpt   15  12991.458 ? 402.190  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength5  thrpt   15  11464.481 ? 603.970  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength6  thrpt   15  10386.347 ? 673.596  ops/ms


Patch:

Benchmark                                                    Mode  Cnt      Score     Error   Units
DateTimeFormatterWithPaddingBench.formatWithPadding         thrpt   15   6548.853 ? 201.695  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength0  thrpt   15  22269.428 ? 737.613  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength1  thrpt   15  19086.146 ? 117.055  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength2  thrpt   15  15627.898 ? 314.890  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength3  thrpt   15  15447.997 ? 121.946  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength4  thrpt   15  15185.318 ? 198.266  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength5  thrpt   15  15243.618 ? 147.131  ops/ms
DateTimeFormatterWithPaddingBench.formatWithPaddingLength6  thrpt   15  15093.142 ? 294.421  ops/ms

The expected steps in performance match the code paths of 0, 1, 2-6.

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

PR Review: https://git.openjdk.org/jdk/pull/12131#pullrequestreview-1396300114
PR Comment: https://git.openjdk.org/jdk/pull/12131#issuecomment-1518248669

From jlu at openjdk.org  Mon Apr 24 21:09:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Apr 2023 21:09:04 GMT
Subject: <i18n dev> RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106"
Message-ID: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>

This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.

With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.

On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.

In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

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

Commit messages:
 - Header and copyright year
 - Switch invalid id for custom id

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

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

From naoto at openjdk.org  Mon Apr 24 22:42:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Apr 2023 22:42:09 GMT
Subject: <i18n dev> RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106"
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <zhKsTLyory5poVlCullZZgR89PlHJ12kMVDadPNgzVo=.a90ef28a-976a-401e-9061-49d04d1b3865@github.com>

On Mon, 24 Apr 2023 21:02:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

Great to see this intermittent issue solved, Justin! A minor suggestion:

test/jdk/java/text/Format/DateFormat/DateFormatRegression.java line 360:

> 358:         TimeZone def = TimeZone.getDefault();
> 359:         try {
> 360:             TimeZone z = new SimpleTimeZone((int)(8.25 * 3600000), "GMT-08:15");

If we want a custom zone, simply `TimeZone.getTimeZone("GMT-08:15")` will do.

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

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1398894333
PR Review Comment: https://git.openjdk.org/jdk/pull/13630#discussion_r1175839321

From jlu at openjdk.org  Mon Apr 24 23:47:05 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Apr 2023 23:47:05 GMT
Subject: <i18n dev> RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106" [v2]
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

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

  Minor cleanup / alternate custom tz

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13630/files
  - new: https://git.openjdk.org/jdk/pull/13630/files/348f9691..19973c31

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

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

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

From ysatowse at openjdk.org  Tue Apr 25 05:23:12 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 25 Apr 2023 05:23:12 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler
Message-ID: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>

Please review this PR.  
With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

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

Commit messages:
 - Remove trailing spaces
 - Fix a mistake in the change
 - 8305505: NPE in javazic compiler

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

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

From naoto at openjdk.org  Tue Apr 25 05:23:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 05:23:14 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

test/jdk/sun/util/calendar/zi/GenDoc.java line 159:

> 157:             if (mapList == null) {
> 158:                 mapList = new HashMap<String, LatitudeAndLongitude>();
> 159:                 if (Main.getMapFile() != null) {

You could retain the map file and use it in the following line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13504#discussion_r1170502826

From ysatowse at openjdk.org  Tue Apr 25 05:23:15 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 25 Apr 2023 05:23:15 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler
In-Reply-To: <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
 <CLqtl6RXgMh5UqXS-uQ-eY7e-jKQJKizjCfTjju17ik=.b5c8357b-a79b-491a-80ae-96b39a8eb2a2@github.com>
Message-ID: <Xn2Nb3OY6fKWAPzItvw9bZT7JCJeQd6lv73QaayaVwk=.475db648-b0cd-4370-a701-74fa4d2242f5@github.com>

On Tue, 18 Apr 2023 19:50:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR.  
>> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.
>
> test/jdk/sun/util/calendar/zi/GenDoc.java line 159:
> 
>> 157:             if (mapList == null) {
>> 158:                 mapList = new HashMap<String, LatitudeAndLongitude>();
>> 159:                 if (Main.getMapFile() != null) {
> 
> You could retain the map file and use it in the following line

Correct.  Thanks for the catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13504#discussion_r1170668064

From naoto at openjdk.org  Tue Apr 25 16:31:09 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 16:31:09 GMT
Subject: <i18n dev> RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106" [v2]
In-Reply-To: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
 <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
Message-ID: <9yEWlPnMGSMqG9HrEQ-3u5jcnP7PI3RDvOM589Pzdj4=.0463d83d-d546-4839-bdc4-570ebb111134@github.com>

On Mon, 24 Apr 2023 23:47:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
>> 
>> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
>> 
>> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
>> 
>> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup / alternate custom tz

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1400309227

From lancea at openjdk.org  Tue Apr 25 17:00:10 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 25 Apr 2023 17:00:10 GMT
Subject: <i18n dev> RFR: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106" [v2]
In-Reply-To: <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
 <F_-vhIbxDmBc5NSTonXAP23GQc_Z4SJS7yzDXKfG2cE=.1b2618bf-d7d4-41ec-a401-834600939919@github.com>
Message-ID: <PpUCyOMm9gZH-uOZ9_NQdYDzbMJHDdq4HUoDsvgi5tQ=.fc516862-2830-4916-ba20-a564f582c092@github.com>

On Mon, 24 Apr 2023 23:47:05 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
>> 
>> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
>> 
>> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
>> 
>> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup / alternate custom tz

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13630#pullrequestreview-1400354287

From naoto at openjdk.org  Tue Apr 25 17:12:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 17:12:11 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <apagDwvacqb0PH5j0cl4j4AacLQin60Eem5FMGgqmNg=.dee5a670-18b7-439a-9a52-1209b3fa8fff@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

I revisited the code, and now think that `mapList` better be `null`, as it indicates the map option was not provided, so I think modifying the offending line as

            LatitudeAndLongitude location = (mapList != null ? mapList.get(zonename) : null);

may be cleaner.

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

PR Review: https://git.openjdk.org/jdk/pull/13504#pullrequestreview-1400371061

From jlu at openjdk.org  Tue Apr 25 20:35:22 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 20:35:22 GMT
Subject: <i18n dev> Integrated: 8306031: Update IANA Language Subtag
 Registry to Version 2023-04-13
In-Reply-To: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
References: <bNGHtB6aLCPuj0KvUqhEPOCpMa1IROrqAD5XzMxTmic=.ce200256-a5b7-431f-8da4-bef440bc9d98@github.com>
Message-ID: <qJLR2MnB-CAMxgYhwYA7UgWKVaAROjnXe64hPm3aP18=.f9c1c5e9-41f2-4c3b-bb80-68389a5d38cd@github.com>

On Mon, 17 Apr 2023 19:48:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Update the registry and accompanying tests with the **IANA 4/13/2022** update.
> 
> This update introduces the case where an IANA entry can have a preferred value, but that preferred value has a preferred value as well.
> 
> This causes unexpected failures in JDK tests because of how locale equivalencies are created.
> 
> eg: `ar-ajp` has a preferred value of `ajp` but `ajp` has a preferred value of `apc`
> 
> Normally, when the JDK is built, _LocaleEquivlalentMaps.java_ generates the following
> 
> 
> ...
> singleEquivMap.put("ar-ajp", "ajp");
> singleEquivMap.put("ajp", "ar-ajp");
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp"});
> ...
> 
> 
> When `LocaleMatcher.parse(ACCEPT_LANGUAGE)` is called with `ACCEPT_LANGUAGE` containing `apc` and `ajp` in that order, the following occurs:
> 
> `apc` is found, `apc` is added, all of `apc's` equivalencies are added: `ajp` and `ar-apc`
> 
> When parse iterates to `ajp`, it finds that it is already added to the list, and does not add it's equivalency `ar-ajp`.
> 
> To address this, the build process must be adjusted so that the equivalencies are built as 
> 
> 
> ...
> multiEquivsMap.put("ajp", new String[] {"apc", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("apc", new String[] {"ajp", "ar-ajp", "ar-apc"});
> multiEquivsMap.put("ar-ajp", new String[] {"apc", "ajp", "ar-apc"});
> multiEquivsMap.put("ar-apc", new String[] {"apc", "ajp", "ar-ajp"});
> ...
> 
> 
> As, if `ar-ajp` has a preferred value of `ajp`, and `ajp` has a preferred value of `apc`, this technically means that `ar-ajp` is equivalent to `apc` and its equivalencies as well. This way, when `LocaleMatcher.parse(ACCEPT_LANGUAGE)` iterates to `apc`, it will add all of it's equivalencies including `ar-ajp`.

This pull request has now been integrated.

Changeset: 00b1eaca
Author:    Justin Lu <jlu at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/00b1eacad6ae2d5ea5afb1de506768e9ab960743
Stats:     37 lines in 3 files changed: 19 ins; 0 del; 18 mod

8306031: Update IANA Language Subtag Registry to Version 2023-04-13

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Tue Apr 25 23:01:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Apr 2023 23:01:15 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v2]
In-Reply-To: <s5kZwYFz26u9Bwn9ykKCXDu_tLaQinwW2go4uSLCG-E=.e2154929-bbda-4104-b3f9-5517a831aa75@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <s5kZwYFz26u9Bwn9ykKCXDu_tLaQinwW2go4uSLCG-E=.e2154929-bbda-4104-b3f9-5517a831aa75@github.com>
Message-ID: <t-clxih2jqK_KQyxMlRha9NmC26cVJ02x_bcEzVH-Xo=.30babba9-a659-424b-a0ae-e8345514d6dd@github.com>

On Tue, 25 Apr 2023 22:08:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert changes that may affect extending test classes
>  - Add back toHexString (used by some tests)

Looks good, with minor nits:

test/jdk/java/text/testlib/IntlTest.java line 84:

> 82:         for (Method testMethod : testsToRun) {
> 83:             int oldCount = errorCount;
> 84:             writeTestName(testMethod.getName());

Could cache the method name for later uses

test/jdk/java/text/testlib/IntlTest.java line 134:

> 132:         indentLevel--;
> 133:         writeTestResult(errorCount);
> 134: 

Would this mean the final result is only written with `nothrow` option?

test/jdk/java/text/testlib/IntlTest.java line 228:

> 226:     protected int getErrorCount() {
> 227:         return errorCount;
> 228:     }

No need to move the method

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

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1400872160
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177142651
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177141497
PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177142257

From jlu at openjdk.org  Tue Apr 25 23:58:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 25 Apr 2023 23:58:59 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v3]
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

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

 - Move getErrorCount() back to original spot
 - Regardles of nothrow, final result should be logged, cache, move method back

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13655/files
  - new: https://git.openjdk.org/jdk/pull/13655/files/e89740cc..a395ba67

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

  Stats: 22 lines in 1 file changed: 5 ins; 6 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

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

From jlu at openjdk.org  Wed Apr 26 00:09:54 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 00:09:54 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <mfHN8qW2O-geCbegq8hR79LyVNYgyvREqLsWQ_fmheE=.7749e884-fe6f-45c5-99e8-805965ef5938@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

test/jdk/java/text/testlib/IntlTest.java line 108:

> 106:             }
> 107:         }
> 108:         if (exitCode) {

@naotoj Since I got rid of `writeTestResult(errorCount);`

I will just have this block execute regardless of `nothrow`. All tests should now write the final result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13655#discussion_r1177171469

From ysatowse at openjdk.org  Wed Apr 26 03:03:58 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Wed, 26 Apr 2023 03:03:58 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler [v2]
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:

  Insert null check for mapList at its usage instead of initializing mapList

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13504/files
  - new: https://git.openjdk.org/jdk/pull/13504/files/2864658d..3d726b3c

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

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

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

From naoto at openjdk.org  Wed Apr 26 16:02:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Apr 2023 16:02:33 GMT
Subject: <i18n dev> RFR: 8305505: NPE in javazic compiler [v2]
In-Reply-To: <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
 <plN7RPgpzoYMsyadgCTl6jBDKCuCuFmD4FxqWIWfm2U=.1786e964-5250-48a6-b4d3-e584752d7b88@github.com>
Message-ID: <gNrT0850NnZ4JHATDpI26_hWuuhw8ByFiBQ03jp2bc4=.9ec52ffc-be99-4ae2-b4e5-b3167db52fb7@github.com>

On Wed, 26 Apr 2023 03:03:58 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

>> Please review this PR.  
>> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.
>
> Yoshiki Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Insert null check for mapList at its usage instead of initializing mapList

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13504#pullrequestreview-1402301927

From jlu at openjdk.org  Wed Apr 26 17:08:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 17:08:25 GMT
Subject: <i18n dev> Integrated: 8305853:
 java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught
 exception thrown in test method Test4089106"
In-Reply-To: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
References: <PWwKRj_Qq886syWEOabKIRXbXnK9S0EapNax9x9stjc=.66d629ca-c9b6-4aa2-861e-bbd4c3f39594@github.com>
Message-ID: <AMx6iql95VOJb3DnZ3foWbJaIyiDmqoD_uPUkcN-bJg=.798af880-a306-4fb7-b239-407b049a28d7@github.com>

On Mon, 24 Apr 2023 21:02:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes an intermittent failure (that only occurs on Windows) in _DateFormatRegression.java_.
> 
> With the integration of [JDK-8304982](https://bugs.openjdk.org/browse/JDK-8304982), _LocaleProviderAdapter.java_ now emits a compat warning when the class is loaded. This warning calls `ZonedDateTime.now()` during formatting. This call depends on the `TimeZone.ID` of the TimeZone returned from `TimeZone.getDefault()`.
> 
> On Windows, the test class which DateFormatRegression extends will run the tests at random, (as opposed to running in the same order every time). When Test4089106() happens to be the first test ran, the static block of LocaleProviderAdapter will be executed with `TimeZone.setDefault()` set to a `SimpleTimeZone` with `id` as _FAKEZONE_. When LocaleProviderAdapter formats the compat warning ... and many calls later calls `ZoneRulesProvider getProvider(String zoneId)` with `zoneId` as _FAKEZONE_ the test fails with _java.time.zone.ZoneRulesException: Unknown time-zone ID: FAKEZONE_.
> 
> In order to still test that `SimpleDateFormat.getTimeZone()` defaults to `TimeZone.getDefault()` we can create a `SimpleTimeZone` with a custom id rather than an invalid id. This way ZoneRulesProvider will not fail on the ID, but the `SimpleTimeZone` being tested is still not a "default" `TimeZone`.

This pull request has now been integrated.

Changeset: 8e36c05d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e36c05d6c80f6bdcd8a7530a382810f500885ad
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8305853: java/text/Format/DateFormat/DateFormatRegression.java fails with "Uncaught exception thrown in test method Test4089106"

Reviewed-by: naoto, lancea

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

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

From naoto at openjdk.org  Wed Apr 26 18:28:24 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Apr 2023 18:28:24 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <3Niq8CgII4c7bK_CO1PdVbm5gMLJKlPvwI0yv-a0dbE=.61cee516-f80e-4239-b025-add9aac17f98@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1402547220

From lancea at openjdk.org  Wed Apr 26 20:21:53 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 26 Apr 2023 20:21:53 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v3]
In-Reply-To: <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
Message-ID: <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>

On Tue, 25 Apr 2023 23:58:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to the IntlTest (test framework) class. 
>> 
>> These changes include
>> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
>> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
>> - Improving output.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Move getErrorCount() back to original spot
>  - Regardles of nothrow, final result should be logged, cache, move method back

Looks good overall perhaps consider using `HexFormat` instead of the private method `toHexString`

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13655#pullrequestreview-1402735283

From jlu at openjdk.org  Wed Apr 26 22:31:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 22:31:53 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <7CYXigGbDi0cdS37EA30gH6qbnxacqDOTaYToHMUCcg=.4c78f4d3-1bae-4f21-936c-01d872b706c4@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1402905133

From jlu at openjdk.org  Wed Apr 26 22:34:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 22:34:56 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention
Message-ID: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>

Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.

This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.


In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
- Will not case fold variant subtags
- Will not case fold private use subtags prefixed by "lvariant"

As an example, `caseFoldLanguageTag("JA-JPAN-JP-U-CA-JAPANESE-x-RANDOM-lvariant-JP")` returns _"ja-Jpan-JP-u-ca-japanese-x-random-lvariant-JP"_. Further examples can be seen in the test file.

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

Commit messages:
 - Copyright year for LangTag
 - Space
 - Add PR example to tests
 - Add case for grandfathered tag in specification
 - Consider private use variant prefix (JDK special cases)
 - Cache the potential legacy tag
 - Remove leftover comments in LanguageTag
 - Adjust imports in LanguageTag.java
 - Add implementation to LanguageTag.java
 - Add specification to Locale
 - ... and 1 more: https://git.openjdk.org/jdk/compare/d063b896...25be34d9

Changes: https://git.openjdk.org/jdk/pull/13679/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13679&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8159337
  Stats: 251 lines in 3 files changed: 247 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlu at openjdk.org  Wed Apr 26 23:40:23 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 23:40:23 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v4]
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <OCUg1H7MfpamF6cDz24fHWKyc3L3ZZNhXFeV_pX1mp8=.879d7c07-40bc-4645-983f-bbfe26e0063f@github.com>

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

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

  Replace toHexString() with HexFormat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13655/files
  - new: https://git.openjdk.org/jdk/pull/13655/files/a395ba67..773da120

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

  Stats: 70 lines in 2 files changed: 26 ins; 14 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/13655.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13655/head:pull/13655

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

From jlu at openjdk.org  Wed Apr 26 23:42:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Apr 2023 23:42:52 GMT
Subject: <i18n dev> RFR: 8306711: Improve diagnosis of `IntlTest`
 framework [v3]
In-Reply-To: <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
 <1jgAl-t9wzGNi3vuG9zDxsjAK3xyei8Chqrzt7DvRYg=.8f49fb5f-afdd-423f-9e22-078584b00433@github.com>
 <BR4HE-aBeNqd1ddhrKd65MrLB098p30EzNAjdRXwOBM=.ffc0bb0c-39d4-4c1e-b651-4de8c6b25442@github.com>
Message-ID: <cfAoW7z8xm9k5krmirT1jqwMTCkVHd3xd9pfaHvYpSM=.44b53e99-af85-48fe-82a5-ca0ae389c146@github.com>

On Wed, 26 Apr 2023 20:08:51 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Move getErrorCount() back to original spot
>>  - Regardles of nothrow, final result should be logged, cache, move method back
>
> Looks good overall perhaps consider using `HexFormat` instead of the private method `toHexString`

@LanceAndersen Thanks for the review. Changed it so that `HexFormat` methods are used, luckily only one subclass used `toHexString`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13655#issuecomment-1524179840

From iris at openjdk.org  Thu Apr 27 01:13:23 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 27 Apr 2023 01:13:23 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <sCRan2XV_GNo_g_ETudGP2kCW6QH993xWQy2IHSf2Bg=.1c3fcdb2-86e8-4544-97b2-82737d8f48bc@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

Release note also looks good.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1403026602

From joehw at openjdk.org  Thu Apr 27 04:47:26 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Apr 2023 04:47:26 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1524687089

From stsypanov at openjdk.org  Thu Apr 27 07:01:23 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 27 Apr 2023 07:01:23 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <3KTd3Uwc0ld5LXC3td_XBQ83vEPHtctjJB-ldcFM3-k=.bcd137e2-b931-47ec-9dda-72f190f6f9f3@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Keep alive

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1524890379

From naoto at openjdk.org  Thu Apr 27 12:49:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Apr 2023 12:49:03 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
 <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
Message-ID: <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>

On Thu, 27 Apr 2023 04:37:08 GMT, Joe Wang <joehw at openjdk.org> wrote:

> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?

We don't file a CSR for such a locale data change. These sorts of changes happen in the CLDR upgrade all the time, as well as other i18n-related data changes (currency, timezone, etc.)

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1525616806

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

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

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

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

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=63
  Stats: 9276 lines in 73 files changed: 9179 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From joehw at openjdk.org  Thu Apr 27 15:30:29 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 27 Apr 2023 15:30:29 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <OB5IdTtYCR4vH1dMCdNiuj__3aNFWmAH6RPWkmNKjTs=.8da87038-a970-45e5-b997-29ec85d88e20@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

I see. Thanks.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13677#pullrequestreview-1404319290

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

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

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

  CSR recommendations

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

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

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

  Stats: 115 lines in 3 files changed: 71 ins; 27 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From naoto at openjdk.org  Thu Apr 27 18:34:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Apr 2023 18:34:23 GMT
Subject: <i18n dev> Integrated: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <g6vRExS-qEe5UeT6IwNwVGpAQzxfbVb59C9uMCgL0-o=.9b865134-649c-4603-a611-d469fbe7d652@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

This pull request has now been integrated.

Changeset: 6983d05b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6983d05b73258f11dcb35bc3961b724ba58d9667
Stats:     50 lines in 2 files changed: 45 ins; 4 del; 1 mod

8306927: Collator treats "v" and "w" as the same letter for Swedish language locale.

Reviewed-by: jlu, iris, joehw

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

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

From jlu at openjdk.org  Fri Apr 28 00:35:26 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 28 Apr 2023 00:35:26 GMT
Subject: <i18n dev> Integrated: 8306711: Improve diagnosis of `IntlTest`
 framework
In-Reply-To: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
References: <qRAjYo1qpxKfT4sO5lmZI5NnpRG0lIvKstIBrPc0nLQ=.563f4c02-fce9-4077-b38f-80e6c9fbf310@github.com>
Message-ID: <ej0C_wha2hoQ7VDUkLDzLwoXTcoXPCCshJ61OCRi9TM=.f53ce08b-7e54-4e09-9159-db0e075b4224@github.com>

On Tue, 25 Apr 2023 20:28:33 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to the IntlTest (test framework) class. 
> 
> These changes include
> - Logging the actual exception + stack trace. Previously, the test framework would throw `InvocationTargetException` but hide the actual underlying exception of the failing test unless the test class was ran with -nothrow.
> - Sorting the tests, ensuring for any given run, the tests are ran in the same order. (In [JDK-8305853](https://bugs.openjdk.org/browse/JDK-8305853) it was discovered that on Windows, the test framework would execute tests in a random order each time).
> - Improving output.

This pull request has now been integrated.

Changeset: f3c90f04
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f3c90f0445df359a8bc03630fc5cde2843bbfef1
Stats:     171 lines in 2 files changed: 68 ins; 54 del; 49 mod

8306711: Improve diagnosis of `IntlTest` framework

Reviewed-by: naoto, lancea

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

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

From duke at openjdk.org  Fri Apr 28 16:36:57 2023
From: duke at openjdk.org (Madjosz)
Date: Fri, 28 Apr 2023 16:36:57 GMT
Subject: <i18n dev> Integrated: 8302983:
 ZoneRulesProvider.registerProvider() twice will remove provider
In-Reply-To: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
References: <AAfM5rBLeq2B3ttHBX_7kw0_rjfIVPSdcEL23HiOhVs=.b17c2586-b0bc-46ad-9501-0cf8363f82b9@github.com>
Message-ID: <nEVQOx5QSQJhl2y6h3i6qT4RocoBjdPlkGvvyCLily4=.4d21c348-6ac8-4c8a-9c3a-13dd9bdf0946@github.com>

On Tue, 21 Feb 2023 13:44:52 GMT, Madjosz <duke at openjdk.org> wrote:

> Fixes JDK-8302983 (and duplicate JDK-8302898)

This pull request has now been integrated.

Changeset: f83e7302
Author:    Madjosz <28844868+Madjosz at users.noreply.github.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f83e7302c1660c128f866daa7317bc1dce156686
Stats:     87 lines in 2 files changed: 63 ins; 17 del; 7 mod

8302983: ZoneRulesProvider.registerProvider() twice will remove provider

Reviewed-by: naoto

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

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