From stefank at openjdk.org  Tue Jan  2 15:36:07 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:07 GMT
Subject: <i18n dev> RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v4]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <yEDcAV7XwAPsBX5Z4vPBDDUowP57us2a3WIW5bJ6vyk=.d55a077c-b8c9-4050-ad9d-08337753fbae@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

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

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/5d488f42..486dc6d5

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

  Stats: 5249 lines in 348 files changed: 3069 ins; 973 del; 1207 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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

From stefank at openjdk.org  Tue Jan  2 15:36:10 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 2 Jan 2024 15:36:10 GMT
Subject: <i18n dev> RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v3]
In-Reply-To: <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
 <rOdHN6_YCb1J7nbJbJ3uAZ0_octri-wWhlPPrC04HYQ=.a13d7a73-71f2-403b-8efa-6aa614a0c11e@github.com>
Message-ID: <yDnkf3CvvXwTidrzaz6lrvS6XZVKBLVbJEOqBXwPi6M=.e4ddf28f-f03d-4c37-b831-a7206a202755@github.com>

On Mon, 11 Dec 2023 14:06:43 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
>> 
>> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
>> 
>> With these functions it is common to see the following pattern in tests:
>> 
>> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
>> OutputAnalyzer output = executeProcess(pb);
>> 
>> 
>> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
>> 
>> OutputAnalyzer output = ProcessTools.executeTestJvm();
>> 
>> 
>> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.
>
> Stefan Karlsson has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test cleanup

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17049#issuecomment-1874176578

From stefank at openjdk.org  Wed Jan  3 07:55:12 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 07:55:12 GMT
Subject: <i18n dev> RFR: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder [v5]
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <GpEb2qpnxJqXX5Ogimr2sbaXPOyFbB7wh06f0a47vc8=.96bd91bf-8487-49e0-8112-77843e7e3b15@github.com>

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

Stefan Karlsson 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 five additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Merge remote-tracking branch 'upstream/master' into rename_executeTestJvm
 - Test cleanup
 - Fix impl and add test
 - 8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17049/files
  - new: https://git.openjdk.org/jdk/pull/17049/files/486dc6d5..755d925d

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

  Stats: 875 lines in 70 files changed: 577 ins; 58 del; 240 mod
  Patch: https://git.openjdk.org/jdk/pull/17049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17049/head:pull/17049

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

From stefank at openjdk.org  Wed Jan  3 08:55:54 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 3 Jan 2024 08:55:54 GMT
Subject: <i18n dev> Integrated: 8321713: Harmonize executeTestJvm with
 create[Limited]TestJavaProcessBuilder
In-Reply-To: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
References: <fIIn7OfSFIv_Or1dUx5NasB9s0qgov89khLMR73wFQs=.b026b011-764d-48cc-a728-baf350e1a30a@github.com>
Message-ID: <97p3loy_9ZZnMenWO0FMfeACOTWUjesg8dVD6fmYCzs=.160baa3e-3709-4ece-a3aa-986206b73148@github.com>

On Mon, 11 Dec 2023 09:15:50 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> [JDK-8315097](https://bugs.openjdk.org/browse/JDK-8315097): 'Rename createJavaProcessBuilder' changed the name of the ProcessTools helper functions used to create `ProcessBuilder`s used to spawn new java test processes.
> 
> We now have `createTestJavaProcessBuilder` and `createLimitedTestJavaProcess`. The former prepends jvm options from jtreg, while the latter doesn't.
> 
> With these functions it is common to see the following pattern in tests:
> 
> ProcessBuilder pb = ProcessTools.createTestJavaProcessBuilder(...);
> OutputAnalyzer output = executeProcess(pb);
> 
> 
> We have a couple of thin wrapper in `ProcessTools` that does exactly this, so that the code can be written as a one-liner:
> 
> OutputAnalyzer output = ProcessTools.executeTestJvm();
> 
> 
> I propose that we name this functions using the same naming scheme we used for `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder`. That is, we change `executeTestJvm` to `executeTestJava` and add a new `executeLimitedTestJava` function.

This pull request has now been integrated.

Changeset: cbe329b9
Author:    Stefan Karlsson <stefank at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cbe329b90ac1488836d4852fead79aa26c082114
Stats:     262 lines in 89 files changed: 73 ins; 1 del; 188 mod

8321713: Harmonize executeTestJvm with create[Limited]TestJavaProcessBuilder

Reviewed-by: lkorinth, lmesnik

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

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

From jlu at openjdk.org  Wed Jan  3 23:38:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 Jan 2024 23:38:09 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve LocaleProvidersRun
Message-ID: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>

Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.

_LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.

In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).

Other updates
- For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
- For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
- Added comments for each test method

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

Commit messages:
 - remove LocaleProvidersLoggdersLogger from extending LocaleProvidersRun
 - replace non en locale check with Junit annotation
 - init

Changes: https://git.openjdk.org/jdk/pull/17257/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17257&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322235
  Stats: 554 lines in 7 files changed: 412 ins; 87 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From duke at openjdk.org  Thu Jan  4 13:40:41 2024
From: duke at openjdk.org (Johny Jose)
Date: Thu, 4 Jan 2024 13:40:41 GMT
Subject: <i18n dev> RFR: 8322725: (tz) Update Timezone Data to 2023d
Message-ID: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>

tzdata2023d changes

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

Commit messages:
 - 8322725: (tz) Update Timezone Data to 2023d

Changes: https://git.openjdk.org/jdk/pull/17268/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322725
  Stats: 140 lines in 14 files changed: 94 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/17268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17268/head:pull/17268

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

From duke at openjdk.org  Thu Jan  4 13:46:21 2024
From: duke at openjdk.org (Johny Jose)
Date: Thu, 4 Jan 2024 13:46:21 GMT
Subject: <i18n dev> RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <eYqYdEsFUcbqxVwWfS-mgLaLF_nj4u6bDK7cihKLSvM=.1b15408f-cfbe-4cbd-927a-d8397c58cd15@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

@naotoj Can you please review the changes

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

PR Comment: https://git.openjdk.org/jdk/pull/17268#issuecomment-1877117106

From coffeys at openjdk.org  Thu Jan  4 15:13:21 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Thu, 4 Jan 2024 15:13:21 GMT
Subject: <i18n dev> RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <imBWJNEeMQRsrpA3-FkpwYmYZ97nT-DDLSXBfDTphyw=.ea4286e5-f235-4731-b7bd-cf5555b2879e@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17268#pullrequestreview-1804359390

From naoto at openjdk.org  Thu Jan  4 17:19:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:19:35 GMT
Subject: <i18n dev> Integrated: 8322647: Short name for the `Europe/Lisbon`
 time zone is incorrect
In-Reply-To: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
Message-ID: <7U1F8HZlHjkwQOMf9lgE6kQ0JF891LNcAynooll3Dbo=.2dc9121a-31a9-4681-977d-6101ddf283cf@github.com>

On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:
> 
> --- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
> +++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
> @@ -304,11 +304,11 @@
>              };
>          final String[] Azores = new String[] {
>                 "Azores Standard Time",
> -               "HMT",
> +               "",
>                 "Azores Summer Time",
> -               "HMT",
> +               "",
>                 "Azores Time",
> -               "HMT",
> +               "",
>              };
>          final String[] Bhutan = new String[] {
>                 "Bhutan Time",
> @@ -968,11 +968,11 @@
>              };
>          final String[] Africa_Central = new String[] {
>                 "Central Africa Time",
> -               "SAST",
> -               "",
> -               "SAST",
> +               "CAT",
>                 "",
> -               "SAST",
> +               "CAT",
> +               "",
> +               "CAT",
>              };
>          final String[] Africa_Eastern = new String[] {
>                 "East Africa Time",
> @@ -1016,11 +1016,11 @@
>              };
>          final String[] Europe_Western = new String[] {
>                 "Western European Standard Time",
> -               "FMT",
> -               "Western European Summer Time",
> -               "FMT",
> +               "WET",
> +               "Western European Summer Time",
> +               "WEST",
>                 "Western European Time",
> -               "FMT",
> +               "WET",
>              };
>          final String[] Mexico_Pacific = new String[] {
>                 "Mexican Pacific Standard Time",
> @@ -1152,11 +1152,11 @@
>              };
>          final String[] Australia_Western = new String[] {
>                 "Australian Western Standard Time",
> -               "",
> +               "AWST",
>                 "Australian Western Daylight Time",
> -               "",
> +               "AWDT",
>                 "Western Australia Time",
> -               "",
> +               "AWT",
>              };
>          final String[] Greenland_Eastern = new String[] {
>                 "East Greenland Standard Time",
> 
> Previously, they all had wrong short names due to incorrect parsi...

This pull request has now been integrated.

Changeset: ad31ec5c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad31ec5c5f120082cedd7b9ece45b6b44147c0c5
Stats:     94 lines in 3 files changed: 72 ins; 2 del; 20 mod

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Reviewed-by: joehw, iris

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

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

From naoto at openjdk.org  Thu Jan  4 17:19:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:19:34 GMT
Subject: <i18n dev> RFR: 8322647: Short name for the `Europe/Lisbon`
 time zone is incorrect
In-Reply-To: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
References: <cBXYY9xbMBf9qIWtQ5bg-JrtQRO0XBzPNj7NHrUKbS8=.80cda0a4-4008-4b48-b3f5-2d736ac60a9c@github.com>
Message-ID: <xdxD6Zc7M-P2Gr8IDR027gYdZFqVH1KlG8Phl5q0jPE=.bcc5a0e2-057c-4f0f-8cfd-97f1bff1d2fa@github.com>

On Fri, 22 Dec 2023 18:59:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a regression caused by the fix to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979), where the parsing of TZDB files was incorrect. With this fix, `TimeZoneNames_en.java` which is generated during the build time has the following diffs from the previous (incorrect) one:
> 
> --- master/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-18 10:28:57
> +++ tz/build/macosx-aarch64/support/gensrc/java.base/sun/util/resources/cldr/TimeZoneNames_en.java	2023-12-22 10:09:13
> @@ -304,11 +304,11 @@
>              };
>          final String[] Azores = new String[] {
>                 "Azores Standard Time",
> -               "HMT",
> +               "",
>                 "Azores Summer Time",
> -               "HMT",
> +               "",
>                 "Azores Time",
> -               "HMT",
> +               "",
>              };
>          final String[] Bhutan = new String[] {
>                 "Bhutan Time",
> @@ -968,11 +968,11 @@
>              };
>          final String[] Africa_Central = new String[] {
>                 "Central Africa Time",
> -               "SAST",
> -               "",
> -               "SAST",
> +               "CAT",
>                 "",
> -               "SAST",
> +               "CAT",
> +               "",
> +               "CAT",
>              };
>          final String[] Africa_Eastern = new String[] {
>                 "East Africa Time",
> @@ -1016,11 +1016,11 @@
>              };
>          final String[] Europe_Western = new String[] {
>                 "Western European Standard Time",
> -               "FMT",
> -               "Western European Summer Time",
> -               "FMT",
> +               "WET",
> +               "Western European Summer Time",
> +               "WEST",
>                 "Western European Time",
> -               "FMT",
> +               "WET",
>              };
>          final String[] Mexico_Pacific = new String[] {
>                 "Mexican Pacific Standard Time",
> @@ -1152,11 +1152,11 @@
>              };
>          final String[] Australia_Western = new String[] {
>                 "Australian Western Standard Time",
> -               "",
> +               "AWST",
>                 "Australian Western Daylight Time",
> -               "",
> +               "AWDT",
>                 "Western Australia Time",
> -               "",
> +               "AWT",
>              };
>          final String[] Greenland_Eastern = new String[] {
>                 "East Greenland Standard Time",
> 
> Previously, they all had wrong short names due to incorrect parsi...

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17187#issuecomment-1877474644

From naoto at openjdk.org  Thu Jan  4 17:32:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:32:44 GMT
Subject: <i18n dev> [jdk22] RFR: 8322647: Short name for the `Europe/Lisbon`
 time zone is incorrect
Message-ID: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

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

Commit messages:
 - Backport ad31ec5c5f120082cedd7b9ece45b6b44147c0c5

Changes: https://git.openjdk.org/jdk22/pull/30/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=30&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322647
  Stats: 94 lines in 3 files changed: 72 ins; 2 del; 20 mod
  Patch: https://git.openjdk.org/jdk22/pull/30.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/30/head:pull/30

PR: https://git.openjdk.org/jdk22/pull/30

From joehw at openjdk.org  Thu Jan  4 17:42:33 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 4 Jan 2024 17:42:33 GMT
Subject: <i18n dev> [jdk22] RFR: 8322647: Short name for the
 `Europe/Lisbon` time zone is incorrect
In-Reply-To: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
References: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
Message-ID: <KWGA2wG7Tax9_Em3pG6hExibFT-PnJpveqipEp1LlYE=.ce66c9ed-38d1-44cd-823c-fb00802dfa68@github.com>

On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/30#pullrequestreview-1804685583

From naoto at openjdk.org  Thu Jan  4 17:54:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:54:23 GMT
Subject: <i18n dev> RFR: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <MyYwlRz7CHmhMO1j9PIpwDIPERM466h24cl9cy2UAdY=.bdf4c779-8c49-45cf-9c6a-2d7147d49322@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

LTGM too, assuming all the tests passed

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17268#pullrequestreview-1804702013

From naoto at openjdk.org  Thu Jan  4 17:54:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 17:54:24 GMT
Subject: <i18n dev> [jdk22] Integrated: 8322647: Short name for the
 `Europe/Lisbon` time zone is incorrect
In-Reply-To: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
References: <HNGa1wU36qxWIt7JC47OPjot-WPAQHyNDh1_GvrJkok=.a243c251-069c-435c-a3c8-cf36005871b9@github.com>
Message-ID: <WSeq-HZfVIKvNrhhcTCMRqHqL20vTq_090WC-HJwxfQ=.7d01ce32-b7ea-46fd-b23d-bb3d22afe2f6@github.com>

On Thu, 4 Jan 2024 17:26:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> 8322647: Short name for the `Europe/Lisbon` time zone is incorrect

This pull request has now been integrated.

Changeset: a72afb38
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a72afb3845a7d245d462904e75b9368efefc0d39
Stats:     94 lines in 3 files changed: 72 ins; 2 del; 20 mod

8322647: Short name for the `Europe/Lisbon` time zone is incorrect

Reviewed-by: joehw
Backport-of: ad31ec5c5f120082cedd7b9ece45b6b44147c0c5

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

PR: https://git.openjdk.org/jdk22/pull/30

From naoto at openjdk.org  Thu Jan  4 19:05:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:05:24 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>

On Wed, 3 Jan 2024 23:30:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
> - Added comments for each test method

Great to see this refactoring! Much cleaner now.

test/jdk/java/util/Locale/LocaleProvidersFormat.java line 30:

> 28:  * @library /test/lib
> 29:  * @build LocaleProviders
> 30:  *        providersrc.spi.src.tznp8013086

Although it is not needed in this test, I would list `tznp` to be built here, as the provider's meta-info includes both classes for completeness. Applies to `LocaleProvidersTimeZone` test too.

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

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1804804618
PR Review Comment: https://git.openjdk.org/jdk/pull/17257#discussion_r1442145501

From naoto at openjdk.org  Thu Jan  4 19:25:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:25:41 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v6]
In-Reply-To: <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <-g3xZNoboLRPlrTcQv17TGig7R0WNUJ0oJDAIWc0lwo=.f7946875-077b-4d15-a5a9-bb415b3ab062@github.com>
Message-ID: <JslKhkxUZqS5ooElquVSNQk5NaBAiFf6cGr3gsmBxdU=.def5cfe8-5bbf-46cd-a839-50a3647e2bec@github.com>

On Wed, 30 Aug 2023 22:35:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 31 commits:
> 
>  - Restored the test
>  - Merge branch 'master' into JDK-8309622-Cache-BaseLocale
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8309622-Cache-BaseLocale
>  - small cleanup
>  - Merge branch 'pull/14684' into JDK-8309622-Cache-BaseLocale
>  - Update ReferencedKeyTest.java
>  - Simple versions of create
>  - Add flag for reference queue type
>  - Merge branch 'master' into 8310913
>  - Update to use VirtualThread friendly stale queue.
>  - ... and 21 more: https://git.openjdk.org/jdk/compare/99ea8bf2...b1f64e93

keep open

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1877639764

From jlu at openjdk.org  Thu Jan  4 19:30:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jan 2024 19:30:00 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v2]
In-Reply-To: <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <8KYg2XUArUxeAW7xH7-wP2ibaXYhzOiG65ytLUUsE6Y=.9e0aa2fa-09d7-41d7-bbac-dcb2d1267526@github.com>
Message-ID: <THOfdHNK9gn-9-XbkMJBU2h0UAt8S0R5ilmkuAMYcak=.c0fa554e-bd86-4eb4-b5ef-bdefe6ca5d07@github.com>

On Thu, 4 Jan 2024 19:01:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - cleanup comments
>>  - provide both SPI classes under build for relevant test files
>
> test/jdk/java/util/Locale/LocaleProvidersFormat.java line 30:
> 
>> 28:  * @library /test/lib
>> 29:  * @build LocaleProviders
>> 30:  *        providersrc.spi.src.tznp8013086
> 
> Although it is not needed in this test, I would list `tznp` to be built here, as the provider's meta-info includes both classes for completeness. Applies to `LocaleProvidersTimeZone` test too.

That makes sense, updated both the relevant test files as you suggested. Thank you for taking the time to review this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17257#discussion_r1442166693

From jlu at openjdk.org  Thu Jan  4 19:30:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Jan 2024 19:30:00 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v2]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
> - Added comments for each test method

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

 - cleanup comments
 - provide both SPI classes under build for relevant test files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/b38b9909..a75237dc

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

  Stats: 23 lines in 5 files changed: 12 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From naoto at openjdk.org  Thu Jan  4 19:45:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 Jan 2024 19:45:23 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v2]
In-Reply-To: <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <emagDeQpr9-YfV62FoAa_hQL6gCUCK4UCeSYH_xzED4=.41465146-1251-405f-9f37-30a8b14d1957@github.com>
Message-ID: <8AMY6YNVKUXnE5dqjYHWoAnKv5F9P7dTTmEKMeAZ2eg=.4aa44e24-a8df-4abb-af8f-a191f45ef1ac@github.com>

On Thu, 4 Jan 2024 19:30:00 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
>> 
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
>> 
>> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
>> 
>> Other updates
>> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
>> - For tests that are meant to be tested against specific locales, additional run invocations were added with the appropiate locale to guarantee a run (ex: `@run junit/othervm -Duser.language=en -Duser.country=GB`)
>> - Added comments for each test method
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - cleanup comments
>  - provide both SPI classes under build for relevant test files

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1804861121

From duke at openjdk.org  Fri Jan  5 08:15:33 2024
From: duke at openjdk.org (Johny Jose)
Date: Fri, 5 Jan 2024 08:15:33 GMT
Subject: <i18n dev> Integrated: 8322725: (tz) Update Timezone Data to 2023d
In-Reply-To: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
References: <WQeefDN68QGN6UCZ7Mk5ZhdKX2jkgAfxwrnPBELg2Mg=.c6c4b976-2ca1-4a2d-b74e-93191a2c5713@github.com>
Message-ID: <4UBo8oLvyPwMubDYKzSz1PqINlWsRhxbejzSL4wN9AY=.e6479968-1879-4678-9679-5f201ed3be81@github.com>

On Thu, 4 Jan 2024 13:34:50 GMT, Johny Jose <duke at openjdk.org> wrote:

> tzdata2023d changes

This pull request has now been integrated.

Changeset: 2a9c3589
Author:    Johny Jose <johny.jose at oracle.com>
Committer: Sean Coffey <coffeys at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc
Stats:     140 lines in 14 files changed: 94 ins; 15 del; 31 mod

8322725: (tz) Update Timezone Data to 2023d

Reviewed-by: coffeys, naoto

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

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

From dlutker at openjdk.org  Fri Jan  5 17:46:34 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Fri, 5 Jan 2024 17:46:34 GMT
Subject: <i18n dev> [jdk22] RFR: 8322725: (tz) Update Timezone Data to 2023d
Message-ID: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>

Clean backport tzdata 2023d.
`make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

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

Commit messages:
 - Backport 2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc

Changes: https://git.openjdk.org/jdk22/pull/35/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=35&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322725
  Stats: 140 lines in 14 files changed: 94 ins; 15 del; 31 mod
  Patch: https://git.openjdk.org/jdk22/pull/35.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/35/head:pull/35

PR: https://git.openjdk.org/jdk22/pull/35

From vladimir.petko at canonical.com  Sun Jan  7 19:50:28 2024
From: vladimir.petko at canonical.com (Vladimir Petko)
Date: Mon, 8 Jan 2024 08:50:28 +1300
Subject: <i18n dev> JDK-8286154: fix 3rd party notices in test files
Message-ID: <CALFf3kf_JoFL_zYjecnTkYUnnDJDF+_Rvx=5WGAC=_+uT20=iw@mail.gmail.com>

Hi,

I18n tests listed in JDK-8286154[1] contain a notice stating that
their license is only valid for non-commercial purposes.

The requirement contradicts GNU GPLv2[1]. JDK-8286154 tried to address
it, but the original notice is still present, and the requirement for
non-commercial use still applies.

I wonder if rewriting the affected tests solves the issue.
I would be happy to work on it if this approach is valid.

Best Regards,
 Vladimir.

[1] https://bugs.openjdk.org/browse/JDK-8286154

From naoto at openjdk.org  Tue Jan  9 17:17:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 17:17:27 GMT
Subject: <i18n dev> [jdk22] RFR: 8322725: (tz) Update Timezone Data to
 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <zWIt8iQrg6ZU2HYwQ1LExy7WnhQ90YSZ4J-e1K2oXvo=.ff1d8475-56d0-4691-8ca5-ef0c2eda170a@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

LGTM. Thanks for the backport.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/35#pullrequestreview-1811635378

From iris at openjdk.org  Tue Jan  9 17:39:22 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 17:39:22 GMT
Subject: <i18n dev> [jdk22] RFR: 8322725: (tz) Update Timezone Data to
 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <xLpz0NnPU2zXvtF8ZtRd4KVFnXgeYgYTbR8_UkLaWuU=.1fcd7915-1c51-4dc2-b312-adb1fd0eb93a@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/35#pullrequestreview-1811674978

From dlutker at openjdk.org  Tue Jan  9 17:56:24 2024
From: dlutker at openjdk.org (Dan Lutker)
Date: Tue, 9 Jan 2024 17:56:24 GMT
Subject: <i18n dev> [jdk22] Integrated: 8322725: (tz) Update Timezone Data
 to 2023d
In-Reply-To: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
References: <xGa_xtZsoSOFGpH8xm1fpc3Jw7bUvMT1Jbni7LCFJuM=.4de8c4a3-0abf-47e7-b651-dc37e195aea9@github.com>
Message-ID: <FUQZ9fsukHUswq12Zx7WVvHweBiExIfjzPbk1nOOtDM=.1f84667f-4152-4b88-b012-deb663cfe34b@github.com>

On Fri, 5 Jan 2024 17:05:04 GMT, Dan Lutker <dlutker at openjdk.org> wrote:

> Clean backport tzdata 2023d.
> `make test TEST="test/jdk/java/util/TimeZone test/jdk/java/time/test test/jdk/sun/util/resources test/jdk/sun/text/resources test/jdk/sun/util/calendar"` is all passing

This pull request has now been integrated.

Changeset: acc4829e
Author:    Dan Lutker <dlutker at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/acc4829ec39b3a7dacd3e2a872ba3becd89b175e
Stats:     140 lines in 14 files changed: 94 ins; 15 del; 31 mod

8322725: (tz) Update Timezone Data to 2023d

Reviewed-by: naoto, iris
Backport-of: 2a9c3589d941d9a57e536ea0b3d7919c6ddb82dc

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

PR: https://git.openjdk.org/jdk22/pull/35

From naoto at openjdk.org  Tue Jan  9 18:26:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 18:26:30 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing some
 properties
Message-ID: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>

Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has alos been drafted.

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

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

Commit messages:
 - initial commit

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

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

From iris at openjdk.org  Tue Jan  9 19:05:24 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 19:05:24 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>

On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

src/java.base/share/classes/java/lang/System.java line 818:

> 816:      * {@link #getProperty(String)} operation.
> 817:      * <p>
> 818:      * In addition to the above set of system properties, locale related

I think I'd consider a slight reduction in the first/last phrases leaving this equivalent statement:

Additional locale-related system properties defined by the {@link Locale##default_locale Default Locale} section in the {@code Locale} class description may also be obtained with this method.

(Note that I couldn't find the referenced Locale section, but perhaps I was looking at an older version of the spec.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446489646

From naoto at openjdk.org  Tue Jan  9 19:23:53 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:23:53 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17317/files
  - new: https://git.openjdk.org/jdk/pull/17317/files/19128cc8..b1d31163

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

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

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

From naoto at openjdk.org  Tue Jan  9 19:28:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:28:25 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <ghuDMQmj_CqvIIbcuhvDJyBQf4foVBTEiLkddfSZORU=.1e976ca6-7644-410a-9b44-0174fc0a8cca@github.com>
Message-ID: <sFNooffpbu7SRfyuENb2XcqJpbExD0KTdlHNf-eu8t0=.d10e8370-5a9a-4fb6-ac60-18ee30c53238@github.com>

On Tue, 9 Jan 2024 19:02:39 GMT, Iris Clark <iris at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 818:
> 
>> 816:      * {@link #getProperty(String)} operation.
>> 817:      * <p>
>> 818:      * In addition to the above set of system properties, locale related
> 
> I think I'd consider a slight reduction in the first/last phrases leaving this equivalent statement:
> 
> Additional locale-related system properties defined by the {@link Locale##default_locale Default Locale} section in the {@code Locale} class description may also be obtained with this method.
> 
> (Note that I couldn't find the referenced Locale section, but perhaps I was looking at an older version of the spec.)

That's concise and clearer. Replaced the wording. As to the referenced Locale section, it is in the PR (#17065) which this PR is dependent on and is not yet integrated. Sorry for the confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446509254

From jlu at openjdk.org  Tue Jan  9 19:38:42 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jan 2024 19:38:42 GMT
Subject: <i18n dev> [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
Message-ID: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>

Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

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

Commit messages:
 - Backport 8b24851b9d3619c41c7a6cdb9193ed26a9b732dc

Changes: https://git.openjdk.org/jdk22/pull/45/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=45&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8321480
  Stats: 43 lines in 5 files changed: 10 ins; 0 del; 33 mod
  Patch: https://git.openjdk.org/jdk22/pull/45.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/45/head:pull/45

PR: https://git.openjdk.org/jdk22/pull/45

From naoto at openjdk.org  Tue Jan  9 19:44:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 19:44:26 GMT
Subject: <i18n dev> [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <h3nkY91F6Dk0MqEEmKYcEChACde8bVDXBD6mIyPWdl8=.ba2c97d0-3498-49f8-8ee2-74ed0bea7c23@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/45#pullrequestreview-1811865198

From iris at openjdk.org  Tue Jan  9 20:01:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 20:01:23 GMT
Subject: <i18n dev> [jdk22] RFR: 8321480: ISO 4217 Amendment 176 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <8CTfAXZVKWBPS8F4Q4g0zl-WfR1cAd4duwdhvvfo1Zc=.5d007b8e-ef02-4eb5-9ee8-e4347e4ca352@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

Confirmed changes identical to those in main-line.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/45#pullrequestreview-1811892304

From iris at openjdk.org  Tue Jan  9 20:05:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 9 Jan 2024 20:05:23 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <-IvORgI8rz7JVl4RnKgDp-xIwHFr90hzLKQfs6hV2oU=.c16e40b3-cd82-4657-9d43-9ce0e128558c@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Looks good.  Associated CSR also Reviewed.

Thanks for the clarification regarding the pending new section in Locale.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811895882

From joehw at openjdk.org  Tue Jan  9 20:05:25 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Jan 2024 20:05:25 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/lang/System.java line 819:

> 817:      * <p>
> 818:      * Additional locale-related system properties defined by the
> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}

Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446542159

From rriggs at openjdk.org  Tue Jan  9 20:09:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 20:09:22 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <09sqOazp5DWhr4hCA5xzAiaFVRjToA83nb95B6fTG5A=.e74b7353-2213-4877-801b-39f6580b7847@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811902084

From rriggs at openjdk.org  Tue Jan  9 20:09:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 Jan 2024 20:09:24 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
 <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
Message-ID: <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>

On Tue, 9 Jan 2024 20:01:28 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/lang/System.java line 819:
> 
>> 817:      * <p>
>> 818:      * Additional locale-related system properties defined by the
>> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}
> 
> Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.

The "##" refers to a normal html tag or id in the target page.  A single "#" refers to a javadoc defined method or field.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446545971

From bpb at openjdk.org  Tue Jan  9 20:36:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Jan 2024 20:36:23 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <XkodRePcgpHJyuMbSsGYskOBIeFIozxCc-gaw-rNuC4=.8ea825da-ec44-4d09-b05d-4d609b9fcc90@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811961077

From joehw at openjdk.org  Tue Jan  9 20:52:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Jan 2024 20:52:23 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
Message-ID: <q8GpaWt2ojkAa07QPojAww7t-sKmAx-SQpejCKFctFM=.38f4510e-4073-4f8a-b51d-d3089fd5e6f1@github.com>

On Tue, 9 Jan 2024 19:23:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17317#pullrequestreview-1811984674

From jlu at openjdk.org  Tue Jan  9 22:58:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 Jan 2024 22:58:26 GMT
Subject: <i18n dev> [jdk22] Integrated: 8321480: ISO 4217 Amendment 176
 Update
In-Reply-To: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
References: <_fD56XDZ_RYS1zoJUrDnycPJ_16YnUuQAUwM1CLJ-BQ=.1f4868b5-9320-4277-b305-9198cb7a5376@github.com>
Message-ID: <Q5kK4z9sXmm9qpdwFFNqD5itXP0b5OWUniZqu3fBYcw=.3e6d1559-a7a3-4090-810d-f32e5bd10c42@github.com>

On Tue, 9 Jan 2024 19:27:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is the backport of the ISO 4217 Amendment 176 Update. Commit [8b24851b](https://github.com/openjdk/jdk/commit/8b24851b9d3619c41c7a6cdb9193ed26a9b732dc) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

This pull request has now been integrated.

Changeset: a8df5597
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/a8df5597638c4cbcbc9a56bad7034b9af5efc32d
Stats:     43 lines in 5 files changed: 10 ins; 0 del; 33 mod

8321480: ISO 4217 Amendment 176 Update

Reviewed-by: naoto, iris
Backport-of: 8b24851b9d3619c41c7a6cdb9193ed26a9b732dc

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

PR: https://git.openjdk.org/jdk22/pull/45

From naoto at openjdk.org  Tue Jan  9 23:14:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:14:34 GMT
Subject: <i18n dev> Integrated: 8320919: Clarify Locale related system
 properties
In-Reply-To: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
References: <IruGxIK9DXnXFDANt1y4sCMJEGZh1PTOKhOWZZxJEdc=.77092e02-fb4f-4c9e-8d53-0fa0cf3bae7d@github.com>
Message-ID: <7ejuSu-wzpLFmEEQjlvunZTqizCIPB6TrdZi0B1jejs=.8ed135cb-34e7-45a6-abca-ec0000b1dc5e@github.com>

On Mon, 11 Dec 2023 18:54:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is a doc change to clarify what the `Default Locale` is, and how it is established during the system startup using the system properties. Those locale-related system properties have existed since the early days of Java, but have never been publicly documented before. It is also the intention of this PR to clarify those system properties and how they are overridden. A corresponding CSR has been drafted.

This pull request has now been integrated.

Changeset: 376051a9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/376051a9be95e0e4acf3c59d0eba3e9ef8727d79
Stats:     81 lines in 1 file changed: 71 ins; 0 del; 10 mod

8320919: Clarify Locale related system properties

Reviewed-by: smarks, rriggs

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

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

From naoto at openjdk.org  Tue Jan  9 23:31:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:31:23 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v2]
In-Reply-To: <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <XtyT3q4NNtcAgxbw6SlbWpCfJH-q_x4vXBK0wNiotlU=.6a10d121-faf0-4102-9fe7-1dd3445595b5@github.com>
 <gxVCXf-kUdBGJxQiCsnQF2ejzsVEkQwJZfXHlNdGAIo=.b6a949e4-e62e-4cf9-8494-463dff11b5a7@github.com>
 <HVm_ZDxLjm3PezqqpAQ2sI4sRKQUGgTGRGdPJzW2Tfg=.ea5d196f-9996-4e27-beef-f6f6acfbdfb1@github.com>
Message-ID: <OfNGqjNz1Lb9iTBCgPgC1SWsyLX34NrODWr4nHYS1fE=.e5ab3520-223f-4b8b-869d-ff3ac5fe705d@github.com>

On Tue, 9 Jan 2024 20:06:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 819:
>> 
>>> 817:      * <p>
>>> 818:      * Additional locale-related system properties defined by the
>>> 819:      * {@link Locale##default_locale Default Locale} section in the {@code Locale}
>> 
>> Is that "##" a typo? double pound signs usually leads to the top of the page. I see PR 17065 also had "##" for links to default_locale.
>
> The "##" refers to a normal html tag or id in the target page.  A single "#" refers to a javadoc defined method or field.

Thanks, Joe. As Roger mentioned, the `##` can be used for user-defined anchors since JDK20 ( https://bugs.openjdk.org/browse/JDK-8294195)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17317#discussion_r1446723242

From naoto at openjdk.org  Tue Jan  9 23:40:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Jan 2024 23:40:35 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v3]
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:

 - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
 - Reflects review comments
 - initial commit
 - Reflects review comments
 - Reflects review comments
 - Reflects review comments
 - Reflects review comments
 - Review comments
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update src/java.base/share/classes/java/util/Locale.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

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

Changes: https://git.openjdk.org/jdk/pull/17317/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17317&range=02
  Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/17317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17317/head:pull/17317

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

From naoto at openjdk.org  Wed Jan 10 00:03:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 00:03:41 GMT
Subject: <i18n dev> [jdk22] RFR: 8320919: Clarify Locale related system
 properties
Message-ID: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>

Backporting the document clarification to JDK22

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

Commit messages:
 - Backport 376051a9be95e0e4acf3c59d0eba3e9ef8727d79

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

PR: https://git.openjdk.org/jdk22/pull/47

From iris at openjdk.org  Wed Jan 10 00:24:25 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 10 Jan 2024 00:24:25 GMT
Subject: <i18n dev> [jdk22] RFR: 8320919: Clarify Locale related system
 properties
In-Reply-To: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
References: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
Message-ID: <JFRmvMja10R9ecySA50ueSJT92hQCDgZji_yVHk3uHM=.34e3d47c-9712-44db-8da4-e2370606c756@github.com>

On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document clarification to JDK22

Confirmed that this change corresponds to the changes in main-line and the previously approved CSR.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/47#pullrequestreview-1812224747

From naoto at openjdk.org  Wed Jan 10 17:36:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 17:36:27 GMT
Subject: <i18n dev> [jdk22] Integrated: 8320919: Clarify Locale related
 system properties
In-Reply-To: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
References: <YvdtE3VhYtH5vJA7FA2Jnwj_T57XOhd-8foGikTdK9Q=.5ec244bc-f4ed-451c-b802-2e514ba1e1cd@github.com>
Message-ID: <UKVAatTvKdKoeKoyucQekSnW460pzudhe6gFeC2LDXM=.88681b32-e1af-401c-9838-29abb7ea9e5d@github.com>

On Tue, 9 Jan 2024 23:55:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Backporting the document clarification to JDK22

This pull request has now been integrated.

Changeset: 46b1b1ae
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/46b1b1ae8ddc9466bda5af5ba2e917ded3352f4d
Stats:     81 lines in 1 file changed: 71 ins; 0 del; 10 mod

8320919: Clarify Locale related system properties

Reviewed-by: iris
Backport-of: 376051a9be95e0e4acf3c59d0eba3e9ef8727d79

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

PR: https://git.openjdk.org/jdk22/pull/47

From naoto at openjdk.org  Wed Jan 10 18:56:38 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 18:56:38 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v3]
In-Reply-To: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
Message-ID: <DC0FVU3kM_ZT-MdKJReQoFcSVm_ZtEIsCm5kIWIttLg=.3d3e68c7-feae-426e-b716-c90db56cc7dd@github.com>

On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
>  - Reflects review comments
>  - initial commit
>  - Reflects review comments
>  - Reflects review comments
>  - Reflects review comments
>  - Reflects review comments
>  - Review comments
>  - Update src/java.base/share/classes/java/util/Locale.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update src/java.base/share/classes/java/util/Locale.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/17317#issuecomment-1885433436

From naoto at openjdk.org  Wed Jan 10 18:56:40 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 18:56:40 GMT
Subject: <i18n dev> Integrated: 8320788: The system properties page is
 missing some properties
In-Reply-To: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
Message-ID: <SfY9Yh4d3HI8o2gEQmSPjcAkZi061rRil4P7ASbCPpA=.fe694a35-ae78-4387-b30c-7d66108b5301@github.com>

On Tue, 9 Jan 2024 00:51:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 3bd90420
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3bd9042054116365323912ed5867b70936fe85c4
Stats:     5 lines in 1 file changed: 5 ins; 0 del; 0 mod

8320788: The system properties page is missing some properties

Reviewed-by: iris, rriggs, bpb, joehw

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

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

From jlu at openjdk.org  Wed Jan 10 21:05:53 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:05:53 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v3]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

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

 - clarify locale issues (OS)
 - rename testRun -> test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/a75237dc..c754893f

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

  Stats: 34 lines in 8 files changed: 5 ins; 2 del; 27 mod
  Patch: https://git.openjdk.org/jdk/pull/17257.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17257/head:pull/17257

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

From jlu at openjdk.org  Wed Jan 10 21:10:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:10:43 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses
Message-ID: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>

Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)

The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".

`MessageFormat` is the only Format subclass that can be constructed with a null locale, (hence the ternary in the implementation to prevent a potential NPE).
`ListFormat` already implemented toString(), and thus only the specification was updated to match the other Format subclasses.

An example of all the classes has output such as 


CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]

DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]

SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]

ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]

MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]

ChoiceFormat [pattern: "0#foo"]

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Wed Jan 10 21:26:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 Jan 2024 21:26:22 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v3]
In-Reply-To: <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
Message-ID: <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>

On Wed, 10 Jan 2024 21:05:53 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
>> 
>> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
>> 
>> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
>> 
>> Other updates
>> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
>> - Added comments for each test method
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - clarify locale issues (OS)
>  - rename testRun -> test

Still looks good. Please modify the copyright year for `HostLocaleProviderAdapter_md.c` file before integrating

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17257#pullrequestreview-1814204644

From jlu at openjdk.org  Wed Jan 10 21:36:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:36:49 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v4]
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <xDmLm8bYH06H4aCvU8y0MnKWT1bVmStVznEuQaI1kWo=.767fde36-a114-453d-82cf-bd3109ca911b@github.com>

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

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

  copyright year for HLPA_md.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17257/files
  - new: https://git.openjdk.org/jdk/pull/17257/files/c754893f..a619b255

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

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

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

From jlu at openjdk.org  Wed Jan 10 21:36:50 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 Jan 2024 21:36:50 GMT
Subject: <i18n dev> RFR: JDK-8322235: Split up and improve
 LocaleProvidersRun [v3]
In-Reply-To: <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
 <nsD8CP6v3XL_mBZVNTriXMPneChJcxtFrsF472s2Xak=.d154010c-a673-4446-97ea-dde4a75222e2@github.com>
 <tSXAunh4gUfA3HiCYyesUb8XVFN7QgqfZh3JIF-g510=.f9267d23-83c2-4c92-97b3-469e08e2359f@github.com>
Message-ID: <E0j-RGhypkTuylIjnJgwnuhY-rTX2VffS-a9FjTdAlM=.91bd1871-e995-41e4-85d2-3a105be94661@github.com>

On Wed, 10 Jan 2024 21:23:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Still looks good. Please modify the copyright year for `HostLocaleProviderAdapter_md.c` file before integrating

Totally missed that, thanks for catching. Will integrate after re-testing VM tiers.

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

PR Comment: https://git.openjdk.org/jdk/pull/17257#issuecomment-1885768744

From alanb at openjdk.org  Thu Jan 11 08:03:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Jan 2024 08:03:31 GMT
Subject: <i18n dev> RFR: 8320788: The system properties page is missing
 some properties [v3]
In-Reply-To: <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
References: <wWCniVXOxgopiwPzz1-3vMebr2y332tpAbBK3qAxBwY=.bb9d4123-81be-425c-97ee-7b7e0b0fc2da@github.com>
 <olHu0yzspkdZ6010JMkWn2nCUiGdCN6-0gt_-V0ORMY=.7b36663c-8261-484b-9886-56408740da92@github.com>
Message-ID: <Sbtda0eu1Y-X_5BWycnC4O-puqpIcE2LJijAeTDkUbU=.51881cb8-6706-4183-9f46-670f3700df60@github.com>

On Tue, 9 Jan 2024 23:40:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Adding an explanation of the locale-related system properties in the `System.getProperties()` method. Corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - Merge branch 'master' of https://git.openjdk.org/jdk into JDK-8320788-system.getProperties
>  - Reflects review comments
>  - initial commit
>  - Reflects review comments
>  - Reflects review comments
>  - Reflects review comments
>  - Reflects review comments
>  - Review comments
>  - Update src/java.base/share/classes/java/util/Locale.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update src/java.base/share/classes/java/util/Locale.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/376051a9...7444bb51

We need to think about whether the change proposed here will set precedence or not. There are many places in the API docs where system properties are specified but they aren't linked from System::getProperties.

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

PR Comment: https://git.openjdk.org/jdk/pull/17317#issuecomment-1886570976

From jlu at openjdk.org  Thu Jan 11 19:30:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Jan 2024 19:30:09 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v2]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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

 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/dfc49edb..1dfc949d

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

  Stats: 3057 lines in 78 files changed: 1931 ins; 706 del; 420 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

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

From naoto at openjdk.org  Thu Jan 11 19:45:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Jan 2024 19:45:24 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v2]
In-Reply-To: <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
Message-ID: <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>

On Thu, 11 Jan 2024 19:30:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]", decimal pattern: "foo#0.00#baz"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

I think test cases for these new overridden `toString()` methods would be helpful.

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

PR Comment: https://git.openjdk.org/jdk/pull/17355#issuecomment-1887851029

From jlu at openjdk.org  Thu Jan 11 21:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 Jan 2024 21:02:34 GMT
Subject: <i18n dev> Integrated: JDK-8322235: Split up and improve
 LocaleProvidersRun
In-Reply-To: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
References: <ReALR4SuO3jUDvHD7HNAZ_3obPbRUJOdEh5AB_sIQis=.bab67da4-f748-4d43-93d2-936d1395f5ed@github.com>
Message-ID: <euiNlwTTQio8HqaiIt9ePnguFt_3aTW_9kb8LMYySsE=.bd0e0b3b-72b3-48ba-b2f7-2ff95436e0d0@github.com>

On Wed, 3 Jan 2024 23:30:41 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which splits up the _LocaleProvidersRun_ test file for performance and maintenance reasons.
> 
> _LocaleProvidersRun_ which tests against the various Locale Providers (CLDR, HOST, SPI, etc.) was getting rather long, as all related bugs were added to the single test file. To improve maintainability, this change splits up the single test file into separate test files focused on specific areas (ex: _j.text.Format_).  The original _LocaleProvidersRun_ test file remains and is used for more general Locale Provider testing such as the adapter loading.
> 
> In addition, the previously single test file used to suffer from performance issues, as each test method had to launch a new JVM (since Locale Providers are set at Java startup time). With this change, these tests files can be ran with VM flags and not cause timeout, thus `@requires vm.flagless` is no longer needed (Tiers 6-8 tested).
> 
> Other updates
> - For OS/locale specific tests, the OS/locale is now checked before (not after) launching a JVM
> - Added comments for each test method

This pull request has now been integrated.

Changeset: 4ea7b364
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579
Stats:     569 lines in 8 files changed: 425 ins; 85 del; 59 mod

8322235: Split up and improve LocaleProvidersRun

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Fri Jan 12 18:27:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:27:55 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v2]
In-Reply-To: <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <ZU0P11ntQC0mI79Q-TbmqJBX3qrtjSrPGMcMo0WzsKY=.b85ec9ab-b407-45c0-a60e-8d627178cfd3@github.com>
 <DfkwfopSoREFkqMQ6N8dookEIBrMpIW7hnXc9rFgBXA=.b32455fe-20b2-4579-9136-f60ae82f6ee3@github.com>
Message-ID: <ZfeuSUwnrvTDWDTpIUR9xLug1zqg8TA5y7_7FxBTK1M=.5c4f5a90-1893-47c9-9ddc-ce87811884cb@github.com>

On Thu, 11 Jan 2024 19:42:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I think test cases for these new overridden `toString()` methods would be helpful.

Added test cases for the new methods. Additionally, in the most recent commit, I swapped the placement of `compact patterns` with `decimal pattern`. As `compact patterns` is generally much longer, I felt it helped readability if `decimal pattern` came first.

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

PR Comment: https://git.openjdk.org/jdk/pull/17355#issuecomment-1889761787

From jlu at openjdk.org  Fri Jan 12 18:27:55 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:27:55 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v3]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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

 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/1dfc949d..3157ec8e

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

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

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

From jlu at openjdk.org  Fri Jan 12 18:31:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 18:31:48 GMT
Subject: <i18n dev> [jdk22] RFR: 8322235: Split up and improve
 LocaleProvidersRun
Message-ID: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>

Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

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

Commit messages:
 - Backport 4ea7b36447ea96d62b1ca164c34e2b2b74a16579

Changes: https://git.openjdk.org/jdk22/pull/68/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=68&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322235
  Stats: 569 lines in 8 files changed: 425 ins; 85 del; 59 mod
  Patch: https://git.openjdk.org/jdk22/pull/68.diff
  Fetch: git fetch https://git.openjdk.org/jdk22.git pull/68/head:pull/68

PR: https://git.openjdk.org/jdk22/pull/68

From naoto at openjdk.org  Fri Jan 12 18:52:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 18:52:24 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v3]
In-Reply-To: <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <G2RApo4uByIHt5YIch5GttpbuanxN8MDwpR-I_SGSmo=.4c88f861-095d-4096-8c48-8e33d5fbc4d2@github.com>
Message-ID: <QCuMjRWFevrfhEQaDdBA_xnZLH3WHpc7AZG4nL0ILJE=.1211f409-2c77-45b7-92c5-a354e1b721a4@github.com>

On Fri, 12 Jan 2024 18:27:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests

Added tests look good.

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
> 1195:             """.formatted(locale == null ? "None" : locale.getDisplayName(), toPattern());

I think printing `null` for `locale == null` is better here, as `None` is sort of ambiguous. Applies to SDF (and related tests) as well.

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

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1818845217
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1450811275

From naoto at openjdk.org  Fri Jan 12 18:56:33 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 18:56:33 GMT
Subject: <i18n dev> [jdk22] RFR: 8322235: Split up and improve
 LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <ClMc3-aP9mHwD0BNSBor31_kklT9wB2E13Rtqc8-0TQ=.18ffa200-748e-4385-8649-60081e5650ae@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk22/pull/68#pullrequestreview-1818853193

From jlu at openjdk.org  Fri Jan 12 19:07:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 19:07:46 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v4]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

Justin Lu 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 eight additional commits since the last revision:

 - replace 'None' with 'null' for applicable classes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/3157ec8e..fa2345a2

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

  Stats: 5909 lines in 110 files changed: 3521 ins; 2087 del; 301 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

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

From iris at openjdk.org  Fri Jan 12 19:32:23 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 12 Jan 2024 19:32:23 GMT
Subject: <i18n dev> [jdk22] RFR: 8322235: Split up and improve
 LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <tcHnZt-jLsJwE-xGM6LGI2PdKzxX-2v4b80LN8-rkc0=.4417983b-7a78-4203-ac2c-45f38be4ddf2@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

Confirmed identical to changes in main-line.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk22/pull/68#pullrequestreview-1818908921

From naoto at openjdk.org  Fri Jan 12 19:38:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Jan 2024 19:38:23 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v4]
In-Reply-To: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
Message-ID: <aGyoRikBNZ1XikBUG65Bf9HFJlr94_x1nlJzeY8aMPY=.b9f60cde-52e8-49b7-8c85-9c52e7f15537@github.com>

On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu 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 eight additional commits since the last revision:
> 
>  - replace 'None' with 'null' for applicable classes
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

LGTM. The `locale` object could be passed to `formatted()` argument instead of the hard-coded `"null"`, but that is ok

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1818919978

From rriggs at openjdk.org  Fri Jan 12 21:36:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Jan 2024 21:36:24 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v4]
In-Reply-To: <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
Message-ID: <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>

On Fri, 12 Jan 2024 19:07:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu 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 eight additional commits since the last revision:
> 
>  - replace 'None' with 'null' for applicable classes
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - swap placement of decimal pattern and compact patterns. Expand on tests
>  - add unit tests
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - account for null locale for SDF through deserialization
>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>  - init

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
> 1195:             """.formatted(locale == null ? "null" : locale.getDisplayName(), toPattern());

It would be more accurate if when locale ==null that null was not quoted in the string.
Seeing "null" would imply that the displayName of the locale was "null", when it was `null`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1450941057

From jlu at openjdk.org  Fri Jan 12 22:41:46 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Jan 2024 22:41:46 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v5]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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

  remove quotes around locale when equal to null

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/fa2345a2..70e0a175

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

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

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

From acobbs at openjdk.org  Sun Jan 14 15:36:37 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 14 Jan 2024 15:36:37 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern
Message-ID: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>

Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.

The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.

In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.

The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.

So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.

An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.

However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.

As a result, invoking `f.format(new Object{} { 0, 5 })` will return `"option A: 5"` using the original `MessageFormat` but `"option A: 5}"` from a new one created with the string from `toPattern()`.

This patch fixes this problem by adding quotes around "extra" closing braces in the subformat pattern strings.

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

Commit messages:
 - Quote runs of extra unquoted closing braces in subformat patterns.

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

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

From jlu at openjdk.org  Tue Jan 16 22:07:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Jan 2024 22:07:59 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>

On Sun, 14 Jan 2024 15:32:12 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,

(Jshell with your patch)


var pattIn = "Test: {0,number,foo'{'#.00}";
MessageFormat mFmt = new MessageFormat(pattIn);
var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";



var pattIn = "Test: {0,number,foo'}'#.00}";
MessageFormat mFmt = new MessageFormat(pattIn);
var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";


As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 

Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1894594743

From jlu at openjdk.org  Tue Jan 16 22:13:04 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Jan 2024 22:13:04 GMT
Subject: <i18n dev> [jdk22] Integrated: 8322235: Split up and improve
 LocaleProvidersRun
In-Reply-To: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
References: <Wwob-qTsSfuq6cB5h5w4RadMM8_hG-EMiUMDNNgzKjc=.ff876eec-bed4-42df-92e3-aaaa0b248f01@github.com>
Message-ID: <z82E2vFsyIwuClqEqGTj5_H3eWjyTxSXVT1B4_vPr2g=.c39852e7-bd9b-4d7f-832b-13985e14fe34@github.com>

On Fri, 12 Jan 2024 18:25:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a backport of commit [4ea7b364](https://github.com/openjdk/jdk/commit/4ea7b36447ea96d62b1ca164c34e2b2b74a16579) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The original commit was a test-only change which optimized and split up the LocaleProvidersRun.java test.

This pull request has now been integrated.

Changeset: b9a535b8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk22/commit/b9a535b8ac2e7bd5c7c2e56c1b0a498fa9c94d2a
Stats:     569 lines in 8 files changed: 425 ins; 85 del; 59 mod

8322235: Split up and improve LocaleProvidersRun

Reviewed-by: naoto, iris
Backport-of: 4ea7b36447ea96d62b1ca164c34e2b2b74a16579

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

PR: https://git.openjdk.org/jdk22/pull/68

From prappo at openjdk.org  Wed Jan 17 21:26:02 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 17 Jan 2024 21:26:02 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for sealed
 in java.base
Message-ID: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>

Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

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

Commit messages:
 - Initial commit

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

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

From acobbs at openjdk.org  Wed Jan 17 21:31:22 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Jan 2024 21:31:22 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v2]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

  Quote '{' and '}' in subformat patterns, but only it not already quoted.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/688f5748..a9d78c76

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

  Stats: 344 lines in 4 files changed: 300 ins; 18 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

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

From acobbs at openjdk.org  Wed Jan 17 21:34:49 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 17 Jan 2024 21:34:49 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern
In-Reply-To: <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
Message-ID: <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>

On Tue, 16 Jan 2024 22:05:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,
> 
> (Jshell with your patch)
> 
> 
> var pattIn = "Test: {0,number,foo'{'#.00}";
> MessageFormat mFmt = new MessageFormat(pattIn);
> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";
> 
> 
> 
> var pattIn = "Test: {0,number,foo'}'#.00}";
> MessageFormat mFmt = new MessageFormat(pattIn);
> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";
> 
> 
> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 
> 
> Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.

Hi @justin-curtis-lu,

Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!

> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.

You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):


$ jshell
|  Welcome to JShell -- Version 17.0.9
|  For an introduction type: /help intro

jshell> import java.text.*;

jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
$2 ==> java.text.MessageFormat at 951c5b58

jshell> $2.toPattern()
$3 ==> "Test: {0,number,foo{#.00}"

jshell> new MessageFormat($3)
|  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
|        at MessageFormat.applyPattern (MessageFormat.java:521)
|        at MessageFormat.<init> (MessageFormat.java:371)
|        at (#4:1)


I've been missing the forest for the trees a bit and I think the fix can be simpler now.

For the record, here is my latest understanding of what's going on...

1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.

Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1896840300

From naoto at openjdk.org  Wed Jan 17 22:59:51 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 Jan 2024 22:59:51 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <lzDahkWuw2qH2LnWcPQK5yU5GDyLU6-S5Cqh6-gmQ2w=.fb2fb144-f9bb-4097-b375-7f2592132ab6@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828357538

From darcy at openjdk.org  Wed Jan 17 23:12:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 17 Jan 2024 23:12:49 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <FweRScYClF7i3NykFaDuBAgRcplKO6ENt4H3fuc3CcE=.9ccfeb5f-9a33-4863-8096-9927172df80c@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1828378857

From ihse at openjdk.org  Thu Jan 18 09:32:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 18 Jan 2024 09:32:15 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

Thanks! When this has been integrated, I can take a shot at the missorted `default`s.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829238473

From dfuchs at openjdk.org  Thu Jan 18 09:49:13 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Jan 2024 09:49:13 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <_1D6S_orn-H9wHL41PEskm8JN2PLJs_GvkxIg-Ht0Zs=.b3db368a-ee61-4951-b143-f49fb9e1f702@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

LGTM

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17468#pullrequestreview-1829273407

From prappo at openjdk.org  Thu Jan 18 10:04:14 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 18 Jan 2024 10:04:14 GMT
Subject: <i18n dev> RFR: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
 <sYBKbndDd3hJqkOldbE9Lwuv1kvfPx-pX-RjVtvQ6G4=.102dc24f-19c7-4241-a0b7-aaff20769422@github.com>
Message-ID: <VCIhSACSD78SXKxl1NOLDGeRiRNiuKEARWiTGbhpy_8=.3ed7434b-7469-4e15-92c8-792c98819cb5@github.com>

On Thu, 18 Jan 2024 09:29:11 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Thanks! When this has been integrated, I can take a shot at the missorted `default`s.

Thanks, I could've done that myself, but decided not to. You see, `default` should ideally be a [sole] modifier on a method: all other modifiers of a `default` method should be deleted. I'm not sure that reaching such an ideal would be welcomed.

Whatever you decide to do, be prepared to work manually. `bin/blessed-modifier-order.sh` is simple and robust but not specific. You'll have to carefully sift through other missortings it finds.

[sole]: https://mail.openjdk.org/pipermail/core-libs-dev/2024-January/117398.html

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

PR Comment: https://git.openjdk.org/jdk/pull/17468#issuecomment-1898162068

From naoto at openjdk.org  Thu Jan 18 19:43:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 19:43:27 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect
Message-ID: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>

Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

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

Commit messages:
 - initial commit

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

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

From jlu at openjdk.org  Thu Jan 18 20:11:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 20:11:10 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern
In-Reply-To: <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
 <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
Message-ID: <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>

On Wed, 17 Jan 2024 21:31:49 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Hi Archie, thanks for the proposed fix. I am still taking a look, but I wanted to demonstrate a current issue,
>> 
>> (Jshell with your patch)
>> 
>> 
>> var pattIn = "Test: {0,number,foo'{'#.00}";
>> MessageFormat mFmt = new MessageFormat(pattIn);
>> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo{#.00}";
>> 
>> 
>> 
>> var pattIn = "Test: {0,number,foo'}'#.00}";
>> MessageFormat mFmt = new MessageFormat(pattIn);
>> var pattOut  = mFmt.toPattern(); // returns "Test: {0,number,foo'}'#.00}";
>> 
>> 
>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted. 
>> 
>> Also in response to your earlier question on core-libs-dev, ideally invoking toPattern() can roundtrip, but there are known issues, such as a custom user defined Format subclass, or one of the newer Format subclasses that do not implement the toPattern() method. I am working on making this apparent in the specification of the method in a separate issue.
>
> Hi @justin-curtis-lu,
> 
> Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!
> 
>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.
> 
> You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):
> 
> 
> $ jshell
> |  Welcome to JShell -- Version 17.0.9
> |  For an introduction type: /help intro
> 
> jshell> import java.text.*;
> 
> jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
> $2 ==> java.text.MessageFormat at 951c5b58
> 
> jshell> $2.toPattern()
> $3 ==> "Test: {0,number,foo{#.00}"
> 
> jshell> new MessageFormat($3)
> |  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
> |        at MessageFormat.applyPattern (MessageFormat.java:521)
> |        at MessageFormat.<init> (MessageFormat.java:371)
> |        at (#4:1)
> 
> 
> I've been missing the forest for the trees a bit and I think the fix can be simpler now.
> 
> For the record, here is my latest understanding of what's going on...
> 
> 1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
> 1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
> 1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
> 1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.
> 
> Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.

Hi @archiecobbs , I think the recent commit is good progress.

First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.

> Therefore, the correct fix is for MessageFormat.toPattern() to modify the subformat strings by quoting any unquoted {or } characters while leaving any already-quoted characters alone.

Yes, I think this behavior allows for the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat. Although to clarify, the original String pattern will not be guaranteed to be equivalent to the one returned by `toPattern()` as we are adding quotes to all brackets in the subformatPattern, regardless if they were quoted in the original String. I think the former is more important here, so the latter is okay.

For DecimalFormat and SimpleDateFormat subformats, adding quotes to brackets found in the subformatPattern is always right, those subformats can not be used to create recursive format behavior. Thus you would **never** except a nested ArgumentIndex in the subformatPattern (ex: `"{0,number,{1}foo0.0"}`), and can confidently escape all brackets found for these subFormats (which you do).

To me, ChoiceFormat is where there is some concern. Consider the following,

`new MessageFormat("{0,choice,0# {1} {2} {3} }?)`

With this change, invoking `toPattern()` on the created MessageFormat would return 

`"{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }"`.

This would technically be incorrect. One would think instead of allowing 3 nested elements, we are now printing the literal `{1} {2} {3}` since the brackets are escaped. But, this is not actually the case. Escaping brackets with a choice subFormat does not function properly. This is due to the fact that a recursive messageFormat is created, but the pattern passed has already lost the quotes.

This means that `new MessageFormat("{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }")`.

is still equivalent to `new MessageFormat("{0,choice,0# {1} {2} {3} }?).`

So the behavior of quoting all brackets would still guarantee _the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat_ but only because the current behavior of formatting with a choice subFormat is technically wrong. I think this is okay, since this incorrect behavior is long-standing, but a CSR would be good to address this.

Please let me know if these points made sense, I?m happy to discuss further.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899133247

From iris at openjdk.org  Thu Jan 18 20:51:11 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 20:51:11 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>

On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

Hopefully "2100" is unique enough that you'll be able to easily search/replace the next time you need to extend.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830530349

From naoto at openjdk.org  Thu Jan 18 21:02:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 21:02:26 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

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

  Added comment to clarify the possible need for the last year expansion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17492/files
  - new: https://git.openjdk.org/jdk/pull/17492/files/1779673d..9ce8f35b

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

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

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

From naoto at openjdk.org  Thu Jan 18 21:02:26 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 Jan 2024 21:02:26 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <YmFXEEi8SSunIMk1c-APzMNIrBJUInxl6iTOQ6-xjMw=.2cbbf55a-7fa3-4ab3-a077-dc6f60cdf2d6@github.com>
Message-ID: <Iibn9Ex67B-dxjZaEehxcLvqYcvfGsvC28WrjUiUjzQ=.9a1cfedc-b4af-481c-8976-79239eca7d9c@github.com>

On Thu, 18 Jan 2024 20:48:03 GMT, Iris Clark <iris at openjdk.org> wrote:

> Hopefully "2100" is unique enough that you'll be able to easily search/replace the next time you need to extend.

Thank you, Iris. Added a comment to clarify the need for possible expansion.

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

PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899195604

From acobbs at openjdk.org  Thu Jan 18 21:11:11 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 18 Jan 2024 21:11:11 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern
In-Reply-To: <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <_Zzu7E5pe-axhJz9LsmmCKTbPUv3ku2cAYthVanICCM=.4dadac29-dbfb-44c8-9f9e-642937fa9767@github.com>
 <4h8rbe30hshRNi6uQpqGscImjRBLN22QtfdXflFtqNM=.1b69f75b-8682-4c64-9efa-c3682ace0a2d@github.com>
 <3hKX_Ehs3wm7zMvfwukLB_MgY9rHey6row0X9bH1ICs=.a9cb4596-7a72-4de1-ac26-7c7d9ce51479@github.com>
Message-ID: <97WpuyYiAg3WZVK5Z7tg1OWW3vD6H8B9Oa_roP2ndeo=.55431e6f-16ad-4d28-aa93-c0a779d23ce7@github.com>

On Thu, 18 Jan 2024 20:08:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Hi @justin-curtis-lu,
>> 
>> Thanks a lot for taking a look, I am glad for any other set of eyes on this tricky stuff!
>> 
>>> As it stands, it would be inconsistent to have the closing bracket quoted and the opening bracket not quoted.
>> 
>> You're right - the problem exists with both `{` and `}`, as is shown here (unmodified jshell):
>> 
>> 
>> $ jshell
>> |  Welcome to JShell -- Version 17.0.9
>> |  For an introduction type: /help intro
>> 
>> jshell> import java.text.*;
>> 
>> jshell> new MessageFormat("Test: {0,number,foo'{'#.00}");
>> $2 ==> java.text.MessageFormat at 951c5b58
>> 
>> jshell> $2.toPattern()
>> $3 ==> "Test: {0,number,foo{#.00}"
>> 
>> jshell> new MessageFormat($3)
>> |  Exception java.lang.IllegalArgumentException: Unmatched braces in the pattern.
>> |        at MessageFormat.applyPattern (MessageFormat.java:521)
>> |        at MessageFormat.<init> (MessageFormat.java:371)
>> |        at (#4:1)
>> 
>> 
>> I've been missing the forest for the trees a bit and I think the fix can be simpler now.
>> 
>> For the record, here is my latest understanding of what's going on...
>> 
>> 1. When `MessageFormat.toPattern()` constructs the combined pattern string, it concatenates the plain text bits, suitably escaped, and the pattern strings from each subformat.
>> 1. The subformat strings are already escaped, in the sense that you can take (for example) a `ChoiceFormat` format string and use it as-is to recreate that same `ChoiceFormat`, but they are escaped _only for their own purposes_.
>> 1. The original example is an example of where this matters - `ChoiceFormat` needs to escape `#`, `|`, etc., but doesn't need to escape `{` or `}` - but a `MessageFormat` format string does need to escape those.
>> 1. Therefore, the correct fix is for `MessageFormat.toPattern()` to modify the subformat strings by quoting any _unquoted_ `{` or `}` characters while leaving any already-quoted characters alone.
>> 
>> Updated in a9d78c76f5f. I've also updated the test so it does more thorough round-trip checks.
>
> Hi @archiecobbs , I think the recent commit is good progress.
> 
> First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.
> 
>> Therefore, the correct fix is for MessageFormat.toPattern() to modify the subformat strings by quoting any unquoted {or } characters while leaving any already-quoted characters alone.
> 
> Yes, I think this behavior allows for the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat. Although to clarify, the original String pattern will not be guaranteed to be equivalent to the one returned by `toPattern()` as we are adding quotes to all brackets in the subformatPattern, regardless if they were quoted in the original String. I think the former is more important here, so the latter is okay.
> 
> For DecimalFormat and SimpleDateFormat subformats, adding quotes to brackets found in the subformatPattern is always right, those subformats can not be used to create recursive format behavior. Thus you would **never** except a nested ArgumentIndex in the subformatPattern (ex: `"{0,number,{1}foo0.0"}`), and can confidently escape all brackets found for these subFormats (which you do).
> 
> To me, ChoiceFormat is where there is some concern. Consider the following,
> 
> `new MessageFormat("{0,choice,0# {1} {2} {3} }?)`
> 
> With this change, invoking `toPattern()` on the created MessageFormat would return 
> 
> `"{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }"`.
> 
> This would technically be incorrect. One would think instead of allowing 3 nested elements, we are now printing the literal `{1} {2} {3}` since the brackets are escaped. But, this is not actually the case. Escaping brackets with a choice subFormat does not function properly. This is due to the fact that a recursive messageFormat is created, but the pattern passed has already lost the quotes.
> 
> This means that `new MessageFormat("{0,choice,0.0# '{'1'}' '{'2'}' '{'3'}' }")`.
> 
> is still equivalent to `new MessageFormat("{0,choice,0# {1} {2} {3} }?).`
> 
> So the behavior of quoting all brackets would still guarantee _the String returned by `toPattern()` to create a MessageFormat that can format equivalently to the original MessageFormat_ but only because the current behavior of formatting with a choice subFormat is technically wrong. I think this is okay, since this incorrect behavior is long-standing, but a CSR would be good to ad...

Hi @justin-curtis-lu,

Thanks for your comments.

> First off I think this change will need a CSR as there are behavioral concerns, although minimal. Please let me know if you have access on JBS to file one, otherwise I can file one for you.

No problem, I'll add one.

> To me, ChoiceFormat is where there is some concern. Consider the following,

OK I think I understand what you're saying.

The first goal here is to ensure the round trip operation `MessageFormat` ? Pattern string from `toPattern()` ? `MessageFormat` takes you back to where you started.

The patch achieves this so we're good so far. I think we agree on this.

> This would technically be incorrect.

I'm not quite understanding what you meant there (and therefore slightly worried)...

In my mind, a key observation here is that the following two things are not equal and therefore shouldn't be conflated:
* A `ChoiceFormat` pattern string (e.g., what you get from invoking `ChoiceFormat.toPattern()`)
* The `XXX` that you see inside a `MessageFormat` pattern string as part of a `{0,choice,XXX}` subformat.

Those are not the same, even modulo quoting. As you point out, `MessageFormat` has this quirky logic ([here](https://github.com/openjdk/jdk/blob/81df265e41d393cdde87729e091dd465934071fd/src/java.base/share/classes/java/text/MessageFormat.java#L1327-L1333)) in which, after it evaluates a `ChoiceFormat` subformat, if the returned string contains a `{` character, then that string is magically reinterpreted as a `MessageFormat` pattern string and evaluated again, otherwise it's left alone.

So the `XXX` is not a "`ChoiceFormat` pattern string" but something else, so it can't be "incorrect" for not looking like a normal `ChoiceFormat` pattern string.

Maybe it's just a manner of speaking? In any case I want to be careful I'm not missing something in what you're saying.

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899206551

From iris at openjdk.org  Thu Jan 18 22:11:56 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Jan 2024 22:11:56 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <NG1GvIzUF-IZ-c1vQaN1jIZlihtRlPeAcsoHDMtmj08=.9a55e589-d5f1-4bef-9e2d-f49f340cd5cc@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

Still looks good!

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830637536

From joehw at openjdk.org  Thu Jan 18 22:19:29 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 18 Jan 2024 22:19:29 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <S740Smj_icz7OKNnczQZiBDFbYhuo253Wsmv_oUwsuc=.138f2755-4b28-4ea4-baa4-f04f5aad9cab@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

You've saved generations of engineers from having to look at it again. By then, the dev AI will look at it and ...

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830645855

From prappo at openjdk.org  Thu Jan 18 22:31:38 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 18 Jan 2024 22:31:38 GMT
Subject: <i18n dev> Integrated: 8324053: Use the blessed modifier order for
 sealed in java.base
In-Reply-To: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
References: <g10TIuWM1TzXyFlJt-HFL117L2gjnmLagsR-NJyzk7M=.db3d8faf-3051-4613-9d2b-ee397bbe346d@github.com>
Message-ID: <TVu7K-1CyqlKX5fiNl8LXzQPAPkzbEtmioWPJh_LMSc=.23a8fe26-baf6-4575-89cc-92371f855656@github.com>

On Wed, 17 Jan 2024 21:22:07 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this trivial PR to reorder the `sealed` class or interface modifier. For context of this change see: https://github.com/openjdk/jdk/pull/17242#issuecomment-1887338396.

This pull request has now been integrated.

Changeset: 9efdd242
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9efdd242fb40a8270e489cc071ff1c891878e24f
Stats:     8 lines in 7 files changed: 0 ins; 0 del; 8 mod

8324053: Use the blessed modifier order for sealed in java.base

Reviewed-by: naoto, darcy, ihse, dfuchs

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

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

From jlu at openjdk.org  Thu Jan 18 23:05:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 23:05:26 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v2]
In-Reply-To: <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
Message-ID: <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>

On Wed, 17 Jan 2024 21:31:22 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Quote '{' and '}' in subformat patterns, but only it not already quoted.

Hi Archie,

> The XXX that you see inside a MessageFormat pattern string as part of a {0,choice,XXX} subformat.

I think we both agree that XXX may not be the same as the Subformat pattern string.

Sorry if I'm going over stuff you already know, but to clarify my previous statement, MessageFormat escapes brackets so that they are syntactically not evaluated and simply injected into the pattern as a literal bracket. Why I brought up ChoiceFormat, is that it is unique in the sense that you can insert a `{ FormatElement }` into a subFormat pattern, which causes recursion.

Take the example from the class specification, 

`new MessageFormat(There {0,choice,0#are no files|1#is one file|1<are {0,number,integer} files}.?);`

Formatting the value `5`, MessageFormat will first evaluate it as `are {0,number,integer} files}` and then recursively create another MessageFormat to evaluate it as `5 files`.

This is because `1<are {0,number,integer} files.` has unquoted brackets, signaling that MessageFormat should interpret them as syntactically significant. Had they been quoted such as, `1<are '{'0,number,integer'}' files.}`, **I** would expect that MessageFormat will first evaluate it as `are ?{'0,number,integer?}' files.`, and as the brackets are quoted, interpret them as syntactically meaningless and simply return the value `are {0,number,integer} files.` with no recursive MessageFormat created.


So bringing it back to my example in the previous comment, if we had `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` I we would expect it to format `5 6 7 8` as `foo 6 7 8`. 

But if we had `new MessageFormat("{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }")` which implies the brackets are syntactically meaningless, I would expect the class to treat them not as nested `FormatElement`s and expect the returned value `foo {0} {1} {2}`

But this is not the case, since by the time the recursive MessageFormat is created the quotes are lost, so it has no means of knowing to treat them as syntactically insignificant, and thus parses the quote and treats them as injected `FormatElement`s which is why in reality the most recent example returns the value `foo 6 7 8`.

So with this change, although calling `toPattern()` on `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the String `"{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }"` which **I** would think, formats differently, **in reality**, they format equivalently, so I think it is okay. I brought it up not necessarily as an issue, but just something to make apparent. Although I suppose something like this is up for interpretation, so perhaps its only wrong to me.

I'm taking a look at the CSR you filed, but you may also want someone with Reviewer status to take a look as well.
I'll also test your changes against our internal tests. Hope this helped.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899355910

From jlu at openjdk.org  Thu Jan 18 23:22:36 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 18 Jan 2024 23:22:36 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
Message-ID: <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>

On Thu, 18 Jan 2024 21:02:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added comment to clarify the possible need for the last year expansion

LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/17492#pullrequestreview-1830712470

From acobbs at openjdk.org  Thu Jan 18 23:37:24 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 18 Jan 2024 23:37:24 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v2]
In-Reply-To: <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <C22xMNU_OfA3DTtE6idD8i1XajRbvDhurBlQ3hf0gm0=.ee49afd5-1965-4948-96fd-e1212d46c3b5@github.com>
 <koZD0AtJ06MmrIywQtjzPzSqLh6zgFUbAmWPdJiiSI4=.54ba03cc-1b53-4a50-a8b2-69ef7d01ddcd@github.com>
Message-ID: <6WkTom9bwIDQZ4456ADDqFWiA8uNNNMBPyg84smj06U=.e7307a5b-7326-4b93-9bbc-f460ebb2a213@github.com>

On Thu, 18 Jan 2024 23:02:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Sorry if I'm going over stuff you already know...

No apology needed, this stuff is obscure detail madness!

> So with this change, although calling `toPattern()` on `new MessageFormat("{0,choice,0.0#foo {1} {2} {3} }")` would return the String `"{0,choice,0.0#foo '{'1'}' '{'2'}' '{'3'}' }"` which **I** would think, formats differently, **in reality**, they format equivalently, so I think it is okay. I brought it up not necessarily as an issue, but just something to make apparent. Although I suppose something like this is up for interpretation, so perhaps its only wrong to me.

OK gotcha. I totally agree that what you think it should do makes a lot more sense that what it actually does!

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1899385354

From naoto at openjdk.org  Fri Jan 19 00:07:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jan 2024 00:07:20 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v3]
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <rkvWP6yDRQbKNmnCUfzJn5s-czYmfdidavbu88W5oT8=.8fa6c231-8f57-4767-a94f-85bd018a79e0@github.com>

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

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

  copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17492/files
  - new: https://git.openjdk.org/jdk/pull/17492/files/9ce8f35b..cb652b81

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

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

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

From naoto at openjdk.org  Fri Jan 19 00:07:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Jan 2024 00:07:22 GMT
Subject: <i18n dev> RFR: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect [v2]
In-Reply-To: <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
 <x0Qe1WN_rGUtDX004AV4KbO8mbo0ZdxbIsX3ndX7fOo=.133a899e-f55c-4746-90da-892da9276a32@github.com>
 <2DCaL0E-6tyxiBQBcMQycu73kyFkxghhyDy4nr7g36w=.bcecf044-1965-4602-9198-fa1228e57c38@github.com>
Message-ID: <4J8OkfpJ8D3uJb4GHWF1GM0pIru1Kv7douvXUbupiZY=.778f60d0-5186-4079-979e-e4425a7cdf5c@github.com>

On Thu, 18 Jan 2024 23:19:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> LGTM, _NegativeDSTTest.java_ can bump the copyright year to 2024 as well.

Forgot that! Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17492#issuecomment-1899410249

From acobbs at openjdk.org  Fri Jan 19 23:30:43 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 19 Jan 2024 23:30:43 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

  Add @implNote to Javadoc for toPattern().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/a9d78c76..36d70b8a

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

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

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

From acobbs at openjdk.org  Fri Jan 19 23:34:26 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 19 Jan 2024 23:34:26 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
Message-ID: <USbKLrolMVtWWn7HBuV5iplty0ElR9HOExazD_elq0s=.d50ee2bb-2a07-487d-86d9-661a182cd73c@github.com>

On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implNote to Javadoc for toPattern().

Adding an additional note of explanation here just for the record (this is copied from the CSR):

> We need to ask how do we know it is safe to quote the unquoted curly brace characters in the subformat patterns? If curly braces are not special to the subformat, then quoting them clearly does no harm. So we only need worry about subformat patterns where curly braces are special. But the only subformat pattern strings supported by `MessageFormat` are for `DecimalFormat`, `SimpleDateFormat`, and `ChoiceFormat`, and curly braces are not special for any of these classes, so we're good.
> 
> However, it should be noted that there is some confusing special logic that clouds this question. If the string that results from evaluating a `ChoiceFormat` subformat of a `MessageFormat` contains an opening curly brace, then a new `MessageFormat` is created from that string and evaluated, and _that_ string replaces the original. This behavior doesn't impact how subformats should be quoted, only how their results are interpreted at "run time".

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1901291484

From naoto at openjdk.org  Mon Jan 22 17:18:37 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Jan 2024 17:18:37 GMT
Subject: <i18n dev> Integrated: 8324065: Daylight saving information for
 `Africa/Casablanca` are incorrect
In-Reply-To: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
References: <Or0W7o9jlrxrwqcxeaqn6gScq5nFHt629b3gtu_vllM=.e7364480-84da-407e-8072-2ce3283f0caa@github.com>
Message-ID: <-2FQ8jqCpBpPyZVJxM2TSC2Ka4TTkMBI97jclhIJKUU=.97c56d74-c15f-4a71-8214-ed0a1dc4a011@github.com>

On Thu, 18 Jan 2024 19:37:33 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect std/dst transitions for time zones that have rules beyond 2037. The year 2037 restriction seems to come from the old `zic` command implementation and thus can be expanded in the JDK. Arbitrary I chose 2100 which is greater than the year 2087 which is the farthest rule at the moment.

This pull request has now been integrated.

Changeset: 0d8543d6
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d8543d6773a516dad54038070dce507179d0709
Stats:     44 lines in 6 files changed: 5 ins; 7 del; 32 mod

8324065: Daylight saving information for `Africa/Casablanca` are incorrect

Reviewed-by: iris, joehw, jlu

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

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

From jlu at openjdk.org  Mon Jan 22 22:54:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 Jan 2024 22:54:26 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v4]
In-Reply-To: <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <PDjwsd7fL12h-PxAuV9hQHWPtn6dCqOoROiCE8kCu3A=.8269d920-abbb-4ab6-a9a5-5a805f879a60@github.com>
 <ROYcHd4rqA0XB__-nHTZJ2YXNwxybW1fcREDnT7L4C4=.4d810fff-6c92-4045-8f0d-a6ba73db040c@github.com>
Message-ID: <8mM5JCWtyyOsfOo23GuHUPi9a0rI8RQRCA2usw92vkY=.62fc94ad-d52a-4f9a-bb0d-abe35ae82748@github.com>

On Fri, 12 Jan 2024 21:30:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Justin Lu 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 eight additional commits since the last revision:
>> 
>>  - replace 'None' with 'null' for applicable classes
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - swap placement of decimal pattern and compact patterns. Expand on tests
>>  - add unit tests
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - account for null locale for SDF through deserialization
>>  - Merge branch 'master' into JDK-8321545-toString-j.text.Format
>>  - init
>
> src/java.base/share/classes/java/text/MessageFormat.java line 1195:
> 
>> 1193:             """
>> 1194:             MessageFormat [locale: "%s", pattern: "%s"]
>> 1195:             """.formatted(locale == null ? "null" : locale.getDisplayName(), toPattern());
> 
> It would be more accurate if when locale ==null that null was not quoted in the string.
> Seeing "null" would imply that the displayName of the locale was "null", when it was `null`.

Hi Roger, addressed in https://github.com/openjdk/jdk/pull/17355/commits/70e0a175037ccd0215d76fb2fbfa8c91de291d41; would like to confirm the update is okay with you before integration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1462516181

From rriggs at openjdk.org  Tue Jan 23 15:18:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 23 Jan 2024 15:18:33 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v5]
In-Reply-To: <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
 <RitaZ1Ej-sjgHl4bgPsJLJ5hD-z3ljeWQ0n8vFrquQQ=.2f860079-c0d4-41eb-894a-a78f6f687134@github.com>
Message-ID: <1rmvLpL-NxFuwHXsLqLghFXDNnouQ11MQ4qN1Icb2F8=.0c156875-aadf-46a2-9da2-652bfe6a646f@github.com>

On Fri, 12 Jan 2024 22:41:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
>> 
>> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
>> 
>> An example of all the classes has output such as 
>> 
>> 
>> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
>> 
>> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
>> 
>> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
>> 
>> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
>> 
>> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
>> 
>> ChoiceFormat [pattern: "0#foo"]
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove quotes around locale when equal to null

Marked as reviewed by rriggs (Reviewer).

src/java.base/share/classes/java/text/MessageFormat.java line 1195:

> 1193:             """
> 1194:             MessageFormat [locale: %s, pattern: "%s"]
> 1195:             """.formatted(locale == null ? null : '"'+locale.getDisplayName()+'"', toPattern());

Style wise, operators (like "+") should have spaces around them.

src/java.base/share/classes/java/text/SimpleDateFormat.java line 2433:

> 2431:             """
> 2432:             SimpleDateFormat [locale: %s, pattern: "%s"]
> 2433:             """.formatted(locale == null ? null : '"'+locale.getDisplayName()+'"', toPattern());

Ditto, add spaces around +.

test/jdk/java/text/Format/DateFormat/ToStringTest.java line 59:

> 57:     public void oddValueTest() {
> 58:         String expectedStr =
> 59:                 "SimpleDateFormat [locale: \""+Locale.getDefault().getDisplayName()+"\", pattern: \"MMM d, y\"]\n";

Add spaces around operator +

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

PR Review: https://git.openjdk.org/jdk/pull/17355#pullrequestreview-1839039270
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463432450
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463433138
PR Review Comment: https://git.openjdk.org/jdk/pull/17355#discussion_r1463434281

From jlu at openjdk.org  Tue Jan 23 18:46:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 18:46:37 GMT
Subject: <i18n dev> RFR: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
Message-ID: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>

Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.

When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.

Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.

Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Tue Jan 23 19:22:44 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 19:22:44 GMT
Subject: <i18n dev> RFR: JDK-8321545: Override toString() for Format
 subclasses [v6]
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <XXGFRioj4vvnPv38tYJQ3sqr0k3jPRDID0hp9-dYQg0=.0bb3c660-afc9-4545-b030-f779e35d27bf@github.com>

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

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

 - reflect Rogers comments: style changes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - remove quotes around locale when equal to null
 - replace 'None' with 'null' for applicable classes
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - swap placement of decimal pattern and compact patterns. Expand on tests
 - add unit tests
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - account for null locale for SDF through deserialization
 - Merge branch 'master' into JDK-8321545-toString-j.text.Format
 - ... and 1 more: https://git.openjdk.org/jdk/compare/9baaa352...d65cbcd1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17355/files
  - new: https://git.openjdk.org/jdk/pull/17355/files/70e0a175..d65cbcd1

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

  Stats: 14587 lines in 430 files changed: 7332 ins; 5481 del; 1774 mod
  Patch: https://git.openjdk.org/jdk/pull/17355.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17355/head:pull/17355

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

From naoto at openjdk.org  Tue Jan 23 22:16:27 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jan 2024 22:16:27 GMT
Subject: <i18n dev> RFR: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <LU_67A7Ms9cjZfPTRSVLnlbvCJC1JOFfhH1kbzcBdRM=.f5a4854e-d754-436f-97c4-7e7fa632c292@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17541#pullrequestreview-1840039217

From jlu at openjdk.org  Tue Jan 23 22:23:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 22:23:34 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
Message-ID: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>

On Fri, 19 Jan 2024 23:30:43 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add @implNote to Javadoc for toPattern().

Hi @archiecobbs, left some initial comments.

But I think the logic is sound so far. Quote all quotable characters that need to be quoted, at the MessageFormat level this is simply opening and closing bracket, which you accomplished with the 2 pass copyAndQuoteBraces method. The goal is to create a resultant String that can create a MessageFormat that formats equivalently as the original, (even if calling toPattern() on both MessageFormats returns different String values).

Let's also try and get the CSR approved first.

src/java.base/share/classes/java/text/MessageFormat.java line 1:

> 1: /*

For this file, please also bump the latter copyright year to 2024.

src/java.base/share/classes/java/text/MessageFormat.java line 556:

> 554:      * does not necessarily equal the previously applied pattern.
> 555:      *
> 556:      * @implNote The string returned by this method can be used to create

Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?

src/java.base/share/classes/java/text/MessageFormat.java line 585:

> 583:                     if (fmt instanceof DecimalFormat) {
> 584:                         result.append(",number");
> 585:                         subformatPattern = ((DecimalFormat)fmt).toPattern();

Could use pattern matching `instanceof` here and in the other instances, but I understand if you're trying to stay consistent with the existing code.

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 56:

> 54: 
> 55:     private static final int NUM_RANDOM_TEST_CASES = 1000;
> 56:     private static final int MAX_FORMAT_NESTING = 3;

Can you add a comment defining `MAX_FORMAT_TESTING`, might not be immediately understood without further investigation

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 90:

> 88:         // A few more test cases from the PR#17416 discussion
> 89:         testRoundTrip(new MessageFormat("Test: {0,number,foo'{'#.00}"));
> 90:         testRoundTrip(new MessageFormat("Test: {0,number,foo'}'#.00}"));

Can we add some more concrete test cases, for example, escaped quotes within a MessageFormat pattern (represented by doubled single quotes). 

Another funny case is something like a MessageFormat created by `"{0,number,' abc }'' ' 0.00}"` which becomes `"{0,number, abc '}'''  #0.00}"` after created from the value returned by toPattern() from the first MessageFormat. The Strings appear really different but format equivalently, it would be nice to have suspicious cases like these explicitly defined.

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:

> 94:     @ParameterizedTest
> 95:     @MethodSource("testCases")
> 96:     public void testRoundTrip(MessageFormat format1) {

Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.

Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_

test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 154:

> 152:     // Generate a "random" MessageFormat. We do this by creating a MessageFormat with "{0}" placeholders
> 153:     // and then substituting in random DecimalFormat, DateFormat, and ChoiceFormat subformats. The goal here
> 154:     // is to avoid using pattern strings to construct formats, because they're what we're trying to check.

Can you add a general example of a randomly generated MessageFormat in the comments, (I know they vary by quite a lot), but it would be hard for someone to piece if together without digging into the code. And unfortunately the current toString() of MessageFormat is not implemented, so although JUnit prints the MessageFormat out, it's just gibberish.

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

PR Review: https://git.openjdk.org/jdk/pull/17416#pullrequestreview-1840037706
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059010
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059073
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464059360
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464060206
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464061279
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464062599
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464063513

From jlu at openjdk.org  Tue Jan 23 22:25:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 Jan 2024 22:25:41 GMT
Subject: <i18n dev> Integrated: JDK-8321545: Override toString() for Format
 subclasses
In-Reply-To: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
References: <rbM4e_wOcBiC2gG2rWkwxK02Sr04MbDcNT3r0ujPBAE=.f0b5f46d-b08c-4668-adfe-bcd0d73ddb68@github.com>
Message-ID: <XcTpILSMk7F7luBsSBtJNBf1OWoCAPGf1zS-JgNwnEk=.9ba6e149-6f77-4823-9237-88ddbc191169@github.com>

On Wed, 10 Jan 2024 21:05:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements toString() for the `Format` subclasses. Corresponding CSR: [JDK-8323088](https://bugs.openjdk.org/browse/JDK-8323088)
> 
> The general specification follows a template that provides the locale (if the class is localized) and any relevant patterns. The specification was intentionally kept minimal and deliberately worded as "for debugging".
> 
> An example of all the classes has output such as 
> 
> 
> CompactNumberFormat [locale: "English (United States)", decimal pattern: "foo#0.00#baz", compact patterns: "[, , , {one:0K other:0K}, {one:00K other:00K}, {one:000K other:000K}, {one:0M other:0M}, {one:00M other:00M}, {one:000M other:000M}, {one:0B other:0B}, {one:00B other:00B}, {one:000B other:000B}, {one:0T other:0T}, {one:00T other:00T}, {one:000T other:000T}]"]
> 
> DecimalFormat [locale: "English (United States)", pattern: "foo#0.00#baz"]
> 
> SimpleDateFormat [locale: "Chinese (China)", pattern: "EEE, MMM d, ''yy"]
> 
> ListFormat [locale: "English (United States)", start: "{0}, {1}", middle: "{0}, {1}", end: "{0}, and {1}", two: "{0} and {1}", three: "{0}, {1}, and {2}"]
> 
> MessageFormat [locale: "Chinese (China)", pattern: "foo {0}"]
> 
> ChoiceFormat [pattern: "0#foo"]

This pull request has now been integrated.

Changeset: 96607df7
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/96607df7f055a80d56ea4c19f3f4fcb32838b1f8
Stats:     419 lines in 12 files changed: 412 ins; 0 del; 7 mod

8321545: Override toString() for Format subclasses

Reviewed-by: naoto, rriggs

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

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

From iris at openjdk.org  Tue Jan 23 22:27:26 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Jan 2024 22:27:26 GMT
Subject: <i18n dev> RFR: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <3znCjA6Ng6Fi7KqCFMw0PITckIqZLJEm9r_7Y95GGIM=.48b96ae7-4ff9-4a68-ba83-795a75d67b3e@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17541#pullrequestreview-1840051983

From naoto at openjdk.org  Tue Jan 23 23:03:28 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Jan 2024 23:03:28 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>

On Tue, 23 Jan 2024 22:13:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> src/java.base/share/classes/java/text/MessageFormat.java line 556:
> 
>> 554:      * does not necessarily equal the previously applied pattern.
>> 555:      *
>> 556:      * @implNote The string returned by this method can be used to create
> 
> Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?

Yes, my comment to the CSR was to explain the default implementation as the `@implNote`. Making it explicit would be helpful to readers.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464096885

From acobbs at openjdk.org  Tue Jan 23 23:15:30 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Jan 2024 23:15:30 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>

On Tue, 23 Jan 2024 22:13:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> src/java.base/share/classes/java/text/MessageFormat.java line 1:
> 
>> 1: /*
> 
> For this file, please also bump the latter copyright year to 2024.

Will do.

> src/java.base/share/classes/java/text/MessageFormat.java line 585:
> 
>> 583:                     if (fmt instanceof DecimalFormat) {
>> 584:                         result.append(",number");
>> 585:                         subformatPattern = ((DecimalFormat)fmt).toPattern();
> 
> Could use pattern matching `instanceof` here and in the other instances, but I understand if you're trying to stay consistent with the existing code.

Agreed! Old habits :) I'll fix.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 56:
> 
>> 54: 
>> 55:     private static final int NUM_RANDOM_TEST_CASES = 1000;
>> 56:     private static final int MAX_FORMAT_NESTING = 3;
> 
> Can you add a comment defining `MAX_FORMAT_TESTING`, might not be immediately understood without further investigation

Will do.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:
> 
>> 94:     @ParameterizedTest
>> 95:     @MethodSource("testCases")
>> 96:     public void testRoundTrip(MessageFormat format1) {
> 
> Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.
> 
> Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_

I would have done that but it's not (easily) possible. The `MessageFormat`'s are created not from format strings, but by piecing together plain text and sub-`Format` objects manually. This was we are sure what we're dealing with.

Trying to create format strings with multiple levels of nesting from scratch is too complex for my brain due to all the levels of quoting required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104293
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104138
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104181
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104467

From acobbs at openjdk.org  Tue Jan 23 23:15:32 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 23 Jan 2024 23:15:32 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
 <SLbD3ysQl7WD43ouzjqKykKOCZLmSmH7ImiLau9aiaU=.c7570102-0fdc-421e-b0e1-a84005227324@github.com>
Message-ID: <2hZYIS2JiaimjmDS67wy3gje_rJxrFJi2SLveD2gUEc=.19b86355-b826-45e9-a692-73d257bcf5f1@github.com>

On Tue, 23 Jan 2024 23:00:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 556:
>> 
>>> 554:      * does not necessarily equal the previously applied pattern.
>>> 555:      *
>>> 556:      * @implNote The string returned by this method can be used to create
>> 
>> Hmm, I'm not sure about the current note, because its not true in all cases (for example, some unknown subclass of Format). Maybe @naotoj has thoughts?
>
> Yes, my comment to the CSR was to explain the default implementation as the `@implNote`. Making it explicit would be helpful to readers.

Yes my mistake, I'll change this to:

@implNote The implementation in {@link MessageFormat} returns a string
that can be used to create a new instance that is semantically equivalent
to this instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464104922

From jlu at openjdk.org  Wed Jan 24 00:00:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jan 2024 00:00:26 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
 <dY2OBW7ByRFcu91dvboCpA9-TiJcz_cQBeC-uPy84gM=.b408488f-c8eb-4a5d-bedf-b61c118fc571@github.com>
Message-ID: <ypl0q6bP1Z08buLxmYMRIMuDW6BVvfUunHI7N2zKVTA=.69e341e7-62ef-4055-8c73-ca92683c9460@github.com>

On Tue, 23 Jan 2024 23:12:19 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 96:
>> 
>>> 94:     @ParameterizedTest
>>> 95:     @MethodSource("testCases")
>>> 96:     public void testRoundTrip(MessageFormat format1) {
>> 
>> Can we also include the original String pattern that created format1, to help with debugging. I find myself wondering what the original String was.
>> 
>> Since technically, the full round trip is _pattern string -> MessageFormat1 -> pattern string -> MessageFormat2_
>
> I would have done that but it's not (easily) possible. The `MessageFormat`'s are created not from format strings, but by piecing together plain text and sub-`Format` objects manually. This was we are sure what we're dealing with.
> 
> Trying to create format strings with multiple levels of nesting from scratch is too complex for my brain due to all the levels of quoting required.

Right, should have noted that, definitely not worth to try and re-synthesize the original String pattern for each Format. If we're adding some additional concrete cases, its fine since those will clearly have the original String patterns there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464131694

From acobbs at openjdk.org  Wed Jan 24 00:21:44 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Jan 2024 00:21:44 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v4]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <qBTQyJF90w92AkWITW_HvJIVMBM8yRATdzTFtn9c_EQ=.6950da60-3e86-4e1f-b2d5-f7bf653e482e@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

 - Add more test cases and more pattern string variety.
 - Make it easier to debug & show what the test is doing.
 - Add comment explaining what MAX_FORMAT_NESTING is for.
 - Clean up code a bit by using instanceof patterns.
 - Tweak @implNote to clarify only referring to MessageFormat class.
 - Update copyright year in MessageFormat.java.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/36d70b8a..58e8cc68

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

  Stats: 94 lines in 2 files changed: 50 ins; 12 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/17416.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17416/head:pull/17416

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

From acobbs at openjdk.org  Wed Jan 24 00:21:46 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 24 Jan 2024 00:21:46 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v3]
In-Reply-To: <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <DVGrDlYQG6PApGHAzjP-XYRPCNff8n4wahRg46sz32o=.dce5994b-3216-44de-87a6-88740403d07f@github.com>
 <ap4lSNUIjQeqa6ftK75NMGRebH1NdAHCRy0e7hN1Ucg=.8fb857d1-f12d-4418-b55e-c767919868f5@github.com>
Message-ID: <5UccW0t33EHHwoxE3yDfK7ytOHD7KmRWKFFOsvYZ9Zo=.d7bdf3a2-e392-49e2-beb6-8f1ddd897689@github.com>

On Tue, 23 Jan 2024 22:15:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add @implNote to Javadoc for toPattern().
>
> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 90:
> 
>> 88:         // A few more test cases from the PR#17416 discussion
>> 89:         testRoundTrip(new MessageFormat("Test: {0,number,foo'{'#.00}"));
>> 90:         testRoundTrip(new MessageFormat("Test: {0,number,foo'}'#.00}"));
> 
> Can we add some more concrete test cases, for example, escaped quotes within a MessageFormat pattern (represented by doubled single quotes). 
> 
> Another funny case is something like a MessageFormat created by `"{0,number,' abc }'' ' 0.00}"` which becomes `"{0,number, abc '}'''  #0.00}"` after created from the value returned by toPattern() from the first MessageFormat. The Strings appear really different but format equivalently, it would be nice to have suspicious cases like these explicitly defined.

Sure thing - added in 58e8cc68f45.

> test/jdk/java/text/Format/MessageFormat/MessageFormatToPatternTest.java line 154:
> 
>> 152:     // Generate a "random" MessageFormat. We do this by creating a MessageFormat with "{0}" placeholders
>> 153:     // and then substituting in random DecimalFormat, DateFormat, and ChoiceFormat subformats. The goal here
>> 154:     // is to avoid using pattern strings to construct formats, because they're what we're trying to check.
> 
> Can you add a general example of a randomly generated MessageFormat in the comments, (I know they vary by quite a lot), but it would be hard for someone to piece if together without digging into the code. And unfortunately the current toString() of MessageFormat is not implemented, so although JUnit prints the MessageFormat out, it's just gibberish.

Added in 58e8cc68f45 as a test case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464143414
PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1464143622

From jlu at openjdk.org  Wed Jan 24 23:45:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 Jan 2024 23:45:33 GMT
Subject: <i18n dev> Integrated: JDK-6503196: API doc for
 DecimalFormat::getMaximumIntegerDigits is unclear
In-Reply-To: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
References: <HpFqdUXZbf4g3bH2joD7dbvCPLhTF_XeQHlOUx66P4A=.3bc34d85-23ff-4410-a46e-f20a160f1f0c@github.com>
Message-ID: <FEWpbcy_nsG1NtUH_W_stTWxL_SVstXZcTRBqrfyRBk=.387e145d-e8f0-4e84-b76b-557e9d2ea9d8@github.com>

On Tue, 23 Jan 2024 18:40:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some confusion for the digit getter and setter methods of DecimalFormat.
> 
> When formatting non `BigInteger` and `BigDecimal` values, DecimalFormat uses 309/340 as hard limits for integer and fraction digit limits, regardless of the value set by the user. There was some confusion, that those numbers might be returned by the getters, when in reality, they are only used internally.
> 
> Moving the 309/340 wording to the class description and linking to it reduces the repetitive wording, but also eliminates the confusion that the getters may return those values. This should be OK, as setting limits higher than those values are likely rare, so the warning does not need to be in every method description.
> 
> Additionally, `getMaximumIntegerDigits()` is updated to point to the patterns section to warn about the non-obvious rules for max integer digits.

This pull request has now been integrated.

Changeset: 3d32c460
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d32c460eb60aa95f27c96bbefdf784f6a7663f7
Stats:     46 lines in 1 file changed: 17 ins; 22 del; 7 mod

6503196: API doc for DecimalFormat::getMaximumIntegerDigits is unclear

Reviewed-by: naoto, iris

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

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

From acobbs at openjdk.org  Thu Jan 25 21:38:54 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 25 Jan 2024 21:38:54 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

  Change MessageFormat.toPattern() @implNote to @implSpec.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/58e8cc68..7f96511e

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

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

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

From jlu at openjdk.org  Thu Jan 25 22:52:30 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 Jan 2024 22:52:30 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

Hi Archie, thanks for the updates,

I did testing with some more edge cases, and everything still looks good to me. 

In terms of the CSR,

- Can you update the CSR with the `implSpec` tag as well? 
- Although definitely relevant, I'm not sure if the _special behavior_ section is too involved for a CSR. Perhaps you can move that section to a comment or make it apart of the description in the PR instead?
> After this change, the result of fmt2.toPattern() will be the same as fmt1.toPattern(). 
- While true, I think you should make it apparent that after the change, fmt1.toPattern() returns `{0,number,:'}' #0.##}` now, instead of `{0,number,:} #0.##}`.

Once you make these changes, I will mark it as reviewed by me.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1911121617

From acobbs at openjdk.org  Thu Jan 25 23:05:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 25 Jan 2024 23:05:35 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <8aC3_aHIyJ07yrMtT2GmTdQySoPigx8XP6IJDOuG8bY=.6de28f98-2b95-4927-95a8-0c5af7f61e31@github.com>
Message-ID: <oTV5oabwm2Q04qpcKVBPX_WdxPCifbK0_UL_G6ipXGU=.847ed924-6e42-4c60-b238-403c5504005b@github.com>

On Thu, 25 Jan 2024 22:49:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> In terms of the CSR,...

Hi Justin, thanks again very much for the comments and careful review. The CSR should be updated accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1911134650

From jlu at openjdk.org  Fri Jan 26 19:02:29 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jan 2024 19:02:29 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

Hi Archie,

I wasn't sure if you were waiting to make additional changes or something else, but you can go ahead and re-finalize the CSR (when you are ready), now that it has been reviewed.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1912543193

From acobbs at openjdk.org  Fri Jan 26 19:22:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 19:22:35 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <xKD1UBG7WEYbWTeTFGMmFTpAAfceEkhI_VAGfGSfovI=.037e1858-0630-4672-9cb5-e11a71e562f9@github.com>
Message-ID: <2Uqr1UFSliWOb8Vx9xq8bDFjbBtm3FF2oUwjm7QY8rQ=.1354c971-c101-4014-99b0-3b7dc868a5f1@github.com>

On Fri, 26 Jan 2024 18:58:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

> I wasn't sure if you were waiting to make additional changes or something else, but you can go ahead and re-finalize the CSR (when you are ready), now that it has been reviewed.

Thanks - I wasn't sure about that. I've updated it now.

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

PR Comment: https://git.openjdk.org/jdk/pull/17416#issuecomment-1912570659

From rriggs at openjdk.org  Fri Jan 26 20:54:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 26 Jan 2024 20:54:27 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
Message-ID: <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>

On Thu, 25 Jan 2024 21:38:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
>> 
>> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
>> 
>> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
>> 
>> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
>> 
>> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
>> 
>> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
>> 
>> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
>> 
>> As a result, invoking `f.format(new ...
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Change MessageFormat.toPattern() @implNote to @implSpec.

src/java.base/share/classes/java/text/MessageFormat.java line 558:

> 556:      * @implSpec The implementation in {@link MessageFormat} returns a string
> 557:      * that can be used to create a new instance that is semantically equivalent
> 558:      * to this instance.

The "can be used to create" seems conditional. Perhaps it can be worded as an assertion that can be tested.
Suggestion:

     * @implSpec A new MessageFormat created from the string returned from the implementation of 
     * `MessageFormat.toPattern()` is semantically equivalent to this instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468118990

From acobbs at openjdk.org  Fri Jan 26 21:19:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 21:19:45 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
Message-ID: <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>

On Fri, 26 Jan 2024 20:30:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The "can be used to create" seems conditional. 

It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.

But I also understand how it comes across as a bit wishy-washy...

Hmm, what do you think about this wording?


@implSpec The implementation in {@link MessageFormat} returns a string that,
when passed to the {@link MessageFormat(String)} constructor, produces an
instance that is semantically equivalent to this instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468155069

From jlu at openjdk.org  Fri Jan 26 21:31:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 26 Jan 2024 21:31:37 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
 <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
Message-ID: <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>

On Fri, 26 Jan 2024 21:16:47 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 558:
>> 
>>> 556:      * @implSpec The implementation in {@link MessageFormat} returns a string
>>> 557:      * that can be used to create a new instance that is semantically equivalent
>>> 558:      * to this instance.
>> 
>> The "can be used to create" seems conditional. Perhaps it can be worded as an assertion that can be tested.
>> Suggestion:
>> 
>>      * @implSpec A new MessageFormat created from the string returned from the implementation of 
>>      * `MessageFormat.toPattern()` is semantically equivalent to this instance.
>
>> The "can be used to create" seems conditional. 
> 
> It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.
> 
> But I also understand how it comes across as a bit wishy-washy...
> 
> Hmm, what do you think about this wording?
> 
> 
> @implSpec The implementation in {@link MessageFormat} returns a string that,
> when passed to the {@link MessageFormat(String)} constructor, produces an
> instance that is semantically equivalent to this instance.

Not sure which wording will ultimately be used, but if the wording ends up including the constructor, it's probably worth mentioning the `applyPattern` method as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468163934

From acobbs at openjdk.org  Fri Jan 26 21:40:35 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 26 Jan 2024 21:40:35 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v5]
In-Reply-To: <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
 <6msVU9NAN9Pnhg77pNxV2fs4nA7-HY25BTg257k6SLk=.594ed605-1769-49fb-a502-229b0d99ed7b@github.com>
 <b8-TpGN-tlZ0k7WYsrYLMBdCTylPBND4-Kks1tYfkV0=.5b3b7acb-0452-4b2c-a7d2-dba551f24379@github.com>
 <rvsyB6kFqTdm8GC0Enmmz_vDz80AZXmzic1sztlwE2o=.be934378-3863-41e1-a38e-51a774b4803e@github.com>
 <NUM4BtCgx6_ZiD6lYyOKU3naHpmmx20gRIFXz96HW-A=.3ce6bf5b-5f90-4210-bd04-81e177653dfd@github.com>
Message-ID: <PxKkpt_w1w9NOpZM5ki20-J6-s9091Es9RcvJPa63i4=.13559259-8d97-45bc-83f7-fbd72c375689@github.com>

On Fri, 26 Jan 2024 21:28:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>> The "can be used to create" seems conditional. 
>> 
>> It is conditional - in the sense that you don't _have_ to use it to create a new instance of `MessageFormat`. You can also use it for something else, in other words.
>> 
>> But I also understand how it comes across as a bit wishy-washy...
>> 
>> Hmm, what do you think about this wording?
>> 
>> 
>> @implSpec The implementation in {@link MessageFormat} returns a string that,
>> when passed to the {@link MessageFormat(String)} constructor, produces an
>> instance that is semantically equivalent to this instance.
>
> Not sure which wording will ultimately be used, but if the wording ends up including the constructor, it's probably worth mentioning the `applyPattern` method as well.

Good point... maybe this?

@implSpec The implementation in {@link MessageFormat} returns a string that, when passed
to a {@code MessageFormat()} constructor or {@link #applyPattern applyPattern()}, produces
an instance that is semantically equivalent to this instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17416#discussion_r1468170808

From acobbs at openjdk.org  Sun Jan 28 23:26:51 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 28 Jan 2024 23:26:51 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v6]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <CWhcoN44dkAPUgbaLuwCnwka0AXgZEfE63F_WdON5FU=.c0dc7d6d-6107-4b43-9a0d-0f489aea78d2@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

  Reword the @implSpec note for clarity per PR discussion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/7f96511e..a4d82c67

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

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

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

From acobbs at openjdk.org  Tue Jan 30 18:28:32 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 30 Jan 2024 18:28:32 GMT
Subject: <i18n dev> RFR: 8323699: MessageFormat.toPattern() generates
 non-equivalent MessageFormat pattern [v7]
In-Reply-To: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
References: <A84G_yKytN8J3096W6Ptw4D1b5Q8OfWuo4AJAb9d91Q=.2ad25e92-3710-4b1f-96c3-517cb3bccf08@github.com>
Message-ID: <ghqNTUFsoUYlbXazYygGZV7VZ3tlOj_z9tNLR4EDUSQ=.04239c7d-4747-428a-bc13-8e7a5f171b43@github.com>

> Please consider this fix to ensure that going from `MessageFormat` to pattern string via `toPattern()` and then back via `new MessageFormat()` results in a format that is equivalent to the original.
> 
> The quoting and escaping rules for `MessageFormat` pattern strings are really tricky. I admit not completely understanding them. At a high level, they work like this: The normal way one would "nest" strings containing special characters is with straightforward recursive escaping like with the `bash` command line. For example, if you want to echo `a "quoted string" example` then you enter `echo "a "quoted string" example"`. With this scheme it's always the "outer" layer's job to (un)escape special characters as needed. That is, the echo command never sees the backslash characters.
> 
> In contrast, with `MessageFormat` and friends, nested subformat pattern strings are always provided "pre-escaped". So to build an "outer" string (e.g., for `ChoiceFormat`) the "inner" subformat pattern strings are more or less just concatenated, and then only the `ChoiceFormat` option separator characters (e.g., `<`, `#`, `|`, etc.) are escaped.
> 
> The "pre-escape" escaping algorithm escapes `{` characters, because `{` indicates the beginning of a format argument. However, it doesn't escape `}` characters. This is OK because the format string parser treats any "extra" closing braces (where "extra" means not matching an opening brace) as plain characters.
> 
> So far, so good... at least, until a format string containing an extra closing brace is nested inside a larger format string, where the extra closing brace, which was previously "extra", can now suddenly match an opening brace in the outer pattern containing it, thus truncating it by "stealing" the match from some subsequent closing brace.
> 
> An example is the `MessageFormat` string `"{0,choice,0.0#option A: {1}|1.0#option B: {1}'}'}"`. Note the second option format string has a trailing closing brace in plain text. If you create a `MessageFormat` with this string, you see a trailing `}` only with the second option.
> 
> However, if you then invoke `toPattern()`, the result is `"{0,choice,0.0#option A: {1}|1.0#option B: {1}}}"`. Oops, now because the "extra" closing brace is no longer quoted, it matches the opening brace at the beginning of the string, and the following closing  brace, which was the previous match, is now just plain text in the outer `MessageFormat` string.
> 
> As a result, invoking `f.format(new Object{} { 0, 5 })` will retur...

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

  Fix misspelling in comment.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17416/files
  - new: https://git.openjdk.org/jdk/pull/17416/files/a4d82c67..76e3d6ef

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

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

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

From eirbjo at openjdk.org  Tue Jan 30 20:07:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 20:07:57 GMT
Subject: <i18n dev> RFR: 8324998: Add test cases for String.regionMatches
 comparing Turkic dotted/dotless I with uppercase latin I
Message-ID: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>

Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 

The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.

This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

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

Commit messages:
 - Update copyright year
 - Add test coverage for regionMatches of Turkic dotted I / dotless i against LATIN CAPITAL LETTER I

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

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

From jlu at openjdk.org  Tue Jan 30 21:23:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 21:23:56 GMT
Subject: <i18n dev> RFR: JDK-6285888: ChoiceFormat can support unescaped
 relational symbols in the Format segment
Message-ID: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.

Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.

For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.

Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

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

Commit messages:
 - update PatternsTest
 - more accurately define the SubPattern note
 - init

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

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

From naoto at openjdk.org  Tue Jan 30 22:41:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 Jan 2024 22:41:42 GMT
Subject: <i18n dev> RFR: JDK-6285888: ChoiceFormat can support unescaped
 relational symbols in the Format segment
In-Reply-To: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
Message-ID: <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>

On Tue, 30 Jan 2024 21:19:27 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
> 
> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
> 
> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
> 
> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

src/java.base/share/classes/java/text/ChoiceFormat.java line 185:

> 183:  * it must be single quoted. For example,
> 184:  * {@code new ChoiceFormat("1# '#'1 ").format(1)} returns {@code " #1 "}.
> 185:  * Use two single quotes in a row to produce a literal single quote. For example,

It sounds right to remove this restriction, but if we were to use `|` inside `Format`, shouldn't it still need to be single-quoted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17640#discussion_r1472064667

From naoto at openjdk.org  Tue Jan 30 22:49:41 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 Jan 2024 22:49:41 GMT
Subject: <i18n dev> RFR: 8324998: Add test cases for
 String.regionMatches comparing Turkic dotted/dotless I with uppercase latin
 I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <KKKK9stCjzh0NYbF7VtVZKzDG5ngfYXJUWFsUjPloTE=.21df0230-519a-410f-839f-7ef4d20e51d4@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

Looks reasonable to me.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17639#pullrequestreview-1852521752

From jlu at openjdk.org  Tue Jan 30 23:09:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 23:09:17 GMT
Subject: <i18n dev> RFR: JDK-6285888: ChoiceFormat can support unescaped
 relational symbols in the Format segment [v2]
In-Reply-To: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
Message-ID: <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
> 
> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
> 
> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
> 
> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.

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

  update wording on quoting behavior

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17640/files
  - new: https://git.openjdk.org/jdk/pull/17640/files/a088f91f..740686b2

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

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

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

From jlu at openjdk.org  Tue Jan 30 23:09:17 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 30 Jan 2024 23:09:17 GMT
Subject: <i18n dev> RFR: JDK-6285888: ChoiceFormat can support unescaped
 relational symbols in the Format segment [v2]
In-Reply-To: <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
 <6zMszAL4vLbJXR6deHIGtCaMyrbPgRqOIWjibkJwB64=.021e48d0-b906-4378-95cf-8a1e286a1c79@github.com>
Message-ID: <XPCcZA9Rtbl0davyA-c-Nnf8rpLtk5c1M8N0MM-nTbo=.22d74b99-a5b0-4c7d-99bc-27800687a8d7@github.com>

On Tue, 30 Jan 2024 22:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update wording on quoting behavior
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 185:
> 
>> 183:  * <p>
>> 184:  * For more sophisticated patterns, {@code ChoiceFormat} can be used with
>> 185:  * {@link MessageFormat} to produce accurate forms for singular and plural:
> 
> It sounds right to remove this restriction, but if we were to use `|` inside `Format`, shouldn't it still need to be single-quoted?

Right, the restriction shouldn't be removed, but rather updated. Fixed in https://github.com/openjdk/jdk/pull/17640/commits/740686b2052a276b77529bea5444692e5bbe0078

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17640#discussion_r1472075577

From iris at openjdk.org  Tue Jan 30 23:12:30 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 30 Jan 2024 23:12:30 GMT
Subject: <i18n dev> RFR: 8324998: Add test cases for
 String.regionMatches comparing Turkic dotted/dotless I with uppercase latin
 I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <xKkTCExB2_rwGi33fz1-wFvnmLa5S1fShd3G_xtrkT0=.db798137-4872-4c36-86b3-40dc198e155a@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17639#pullrequestreview-1852564646

From eirbjo at openjdk.org  Tue Jan 30 23:56:10 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 30 Jan 2024 23:56:10 GMT
Subject: <i18n dev> Integrated: 8324998: Add test cases for
 String.regionMatches comparing Turkic dotted/dotless I with uppercase latin
 I
In-Reply-To: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
References: <OvNCyaHIxwXIMccjW3iybUkMcndBWRCdBVs3hKdmKM8=.ab476633-9320-4b53-9e55-b1af2b3ac9f7@github.com>
Message-ID: <x3GVivajet_402tCaJJH8PvZZONI1CZKUanoXOiOvCU=.2eab5023-5cd7-482c-94bf-6ccf11cabd23@github.com>

On Tue, 30 Jan 2024 19:57:01 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which improves test coverage of `String.regionMatches` when comparing the Turkic "dotted I" and "dotless i" characters with their latin cousins. 
> 
> The test `CompactStrings/RegionMatches.java` currently includes cases comparing these characters against the lowercase latin "i" character, but not against the corresponding uppercase latin "I" character. It would be good to add test cases for the uppercase I as well.
> 
> This was originally found in #12637, which was closed without being integrated. I think this test coverage enhancement is worth rescuing from that PR, where it did prove to catch a regression.

This pull request has now been integrated.

Changeset: c3c1d5bd
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3c1d5bd12f80c6a720e431961e90b09c2d972f9
Stats:     5 lines in 1 file changed: 4 ins; 0 del; 1 mod

8324998: Add test cases for String.regionMatches comparing Turkic dotted/dotless I with uppercase latin I

Reviewed-by: naoto, iris

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

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

From naoto at openjdk.org  Wed Jan 31 17:55:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 Jan 2024 17:55:02 GMT
Subject: <i18n dev> RFR: JDK-6285888: ChoiceFormat can support unescaped
 relational symbols in the Format segment [v2]
In-Reply-To: <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>
References: <154YlkQWp3Zi9ksGuOUZpDkdQUXuq0musq8HuCq_LAw=.de42ce19-8d56-44fb-861b-72e3380a49b4@github.com>
 <KpSLzTox6u1ecpTC_z8jxHv6OeFYcQcdny_ghXL1V1A=.8b637d59-dd46-49a4-b098-35b6ea564178@github.com>
Message-ID: <zYe4lYy6lbwojsPrqudgtRRGPpO_NsMiNXEibqbUlr0=.27586a8f-4d76-4ba5-a699-2266f9936b1a@github.com>

On Tue, 30 Jan 2024 23:09:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8314822) which allows for the _Format_ segment of a ChoiceFormat pattern to use the ChoiceFormat Relational symbols without the need to escape them using quotes. Previously, using a non escaped Relational symbol within a _Format_ segment would throw an IAE.
>> 
>> Implementation wise, this can be achieved by adding an additional check of `part == 0` to the relational symbol conditional. This is safe to do, as any subsequent relational symbols should only come after a '|' is parsed, which sets part back to 0. This ensures that for the duration of `part = 1` (Format segment), the relational symbols can be used without syntactic meaning.
>> 
>> For example, this change allows behavior such as: `new ChoiceFormat("1#The code is #7281")`. Previously, the workaround would have been new `ChoiceFormat("1#The code is '#'7281")` to achieve the same formatted behavior. Please see the CSR for more detail.
>> 
>> Additionally, this change also includes an unrelated grouping of the ChoiceFormat examples under a single header: **Usage Information**.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update wording on quoting behavior

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17640#pullrequestreview-1854463383

From jlu at openjdk.org  Wed Jan 31 22:28:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 31 Jan 2024 22:28:16 GMT
Subject: <i18n dev> RFR: JDK-8318761: MessageFormat pattern support for
 CompactNumberFormat, ListFormat, and DateTimeFormatter
Message-ID: <KgYv_zUO6u33Kh0xsRLkcVtisnwzca5ChZZJxCWWP5w=.e9ef803f-1470-4d62-97e2-b110f8baf846@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319344) which adds MessageFormat pattern support for the following subformats: ListFormat, CompactNumberFormat, and DateTimeFormatter. This change is intended to provide pattern support for the more recently added JDK Format subclasses, as well as improving java.time formatting within i18n. The draft javadoc can be viewed here: https://cr.openjdk.org/~jlu/docs/api/java.base/java/text/MessageFormat.html. Please see the CSR for more in-depth behavioral changes, as well as limitations.

The `FormatTypes`:  dtf_date, dtf_time, dtf_datetime, pre-defined DateTimeFormatter(s), and list are added.
The `FormatStyles`: compact_short, compact_long, or, and unit are added.

For example, previously,


Object[] args = {LocalDate.of(2023, 11, 16), LocalDate.of(2023, 11, 27)};
MessageFormat.format("It was {0,date,full}, now it is {1,date,full}", args);


would throw `Exception java.lang.IllegalArgumentException: Cannot format given Object as a Date`

Now, a user can call


MessageFormat.format("It was {0,dtf_date,full}, now it is {1,dtf_date,full}", args);


which returns "It was Thursday, November 16, 2023, now it is Friday, November 17, 2023"

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/17663/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17663&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318761
  Stats: 1166 lines in 6 files changed: 871 ins; 198 del; 97 mod
  Patch: https://git.openjdk.org/jdk/pull/17663.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17663/head:pull/17663

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