From jlu at openjdk.org  Mon Oct  2 05:46:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 2 Oct 2023 05:46:58 GMT
Subject: <i18n dev> Integrated: 5066247: Refine the spec of equals() and
 hashCode() for j.text.Format classes
In-Reply-To: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
References: <S-hzPB_dUxnmtzKCQKgTfyjFNKkxWyCLqbh1iix3z28=.a96f2384-b081-4131-9042-903210bda301@github.com>
Message-ID: <anLSaEdq_UsYbQbbI_buWPE1NWDoF0caGucSqMOYxhw=.a803e33a-0247-4835-9fd7-ef17b3db4a67@github.com>

On Mon, 28 Aug 2023 21:24:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8315720) which refines the spec of `equals()` and `hashCode()` in `java.text.Format` related classes.
> 
> The current spec for most of these methods is either  "_Overrides <method_name>_" or are incomplete/wrong (i.e. see `ChoiceFormat`).
> 
> This fix adjusts the spec to provide a consistent definition for the overridden methods and specify what is being compared/used to generate a hash code value.
> 
> For implementations that use at most a few fields, the values are stated, otherwise a more general term is used as a substitution (i.e. see `DecimalFormat`).

This pull request has now been integrated.

Changeset: 8fcf70e9
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fcf70e931cd2e69e644c459d16d1410ce7ff3ae
Stats:     142 lines in 9 files changed: 117 ins; 1 del; 24 mod

5066247: Refine the spec of equals() and hashCode() for j.text.Format classes

Reviewed-by: naoto, darcy

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

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

From naoto at openjdk.org  Mon Oct  2 17:06:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Oct 2023 17:06:52 GMT
Subject: <i18n dev> RFR: 8317265: ListFormat::format specification could be
 made clearer regarding handling IllegalArgumentException.
Message-ID: <V5Rro3BAKoHuhtGwzL6EjyfarN3XAMKct9ExuTmImv0=.5208d982-be28-4b76-aa6d-787c5590c599@github.com>

A simple clarification of the conditions for throwing an IAE.

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

Commit messages:
 - initial commit

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

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

From naoto at openjdk.org  Mon Oct  2 18:26:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 2 Oct 2023 18:26:54 GMT
Subject: <i18n dev> RFR: JDK-8315064: j.text.ChoiceFormat provides no
 specification on quoting behavior
In-Reply-To: <de9zHai6-4m_2GW1JMuHA_vdmaSlXQQMfLz1N0bOHo4=.8ca7599d-63e8-43e8-b840-c50ea41b418d@github.com>
References: <de9zHai6-4m_2GW1JMuHA_vdmaSlXQQMfLz1N0bOHo4=.8ca7599d-63e8-43e8-b840-c50ea41b418d@github.com>
Message-ID: <k9gQUgjO5W_D8yhx_JpAo_w9ZRmv29LqZkiszrLvF6U=.165d3fb0-b9c0-42f1-b31d-1b5354f73cbc@github.com>

On Fri, 29 Sep 2023 20:46:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and which adjusts the pattern section of java.text.ChoiceFormat to specify the single quote behavior within a String pattern.
> 
> The other Format classes that take a String pattern such as DecimalFormat, CompactNumberFormat, and MessageFormat all provide specification on single quote behavior within a String pattern. ChoiceFormat should have similar specification.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15994#pullrequestreview-1653267645

From jlu at openjdk.org  Tue Oct  3 16:25:32 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Oct 2023 16:25:32 GMT
Subject: <i18n dev> RFR: JDK-8316696: Remove the testing base classes:
 IntlTest and CollatorTest [v6]
In-Reply-To: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
Message-ID: <zGk3iCLmmyDnlefrnypwojNsqPMB2I_c_RjahJucZg4=.95c61585-ca1d-4ae4-ad69-9d73976e7314@github.com>

> Please review this PR which removes the i18n related testing base classes `IntlTest` and `CollatorTest` and converts all the tests that use them,
> 
> IntlTest and CollatorTest are testing classes which are extended by tests in `text/`, `util/Locale`, `util/TimeZone`, and `util/Calendar`. The abstract testing classes are quite dated and have caused issues such as: variation between OS, hiding stack trace, and causing tests to spuriously pass.
> 
> This change mainly automates a low level conversion of all the tests (75) using the frameworks; all tests were converted to use JUnit instead. (With the exception of `DateFormatRoundTripTest` due to the nature of the test).
> 
> The main changes can be viewed in the following commits
> 
> scripted changes - [c0ece01 ](https://github.com/openjdk/jdk/commit/c0ece01e91479a020d5c6dce937dc827472b763b)
> - Converts the IntlTest methods logln, log, err, and errln
> - Adds the JUnit Test annotation to tests that should be ran
> - Adjusts the Jtreg tags accordingly
> - Remove the main method
> - Insert initAll() methods for tests that previously adjusted the JVM default Locale/TimeZone in the main method
> 
> manual changes - [9a54910](https://github.com/openjdk/jdk/commit/9a5491065a94a4dc7a05194f3b8330efba8077b7)
> - Some tests that had extensive logic in the main method or did not follow the general IntlTest format had to be manually adjusted
> - Also clarified some tests that had optional argument setup in the main method (now removed)
> 
> removal of IntlTest and CollatorTest - [8ee9f9c](https://github.com/openjdk/jdk/commit/8ee9f9c79f79210ee6244186970d87a1cac05556) [f90266f](https://github.com/openjdk/jdk/pull/15954/commits/f90266f4f019c031c5f985dd658f62a02cc8b422) [3c67679](https://github.com/openjdk/jdk/pull/15954/commits/3c676794dd0c703db066a346c36e213d113d9acc)
> - Removes IntlTest in both the testlib and under TimeZone/
> - Replaces CollatorTest with CollatorTestUtils
> 
> Tiers 1-3 clean

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

  typo in import

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15954/files
  - new: https://git.openjdk.org/jdk/pull/15954/files/47532e8a..d20b085c

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

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

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

From jlu at openjdk.org  Tue Oct  3 16:41:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 3 Oct 2023 16:41:49 GMT
Subject: <i18n dev> Integrated: JDK-8316696: Remove the testing base
 classes: IntlTest and CollatorTest
In-Reply-To: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
References: <0dqEjJeA1VSwcSJBMpyE0Yj5lvl9U7yEZQukUWkbdkk=.885f5c8f-0752-400f-a0ea-f6cf40433697@github.com>
Message-ID: <X3-To9txBt93HVpkqpfjFw4Dkvj8H-COT6bPtY3EkL0=.2d34a417-6918-4eef-a2f3-c69ee6a15e7d@github.com>

On Thu, 28 Sep 2023 01:02:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the i18n related testing base classes `IntlTest` and `CollatorTest` and converts all the tests that use them,
> 
> IntlTest and CollatorTest are testing classes which are extended by tests in `text/`, `util/Locale`, `util/TimeZone`, and `util/Calendar`. The abstract testing classes are quite dated and have caused issues such as: variation between OS, hiding stack trace, and causing tests to spuriously pass.
> 
> This change mainly automates a low level conversion of all the tests (75) using the frameworks; all tests were converted to use JUnit instead. (With the exception of `DateFormatRoundTripTest` due to the nature of the test).
> 
> The main changes can be viewed in the following commits
> 
> scripted changes - [c0ece01 ](https://github.com/openjdk/jdk/commit/c0ece01e91479a020d5c6dce937dc827472b763b)
> - Converts the IntlTest methods logln, log, err, and errln
> - Adds the JUnit Test annotation to tests that should be ran
> - Adjusts the Jtreg tags accordingly
> - Remove the main method
> - Insert initAll() methods for tests that previously adjusted the JVM default Locale/TimeZone in the main method
> 
> manual changes - [9a54910](https://github.com/openjdk/jdk/commit/9a5491065a94a4dc7a05194f3b8330efba8077b7)
> - Some tests that had extensive logic in the main method or did not follow the general IntlTest format had to be manually adjusted
> - Also clarified some tests that had optional argument setup in the main method (now removed)
> 
> removal of IntlTest and CollatorTest - [8ee9f9c](https://github.com/openjdk/jdk/commit/8ee9f9c79f79210ee6244186970d87a1cac05556) [f90266f](https://github.com/openjdk/jdk/pull/15954/commits/f90266f4f019c031c5f985dd658f62a02cc8b422) [3c67679](https://github.com/openjdk/jdk/pull/15954/commits/3c676794dd0c703db066a346c36e213d113d9acc)
> - Removes IntlTest in both the testlib and under TimeZone/
> - Replaces CollatorTest with CollatorTestUtils
> 
> Tiers 1-3 clean

This pull request has now been integrated.

Changeset: b859da9c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b859da9c548fbd1463b336059d1c55312c7b7ba4
Stats:     4465 lines in 79 files changed: 922 ins; 1081 del; 2462 mod

8316696: Remove the testing base classes: IntlTest and CollatorTest

Reviewed-by: naoto

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

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

From joehw at openjdk.org  Tue Oct  3 18:23:36 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 3 Oct 2023 18:23:36 GMT
Subject: <i18n dev> RFR: 8317265: ListFormat::format specification could
 be made clearer regarding handling IllegalArgumentException.
In-Reply-To: <V5Rro3BAKoHuhtGwzL6EjyfarN3XAMKct9ExuTmImv0=.5208d982-be28-4b76-aa6d-787c5590c599@github.com>
References: <V5Rro3BAKoHuhtGwzL6EjyfarN3XAMKct9ExuTmImv0=.5208d982-be28-4b76-aa6d-787c5590c599@github.com>
Message-ID: <t69Wx8ZYBkqvr3vIUOyTCpSlmm7Q963tk3LQXVAFnx0=.4d609002-7c54-4e67-b451-5dc23008620d@github.com>

On Mon, 2 Oct 2023 16:59:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple clarification of the conditions for throwing an IAE.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16013#pullrequestreview-1655850720

From naoto at openjdk.org  Tue Oct  3 18:36:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 3 Oct 2023 18:36:05 GMT
Subject: <i18n dev> Integrated: 8317265: ListFormat::format specification
 could be made clearer regarding handling IllegalArgumentException.
In-Reply-To: <V5Rro3BAKoHuhtGwzL6EjyfarN3XAMKct9ExuTmImv0=.5208d982-be28-4b76-aa6d-787c5590c599@github.com>
References: <V5Rro3BAKoHuhtGwzL6EjyfarN3XAMKct9ExuTmImv0=.5208d982-be28-4b76-aa6d-787c5590c599@github.com>
Message-ID: <oSpyVOZ6Leo3vNSSQ4sXQmJRIs40exrNQIylCiRqDcM=.f73535cb-eba8-40a8-a6ba-a41bf700b171@github.com>

On Mon, 2 Oct 2023 16:59:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple clarification of the conditions for throwing an IAE.

This pull request has now been integrated.

Changeset: 1809b8cd
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1809b8cdd6f27fd2f19072a874f5020ca717ad11
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8317265: ListFormat::format specification could be made clearer regarding handling IllegalArgumentException.

Reviewed-by: joehw

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

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

From naoto at openjdk.org  Wed Oct  4 17:26:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 4 Oct 2023 17:26:34 GMT
Subject: <i18n dev> RFR: 8317443: StackOverflowError on calling
 ListFormat::getInstance() for Norwegian locales
Message-ID: <gzxz09qDg7ShAjw9uIJCAX4qNAYHmGughMp0O_LBt2w=.30f2e7ff-ddfc-410d-8adb-82b8f671bddf@github.com>

Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

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

Commit messages:
 - initial commit

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

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

From joehw at openjdk.org  Wed Oct  4 21:53:09 2023
From: joehw at openjdk.org (Joe Wang)
Date: Wed, 4 Oct 2023 21:53:09 GMT
Subject: <i18n dev> RFR: 8317443: StackOverflowError on calling
 ListFormat::getInstance() for Norwegian locales
In-Reply-To: <gzxz09qDg7ShAjw9uIJCAX4qNAYHmGughMp0O_LBt2w=.30f2e7ff-ddfc-410d-8adb-82b8f671bddf@github.com>
References: <gzxz09qDg7ShAjw9uIJCAX4qNAYHmGughMp0O_LBt2w=.30f2e7ff-ddfc-410d-8adb-82b8f671bddf@github.com>
Message-ID: <413nEWfXzYt1xL-8FlmHmEnUKTrWXkdRda5EaAp6Yog=.d51401bd-16ab-453e-8090-a48b9e2b8386@github.com>

On Wed, 4 Oct 2023 17:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
> Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16042#pullrequestreview-1658542105

From naoto at openjdk.org  Thu Oct  5 18:04:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Oct 2023 18:04:32 GMT
Subject: <i18n dev> RFR: 8317471: ListFormat::parseObject() spec can be
 improved on parsePosition valid values
Message-ID: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>

Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

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

Commit messages:
 - initial commit

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

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

From iris at openjdk.org  Thu Oct  5 20:02:05 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 5 Oct 2023 20:02:05 GMT
Subject: <i18n dev> RFR: 8317471: ListFormat::parseObject() spec can be
 improved on parsePosition valid values
In-Reply-To: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
References: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
Message-ID: <6IcMmt6-fjIGGr0yJKVahP4UBhOLuhpQNEkCEPjKWYg=.294ae254-11aa-4020-9cf7-53f54faf5442@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Documents existing behaviour.  Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660615062

From lancea at openjdk.org  Thu Oct  5 20:11:00 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 5 Oct 2023 20:11:00 GMT
Subject: <i18n dev> RFR: 8317471: ListFormat::parseObject() spec can be
 improved on parsePosition valid values
In-Reply-To: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
References: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
Message-ID: <_5Qk3vQ7EGCveaJ5BPtTeh2TnE4N88UF5XLTVIsQbPQ=.b74b9369-73bc-4385-a4b0-6c6ccefd6329@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660626757

From joehw at openjdk.org  Thu Oct  5 21:35:59 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 5 Oct 2023 21:35:59 GMT
Subject: <i18n dev> RFR: 8317471: ListFormat::parseObject() spec can be
 improved on parsePosition valid values
In-Reply-To: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
References: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
Message-ID: <H6Hla80PGs76LCVmqNrwJ608ISEkA5SjmuhHrtIXfiI=.2e508a7a-df2c-4ca3-8f41-85da8707f853@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1660771766

From naoto at openjdk.org  Thu Oct  5 23:09:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 5 Oct 2023 23:09:10 GMT
Subject: <i18n dev> Integrated: 8317443: StackOverflowError on calling
 ListFormat::getInstance() for Norwegian locales
In-Reply-To: <gzxz09qDg7ShAjw9uIJCAX4qNAYHmGughMp0O_LBt2w=.30f2e7ff-ddfc-410d-8adb-82b8f671bddf@github.com>
References: <gzxz09qDg7ShAjw9uIJCAX4qNAYHmGughMp0O_LBt2w=.30f2e7ff-ddfc-410d-8adb-82b8f671bddf@github.com>
Message-ID: <GXqUjA9VepgZVAqsY2WMUDrZQWf9n_JZpm_zF2ECquU=.50419275-5395-4464-987c-c5d0be1fdf40@github.com>

On Wed, 4 Oct 2023 17:17:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Please review the fix to the subject issue. This was found during upgrading CLDR to v44, in which some list patterns are missing (thus to be inherited from parents) in Norwegian locales which could end up with infinite parent lookup. Avoiding the recursive call and changing it to a plain loop fixes the issue.
> Not related to this issue, the test case has been corrected to work with any locale. Currently, it assumes English.

This pull request has now been integrated.

Changeset: 8a30c2a9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a30c2a9b2ef3f069e82061e6db113e259a75bcd
Stats:     15 lines in 2 files changed: 2 ins; 0 del; 13 mod

8317443: StackOverflowError on calling ListFormat::getInstance() for Norwegian locales

Reviewed-by: joehw

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

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

From jlu at openjdk.org  Fri Oct  6 17:25:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 17:25:36 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method
Message-ID: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 

That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

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

Commit messages:
 - code tag for MessageFormat::applyPattenr as well
 - Review: use 'may' wording
 - init

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

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

From jlu at openjdk.org  Fri Oct  6 18:07:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 18:07:37 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v2]
In-Reply-To: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
Message-ID: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
> 
> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

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

  tag setChoices as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/b4c89dd4..dc9cbae6

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

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

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

From jlu at openjdk.org  Fri Oct  6 18:54:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 6 Oct 2023 18:54:40 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests to
 use JUnit
Message-ID: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>

Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.

During the switch to JUnit, the tests had the following updates (to improve readability)
- separate the test data generation from the actual execution of the test
- create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

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

Commit messages:
 - trailing ws
 - Clarify data provider for BigDecimalCompatibilityTest.java
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/16035/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317372
  Stats: 942 lines in 9 files changed: 389 ins; 200 del; 353 mod
  Patch: https://git.openjdk.org/jdk/pull/16035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16035/head:pull/16035

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

From mli at openjdk.org  Sat Oct  7 20:06:14 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sat, 7 Oct 2023 20:06:14 GMT
Subject: <i18n dev> RFR: 8317471: ListFormat::parseObject() spec can be
 improved on parsePosition valid values
In-Reply-To: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
References: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
Message-ID: <lJGxode4ZK8A8TXKoVrV3eD-2-cYZEg0m5CDdtmWNgs=.70eff65e-d5f7-47b5-9a9b-a6e63742f55a@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

Marked as reviewed by mli (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16063#pullrequestreview-1663104345

From naoto at openjdk.org  Mon Oct  9 16:33:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Oct 2023 16:33:12 GMT
Subject: <i18n dev> Integrated: 8317471: ListFormat::parseObject() spec can
 be improved on parsePosition valid values
In-Reply-To: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
References: <XSnkT606hvSuV-eEthsD0SuFnzuMXuxLoLxNZVcWNUk=.1aae22c0-4f6e-4ca7-8d87-2e6575c75cbf@github.com>
Message-ID: <NmhljlWqBx1hRW049za8WqVM24hG0i-X4ug4vkFL1tM=.92fb1b5a-8dbc-46f6-af04-50796219faeb@github.com>

On Thu, 5 Oct 2023 17:57:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding IOOBE clause to clarify the behavior on an invalid `parsePos` argument on calling `ListFormat::parseObject()`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

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

8317471: ListFormat::parseObject() spec can be improved on parsePosition valid values

Reviewed-by: iris, lancea, joehw, mli

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

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

From naoto at openjdk.org  Mon Oct  9 22:47:16 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 9 Oct 2023 22:47:16 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: <qQYvOMbIZTI23WLrlfxqDzdpD7CHa9gt72DwdV-c3OA=.2b47d72b-62ee-417a-95f4-a9aeccedd352@github.com>

On Tue, 3 Oct 2023 22:23:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

test/jdk/java/text/Format/NumberFormat/BigDecimalCompatibilityTest.java line 162:

> 160:         // Check parse and returned value
> 161:         Number parsedValue = assertDoesNotThrow(()-> df.parse(longString),
> 162:                 "Should not throw a ParseException");

It could catch any exception, so the message could be broader. Maybe just `a ParseException` -> `an Exception`.

test/jdk/java/text/Format/NumberFormat/Bug4838107.java line 254:

> 252:                     "\n\tre-parsed number: " + parsed2 +
> 253:                     "  (" + parsed2.getClass().getName() + ")" +
> 254:                     "\n\tminus sign: " + df.getDecimalFormatSymbols().getMinusSign());

Could use text block to get rid of `\n`/`\t`s, with `.formatted()`. Same for the following one.

test/jdk/java/text/Format/NumberFormat/Bug4944439.java line 71:

> 69:     public void parseLongTest(String s) {
> 70:         Number parsedNumber = assertDoesNotThrow(() -> df.parse(s),
> 71:                 "DecimalFormat.parse(\"%s\") should not throw ParseException");

`ParseException` -> `Exception`. Applies to other locations

test/jdk/java/text/Format/NumberFormat/Bug4990596.java line 45:

> 43:     public void formatSubclassedNumberTest() {
> 44:         assertDoesNotThrow(() -> new DecimalFormat().format(new MutableInteger(0)),
> 45:                 "DecimalFormat.parse() should support subclasses of Number");

DecimalFormat.format()?

test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:

> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
> 46: 
> 47:         // i.e. "\u2019" as decimal separator, "\u2019" as grouping separator

This is incorrect (sorry, I am to be blamed as I wrote this ?). Should be "`\u002E` as decimal separator, " also remove `i.e.` if you move the comment on top of the variable declaration

test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:

> 60:     // currencySymbolsTest() is only ran for COMPAT
> 61:     private static final boolean isCompat =
> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));

This check could be moved into `currencySymbolsTest()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350752425
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350835828
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350845412
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350862874
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350883202
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1350899278

From job at kimmeringer.de  Tue Oct 10 10:47:58 2023
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Tue, 10 Oct 2023 12:47:58 +0200
Subject: <i18n dev> Date parsing issues with SimpleDateFormat and
 DateTimeFormatter
Message-ID: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>

Hi,

my first mail in this list, so please be gentle ;-)

I've encountered issues when trying to keep date parsing functionality when
migrating from Java 8 to Java 11. This happened a while ago and I implemented
local workarounds but with installations using more recent versions of Java 11
things broke again so I'm not sure if I'm simply doing things wrong or if there
are actual bugs.

I've attached my JUnit-class that contains the different issues (not as single
tests but I will highlight them here in this mail. "Here" SimpleDateFormat is
used but I've added a test to use DateTimeFormatter to make sure that it's
not the use of old classes and that the problem persists in the new API as
well.

Most issues come up when trying to parse abbreviated months with Locales
different from "en". Our use case is that data with the same date layout
but different Locales are parsed (e.g. Ebay revenue summary CSV-files or FTP
servers on german Windows installations). The dates used there are of the form

  - Ebay: 18. M?r 2023
  - FTP server: M?r 14  2022

This worked well with MMM in the template till Java 8 then LLL got introduced
and MMM now leads to the use of four letters being used for the abbreviation
including a dot. Btw: I think the Javadoc that explains the template-parts
(e.g. in SimpleDateFormat) should have an additional column containing an example
for a non-EN-Locale, because

M    Month in year (context sensitive)  Month  July; Jul; 07
L    Month in year (standalone form)    Month  July; Jul; 07

isn't helping at all to see the effect of these two template-parts, so e.g.

M    Month ... (context...)             Month   January;...   Januar; Jan.; 01
M    Month ... (standalone...)          Month   January;...   Januar; Jan; 01

might be better for understanding it.

With the use of LLL all tests with dates without a dot can now be parsed
again using the same mask. But it's not possible to parse a date where
the month is always abbreviated with a dot in a consistent way, e.g.

23. Dez. 2016 11:12:13.456
using the template
dd. LLL. yyyy HH:mm:ss.SSS

It works with Locale en (with "Dec" as month of course) but not with "de".

Reason is that SimpleDateFormat is using all month display names when
parsing "month standalone". That also includes the abbreviated month including
dots. Because these months are in general longer than their standalone
counterparts (except three-letter months like "Mai" in german)
matchString considers this as best match, "consuming" the dot in the text to
be parsed which is now missing when the parsing continues.

DateTimeFormatter seem to work differently because it's not failing at that
point (haven't debugged it) but is failing when trying to parse russian dates
without abbreviating dots. I assume that is because the ru-Locale doesn't
seem to have values for the standalone month. I could live with that given
our user base but the parser in java.time runs into problems when parsing
a time with milliseconds: You need to provide as many "S" as there are digits
in the value:

  - "23. Dec. 2016 11:12:13.456" needs "dd. LLL. yyyy HH:mm:ss.SSS",
    it doesn't work with "dd. LLL. yyyy HH:mm:ss.S"
  - "23. Dec. 2016 11:12:13.4"   needs "dd. LLL. yyyy HH:mm:ss.S",
    it doesn't work with "dd. LLL. yyyy HH:mm:ss.SSS"

When handling data from different sources where one source is cutting
away trailing zeros and the other isn't you essentially need to parse
the date to be parsed to use the correct template being used for parsing.

SimpleDateFormat parses the date correctly independent from the
number of "S" in the template and the actual number of digits
in the text to be parsed.

While my lengthy explanation of the problems with LLL might result into
the answer "not a bug, go away" ;-) I definitely see the milliseconds with
java.time.* as one.


Thanks for reading this far and best regards,

Lothar Kimmeringer
-------------- next part --------------
import static org.junit.Assert.assertEquals;

import java.text.ParsePosition;
import java.text.SimpleDateFormat;
import java.time.DateTimeException;
import java.time.Instant;
import java.time.LocalDate;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.format.DateTimeFormatter;
import java.time.temporal.TemporalAccessor;
import java.util.Date;
import java.util.Locale;

import org.junit.Test;

public class __Test_LocaleDateParsing {

    @FunctionalInterface
    static interface DateParseFunction {
        Date executeParser(String toParse, String mask, Locale locale);
    }
    
    @Test
    public void testParsingWithSimpleDateFormatter() throws Exception {
        performTests(__Test_LocaleDateParsing::parseUsingSimpleDateFormat);
    }
    
    @Test
    public void testParsingWithDateTime() throws Exception {
        performTests(__Test_LocaleDateParsing::parseUsingDateTimeParsing);
    }
    
    void performTests(DateParseFunction parser) {
//        SimpleDateFormat sdf = new SimpleDateFormat("yyyy-LLL-dd", new Locale("ru"));
//        System.out.println(sdf.format(new Date(113, 11, 11, 12, 34, 56)));
        assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 2023", String.valueOf(parser.executeParser("12. Sep 2023", "dd. LLL yyyy", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12 Mar 2023", "dd LLL yyyy", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 2023", String.valueOf(parser.executeParser("12 Sep 2023", "dd LLL yyyy", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12. Mar 2023", "dd. LLL yyyy", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Tue Dec 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12. Dec 2023", "dd. LLL yyyy", new Locale("en", "US"))));

        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.456", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.456", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23.Dec.2016 11:12:13.456", "dd.LLL.yyyy HH:mm:ss.SSS", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.4", "dd. LLL. yyyy HH:mm:ss.S", new Locale("en", "US"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23.Dec.2016 11:12:13.4", "dd.LLL.yyyy HH:mm:ss.S", new Locale("en", "US"))));

        assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 2023", String.valueOf(parser.executeParser("12. Sep 2023", "dd. LLL yyyy", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12 M?r 2023", "dd LLL yyyy", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 2023", String.valueOf(parser.executeParser("12 Sep 2023", "dd LLL yyyy", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12. M?r 2023", "dd. LLL yyyy", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Tue Dec 12 00:00:00 CET 2023", String.valueOf(parser.executeParser("12. Dez 2023", "dd. LLL yyyy", new Locale("de", "DE"))));

        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.456", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.456", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23.Dez.2016 11:12:13.456", "dd.LLL.yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.4", "dd. LLL. yyyy HH:mm:ss.S", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23.Dez.2016 11:12:13.4", "dd.LLL.yyyy HH:mm:ss.S", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Wed Dec 11 12:34:56 CET 2013", String.valueOf(parser.executeParser("11-???-2013 12:34:56", "dd-LLL-yyyy HH:mm:ss", new Locale("ru"))));
        

        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.456", "dd. MMM yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));
        assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016", String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.456", "dd. MMM yyyy HH:mm:ss.SSS", new Locale("en", "US"))));
    }
    
    private static Date parseUsingSimpleDateFormat(String toParse, String mask, Locale locale) {
        SimpleDateFormat formatter = new SimpleDateFormat(mask, locale);
        formatter.setLenient(false);
        ParsePosition pos = new ParsePosition(0);
        return formatter.parse(toParse, pos);
    }
    
    private static Date parseUsingDateTimeParsing(String toParse, String mask, Locale locale) {
        final DateTimeFormatter df = DateTimeFormatter.ofPattern(mask).withLocale(locale);
        TemporalAccessor res = df.parse(toParse);
        try {
            return Date.from(Instant.from(res));
        }
        catch(DateTimeException dte) {
            try {
                LocalDateTime ldt = LocalDateTime.from(res);
                return Date.from(ldt.atZone(ZoneId.systemDefault()).toInstant());
            }
            catch (DateTimeException dte2) {
//                dte2.printStackTrace();
                return Date.from(LocalDate.from(res).atStartOfDay(ZoneId.systemDefault()).toInstant());
            }
        }
    }
}

From naoto.sato at oracle.com  Tue Oct 10 17:24:14 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 10 Oct 2023 10:24:14 -0700
Subject: <i18n dev> Date parsing issues with SimpleDateFormat and
 DateTimeFormatter
In-Reply-To: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>
References: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>
Message-ID: <0882f1a4-dd5e-4f81-a2e1-ee46cddcfea7@oracle.com>

Hi Lothar,

The issue you are seeing here is the one we are aware of for a long 
time: https://bugs.openjdk.org/browse/JDK-8194289

The difference between JDK8 and JDK11 comes from the difference between 
JDK's legacy locale data and the CLDR locale data provided by the 
Unicode Consortium. The CLDR locale data became the default locale data 
in JDK9 (https://openjdk.org/jeps/252)

The locale data changes from time to time, from small ones such as 
translation changes to the somewhat significant ones, so the best course 
of action is not relying on any specific locale data. However, I see 
your situation is to parse dates from outside the JDK, so I understand 
you will need to adapt to whatever the date format the app receives.

As the immediate temporary solution, you could choose the legacy locale 
data over CLDR, by using the system property 
`java.locale.providers=COMPAT` mentioned in those JBS issues. For a 
longer term, you might want to implement 
`java.text.spi.DateFormatProvider` for your specific needs (in this 
case, parse abbreviated months without the trailing dot in German).

Please note that the system property value `COMPAT` was a temporary 
measure for migration, so it is deprecated as of JDK21 and will 
eventually be removed in the future JDK.

Also, we are in the process of revising the old release notes wrt the 
CLDR compatibility issues so that users will know them beforehand.

HTH,
Naoto

On 10/10/23 3:47 AM, Lothar Kimmeringer wrote:
> Hi,
> 
> my first mail in this list, so please be gentle ;-)
> 
> I've encountered issues when trying to keep date parsing functionality when
> migrating from Java 8 to Java 11. This happened a while ago and I 
> implemented
> local workarounds but with installations using more recent versions of 
> Java 11
> things broke again so I'm not sure if I'm simply doing things wrong or 
> if there
> are actual bugs.
> 
> I've attached my JUnit-class that contains the different issues (not as 
> single
> tests but I will highlight them here in this mail. "Here" 
> SimpleDateFormat is
> used but I've added a test to use DateTimeFormatter to make sure that it's
> not the use of old classes and that the problem persists in the new API as
> well.
> 
> Most issues come up when trying to parse abbreviated months with Locales
> different from "en". Our use case is that data with the same date layout
> but different Locales are parsed (e.g. Ebay revenue summary CSV-files or 
> FTP
> servers on german Windows installations). The dates used there are of 
> the form
> 
>  ?- Ebay: 18. M?r 2023
>  ?- FTP server: M?r 14? 2022
> 
> This worked well with MMM in the template till Java 8 then LLL got 
> introduced
> and MMM now leads to the use of four letters being used for the 
> abbreviation
> including a dot. Btw: I think the Javadoc that explains the template-parts
> (e.g. in SimpleDateFormat) should have an additional column containing 
> an example
> for a non-EN-Locale, because
> 
> M??? Month in year (context sensitive)? Month? July; Jul; 07
> L??? Month in year (standalone form)??? Month? July; Jul; 07
> 
> isn't helping at all to see the effect of these two template-parts, so e.g.
> 
> M??? Month ... (context...)???????????? Month?? January;...?? Januar; 
> Jan.; 01
> M??? Month ... (standalone...)????????? Month?? January;...?? Januar; 
> Jan; 01
> 
> might be better for understanding it.
> 
> With the use of LLL all tests with dates without a dot can now be parsed
> again using the same mask. But it's not possible to parse a date where
> the month is always abbreviated with a dot in a consistent way, e.g.
> 
> 23. Dez. 2016 11:12:13.456
> using the template
> dd. LLL. yyyy HH:mm:ss.SSS
> 
> It works with Locale en (with "Dec" as month of course) but not with "de".
> 
> Reason is that SimpleDateFormat is using all month display names when
> parsing "month standalone". That also includes the abbreviated month 
> including
> dots. Because these months are in general longer than their standalone
> counterparts (except three-letter months like "Mai" in german)
> matchString considers this as best match, "consuming" the dot in the 
> text to
> be parsed which is now missing when the parsing continues.
> 
> DateTimeFormatter seem to work differently because it's not failing at that
> point (haven't debugged it) but is failing when trying to parse russian 
> dates
> without abbreviating dots. I assume that is because the ru-Locale doesn't
> seem to have values for the standalone month. I could live with that given
> our user base but the parser in java.time runs into problems when parsing
> a time with milliseconds: You need to provide as many "S" as there are 
> digits
> in the value:
> 
>  ?- "23. Dec. 2016 11:12:13.456" needs "dd. LLL. yyyy HH:mm:ss.SSS",
>  ?? it doesn't work with "dd. LLL. yyyy HH:mm:ss.S"
>  ?- "23. Dec. 2016 11:12:13.4"?? needs "dd. LLL. yyyy HH:mm:ss.S",
>  ?? it doesn't work with "dd. LLL. yyyy HH:mm:ss.SSS"
> 
> When handling data from different sources where one source is cutting
> away trailing zeros and the other isn't you essentially need to parse
> the date to be parsed to use the correct template being used for parsing.
> 
> SimpleDateFormat parses the date correctly independent from the
> number of "S" in the template and the actual number of digits
> in the text to be parsed.
> 
> While my lengthy explanation of the problems with LLL might result into
> the answer "not a bug, go away" ;-) I definitely see the milliseconds with
> java.time.* as one.
> 
> 
> Thanks for reading this far and best regards,
> 
> Lothar Kimmeringer

From job at kimmeringer.de  Wed Oct 11 09:29:06 2023
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Wed, 11 Oct 2023 11:29:06 +0200
Subject: <i18n dev> Date parsing issues with SimpleDateFormat and
 DateTimeFormatter
In-Reply-To: <0882f1a4-dd5e-4f81-a2e1-ee46cddcfea7@oracle.com>
References: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>
 <0882f1a4-dd5e-4f81-a2e1-ee46cddcfea7@oracle.com>
Message-ID: <83369e05-7e52-fc46-31f3-7672a2c06a0f@kimmeringer.de>

Hi,

thanks for the answer.

Am 10.10.2023 um 19:24 schrieb Naoto Sato:

> The issue you are seeing here is the one we are aware of for a long time: https://bugs.openjdk.org/browse/JDK-8194289

These issues share key words but I think they are different. The bug report you've
linked to is using MMM as template (as our user base is currently using) but the
solution for that particular problem (as far as I understood) is using LLL instead.
As shown in my JUnit-test when using Java 11, these tests go through:

  assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 2023",
    String.valueOf(parser.executeParser("12. Sep 2023", "dd. LLL yyyy", new Locale("de", "DE"))));
  assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 2023",
    String.valueOf(parser.executeParser("12 M?r 2023", "dd LLL yyyy", new Locale("de", "DE"))));

are passing.

What's failing is the case where you always have an abbreviated month with a dot
(i.e. in English as well):

  assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016",
    String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.445", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("en", "US"))));

is passing while

  assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 2016",
    String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.456", "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));

is not. My understanding is that LLL is supposed to represent abbreviated
months with three letters without dot, so there shouldn't be different
outcomes when using different Locales. At least I would expect format and
parse are bijective which is not the case with this particular example.

> The locale data changes from time to time, from small ones such as translation
> changes to the somewhat significant ones

I know. That's why I have plenty of of unit-tests to see these changes between
Java releases ;-) and this isn't the first time I had to find workarounds to keep
the functionality that is provided to our user base.

This time though it happened between an update of Java 11.0.14 to 11.0.20 that
the result of a date-parsing process produced different results (I assume due
to the non-derterministic nature of map.keySet but I stopped debugging that
road when "discovering" LLL).

> so I understand you will need to adapt to whatever the date format the app receives.
> 
> As the immediate temporary solution, you could choose the legacy locale data over CLDR,

For our particular application I've solved it by setting up a SimpleDateFormat,
get the abbreviated months with sdf.getShortMonths(), cut them down to three
characters and reset them using dfs.setShortMonths.

I don't suggest that as general solution, it's just a workaround "here" to
keep the application's behavior to the way it's been the last decades. ;-)
So my actual "problem" has been solved with this workaround but I'm simply
confused about the "LLL." issue shown above and the ".S" issue that got
lost in your mail, i.e. the issue with java.time.DateTimeFormatter.parse not
being able to parse

  "23. Dez. 2016 11:12:13.456" with template "dd. LLL. yyyy HH:mm:ss.S"
  and
  "23. Dez. 2016 11:12:13.4" with template "dd. LLL. yyyy HH:mm:ss.SSS"


Thanks and best regards,

Lothar Kimmeringer

From pminborg at openjdk.org  Wed Oct 11 11:54:35 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 11:54:35 GMT
Subject: <i18n dev> RFR: 8317952: C-style array declarations in
 jdk.internal.icu
Message-ID: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>

This PR proposes to replace C-style array declarations with Java array declarations.

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

Commit messages:
 - Update copyright year
 - Replace C-style array declarations

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

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

From pminborg at openjdk.org  Wed Oct 11 12:12:09 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 12:12:09 GMT
Subject: <i18n dev> RFR: 8317952: C-style array declarations in
 jdk.internal.icu [v2]
In-Reply-To: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
References: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
Message-ID: <G3GH7y6YFKDFloDOMZsv9IdqiUab3NTdEjTiy7bWApE=.6109b522-ff91-476a-b06d-b91261b696bf@github.com>

> This PR proposes to replace C-style array declarations with Java array declarations.

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

  Fix additional classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16146/files
  - new: https://git.openjdk.org/jdk/pull/16146/files/596e2c4d..e53ae1eb

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

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

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

From redestad at openjdk.org  Wed Oct 11 13:06:13 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Wed, 11 Oct 2023 13:06:13 GMT
Subject: <i18n dev> RFR: 8317952: C-style array declarations in
 jdk.internal.icu [v2]
In-Reply-To: <G3GH7y6YFKDFloDOMZsv9IdqiUab3NTdEjTiy7bWApE=.6109b522-ff91-476a-b06d-b91261b696bf@github.com>
References: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
 <G3GH7y6YFKDFloDOMZsv9IdqiUab3NTdEjTiy7bWApE=.6109b522-ff91-476a-b06d-b91261b696bf@github.com>
Message-ID: <S0WlTrBo_oh7-VmQK9YKtwbUq3-tjqQ9QGpLcR2C0tM=.f319f979-1005-4c71-9a69-0d1010419b67@github.com>

On Wed, 11 Oct 2023 12:12:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to replace C-style array declarations with Java array declarations.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix additional classes

AFAICT the icu code is integrated from an upstream project (https://github.com/unicode-org/icu/blob/main/icu4j/main/core/src/main/java/com/ibm/icu ?) - so modifying the code in the openjdk will make it harder to sync it up with the upstream project. If possible improvements should be done in the upstream project, otherwise perhaps not at all (unless absolutely necessary for functional purposes). @naotoj?

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

PR Comment: https://git.openjdk.org/jdk/pull/16146#issuecomment-1757656489

From naoto at openjdk.org  Wed Oct 11 15:55:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 15:55:51 GMT
Subject: <i18n dev> RFR: 8317952: C-style array declarations in
 jdk.internal.icu [v2]
In-Reply-To: <S0WlTrBo_oh7-VmQK9YKtwbUq3-tjqQ9QGpLcR2C0tM=.f319f979-1005-4c71-9a69-0d1010419b67@github.com>
References: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
 <G3GH7y6YFKDFloDOMZsv9IdqiUab3NTdEjTiy7bWApE=.6109b522-ff91-476a-b06d-b91261b696bf@github.com>
 <S0WlTrBo_oh7-VmQK9YKtwbUq3-tjqQ9QGpLcR2C0tM=.f319f979-1005-4c71-9a69-0d1010419b67@github.com>
Message-ID: <n51MzW-CDkxQfSIeVZClwaQShXn5kJT6pFUalCDwDlM=.654fb91f-7f63-4bea-8506-9cac4b145825@github.com>

On Wed, 11 Oct 2023 13:03:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix additional classes
>
> AFAICT the icu code is integrated from an upstream project (https://github.com/unicode-org/icu/blob/main/icu4j/main/core/src/main/java/com/ibm/icu ?) - so modifying the code in the openjdk will make it harder to sync it up with the upstream project. If possible improvements should be done in the upstream project, otherwise perhaps not at all (unless absolutely necessary for functional purposes). @naotoj?

Yes, I agree with @cl4es here. Unless some dire need to fix them ourselves, I would leave them as they are. Otherwise, syncing with the upstream (which coincidentally I am working on right now) would be more complex.

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

PR Comment: https://git.openjdk.org/jdk/pull/16146#issuecomment-1758005313

From pminborg at openjdk.org  Wed Oct 11 16:40:59 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 16:40:59 GMT
Subject: <i18n dev> RFR: 8317952: C-style array declarations in
 jdk.internal.icu [v2]
In-Reply-To: <S0WlTrBo_oh7-VmQK9YKtwbUq3-tjqQ9QGpLcR2C0tM=.f319f979-1005-4c71-9a69-0d1010419b67@github.com>
References: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
 <G3GH7y6YFKDFloDOMZsv9IdqiUab3NTdEjTiy7bWApE=.6109b522-ff91-476a-b06d-b91261b696bf@github.com>
 <S0WlTrBo_oh7-VmQK9YKtwbUq3-tjqQ9QGpLcR2C0tM=.f319f979-1005-4c71-9a69-0d1010419b67@github.com>
Message-ID: <t8KeSSm8-lF6lsA_-lriKZFVItkEz_voa--Qs-SOt_U=.bc3e3d4d-9518-4851-9c06-12ff6a08d92a@github.com>

On Wed, 11 Oct 2023 13:03:26 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix additional classes
>
> AFAICT the icu code is integrated from an upstream project (https://github.com/unicode-org/icu/blob/main/icu4j/main/core/src/main/java/com/ibm/icu ?) - so modifying the code in the openjdk will make it harder to sync it up with the upstream project. If possible improvements should be done in the upstream project, otherwise perhaps not at all (unless absolutely necessary for functional purposes). @naotoj?

> Yes, I agree with @cl4es here. Unless some dire need to fix them ourselves, I would leave them as they are. Otherwise, syncing with the upstream (which coincidentally I am working on right now) would be more complex.

Ok. I will close this PR and leave it to you then @naotoj . There are a number of missing `final` declarations for instance variables that are missing in many places so you could mop up those too.

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

PR Comment: https://git.openjdk.org/jdk/pull/16146#issuecomment-1758028751

From pminborg at openjdk.org  Wed Oct 11 16:41:05 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 11 Oct 2023 16:41:05 GMT
Subject: <i18n dev> Withdrawn: 8317952: C-style array declarations in
 jdk.internal.icu
In-Reply-To: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
References: <-ojJQxdBiuGyMzve_DOMDOQxyVYlmxyCIxpIvTt1wts=.ddac59d6-c3f7-4b5b-84d1-9b390950c41c@github.com>
Message-ID: <VBvhz2zSI4KytI4n-uEATsRXUBjh60ZZnNA0_2Y3M7I=.7bb89ebd-b0b5-4575-a4bf-50045767ca42@github.com>

On Wed, 11 Oct 2023 11:46:47 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to replace C-style array declarations with Java array declarations.

This pull request has been closed without being integrated.

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

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

From naoto.sato at oracle.com  Wed Oct 11 18:23:04 2023
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 11 Oct 2023 11:23:04 -0700
Subject: <i18n dev> Date parsing issues with SimpleDateFormat and
 DateTimeFormatter
In-Reply-To: <83369e05-7e52-fc46-31f3-7672a2c06a0f@kimmeringer.de>
References: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>
 <0882f1a4-dd5e-4f81-a2e1-ee46cddcfea7@oracle.com>
 <83369e05-7e52-fc46-31f3-7672a2c06a0f@kimmeringer.de>
Message-ID: <f38fce97-b863-4e30-b9b8-982559130ddb@oracle.com>

Hi,

On 10/11/23 2:29 AM, Lothar Kimmeringer wrote:
> Hi,
> 
> thanks for the answer.
> 
> Am 10.10.2023 um 19:24 schrieb Naoto Sato:
> 
>> The issue you are seeing here is the one we are aware of for a long 
>> time: https://bugs.openjdk.org/browse/JDK-8194289
> 
> These issues share key words but I think they are different. The bug 
> report you've
> linked to is using MMM as template (as our user base is currently using) 
> but the
> solution for that particular problem (as far as I understood) is using 
> LLL instead.
> As shown in my JUnit-test when using Java 11, these tests go through:

I think the difference MMM and LLL does not matter here. As they both 
represent short months, either context or standalone. The fundamental 
issue whether the dot in the pattern is parsed as part of the month 
name, or the literal in the pattern is the same for both M/L.

> 
>  ?assertEquals("check parsing of short month", "Tue Sep 12 00:00:00 CEST 
> 2023",
>  ?? String.valueOf(parser.executeParser("12. Sep 2023", "dd. LLL yyyy", 
> new Locale("de", "DE"))));
>  ?assertEquals("check parsing of short month", "Sun Mar 12 00:00:00 CET 
> 2023",
>  ?? String.valueOf(parser.executeParser("12 M?r 2023", "dd LLL yyyy", 
> new Locale("de", "DE"))));
> 
> are passing.
> 
> What's failing is the case where you always have an abbreviated month 
> with a dot
> (i.e. in English as well):
> 
>  ?assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 
> 2016",
>  ?? String.valueOf(parser.executeParser("23. Dec. 2016 11:12:13.445", 
> "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("en", "US"))));
> 
> is passing while
> 
>  ?assertEquals("check parsing of short month", "Fri Dec 23 11:12:13 CET 
> 2016",
>  ?? String.valueOf(parser.executeParser("23. Dez. 2016 11:12:13.456", 
> "dd. LLL. yyyy HH:mm:ss.SSS", new Locale("de", "DE"))));
> 
> is not. My understanding is that LLL is supposed to represent abbreviated
> months with three letters without dot, so there shouldn't be different
> outcomes when using different Locales. At least I would expect format and
> parse are bijective which is not the case with this particular example.

The pattern "LLL" does not mean "without dot." It merely represents 
stand-alone short months. So depending on locales, it may or may not 
include the trailing dot (cf. 
https://www.unicode.org/cldr/charts/43/by_type/date_&_time.gregorian.html#5a9ad242364bdb22)

> 
>> The locale data changes from time to time, from small ones such as 
>> translation
>> changes to the somewhat significant ones
> 
> I know. That's why I have plenty of of unit-tests to see these changes 
> between
> Java releases ;-) and this isn't the first time I had to find 
> workarounds to keep
> the functionality that is provided to our user base.
> 
> This time though it happened between an update of Java 11.0.14 to 
> 11.0.20 that
> the result of a date-parsing process produced different results (I 
> assume due
> to the non-derterministic nature of map.keySet but I stopped debugging that
> road when "discovering" LLL).

This is interesting, as I expect no difference between update releases 
as CLDR version remains the same for both.

> 
>> so I understand you will need to adapt to whatever the date format the 
>> app receives.
>>
>> As the immediate temporary solution, you could choose the legacy 
>> locale data over CLDR,
> 
> For our particular application I've solved it by setting up a 
> SimpleDateFormat,
> get the abbreviated months with sdf.getShortMonths(), cut them down to 
> three
> characters and reset them using dfs.setShortMonths.

Thanks for letting us know the workaround. This kind of information 
helps our future work.

> 
> I don't suggest that as general solution, it's just a workaround "here" to
> keep the application's behavior to the way it's been the last decades. ;-)
> So my actual "problem" has been solved with this workaround but I'm simply
> confused about the "LLL." issue shown above and the ".S" issue that got
> lost in your mail, i.e. the issue with java.time.DateTimeFormatter.parse 
> not
> being able to parse
> 
>  ?"23. Dez. 2016 11:12:13.456" with template "dd. LLL. yyyy HH:mm:ss.S"
>  ?and
>  ?"23. Dez. 2016 11:12:13.4" with template "dd. LLL. yyyy HH:mm:ss.SSS"

The default parsing mode is "strict" in DateTimeFormatter, so the number 
of digits in those nano seconds should match. You will need to build the 
formatter such that:

new 
DateTimeFormatterBuilder().parseLenient().appendPattern("S").toFormatter()

to accept 0 to 9 digits nanosecs without padding.

Naoto

From jlu at openjdk.org  Wed Oct 11 21:20:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Oct 2023 21:20:47 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v2]
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: <qP1_9-A6QegVHDypCjc1j-7eQAXgnmXeQUW7UfBOrro=.b3fe86de-ed2c-42e5-94b4-9b8698d0734d@github.com>

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

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

  Reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16035/files
  - new: https://git.openjdk.org/jdk/pull/16035/files/415230bd..22d7e1a6

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

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

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

From jlu at openjdk.org  Wed Oct 11 21:20:48 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 11 Oct 2023 21:20:48 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v2]
In-Reply-To: <qQYvOMbIZTI23WLrlfxqDzdpD7CHa9gt72DwdV-c3OA=.2b47d72b-62ee-417a-95f4-a9aeccedd352@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 <qQYvOMbIZTI23WLrlfxqDzdpD7CHa9gt72DwdV-c3OA=.2b47d72b-62ee-417a-95f4-a9aeccedd352@github.com>
Message-ID: <YQCV8DULuqLcT9UhdffdlOYdSKv6bIp8bSQDeHwsTKk=.9440452c-87bc-4698-825a-6e9eada2bf7d@github.com>

On Mon, 9 Oct 2023 20:13:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflect review comments
>
> test/jdk/java/text/Format/NumberFormat/BigDecimalCompatibilityTest.java line 162:
> 
>> 160:         // Check parse and returned value
>> 161:         Number parsedValue = assertDoesNotThrow(()-> df.parse(longString),
>> 162:                 "Should not throw a ParseException");
> 
> It could catch any exception, so the message could be broader. Maybe just `a ParseException` -> `an Exception`.

Thank you for the review. I Adjusted the message, but clarified in the comment that the original intention was checking for a `ParseException`; fixed in the other instances as well.

> test/jdk/java/text/Format/NumberFormat/Bug4838107.java line 254:
> 
>> 252:                     "\n\tre-parsed number: " + parsed2 +
>> 253:                     "  (" + parsed2.getClass().getName() + ")" +
>> 254:                     "\n\tminus sign: " + df.getDecimalFormatSymbols().getMinusSign());
> 
> Could use text block to get rid of `\n`/`\t`s, with `.formatted()`. Same for the following one.

Adjusted.

> test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:
> 
>> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
>> 46: 
>> 47:         // i.e. "\u2019" as decimal separator, "\u2019" as grouping separator
> 
> This is incorrect (sorry, I am to be blamed as I wrote this ?). Should be "`\u002E` as decimal separator, " also remove `i.e.` if you move the comment on top of the variable declaration

Fixed.

> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:
> 
>> 60:     // currencySymbolsTest() is only ran for COMPAT
>> 61:     private static final boolean isCompat =
>> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));
> 
> This check could be moved into `currencySymbolsTest()`

I left it as a static declaration as although it is used in `currencySymbolsTest()`, it is also used in the data provider of `CurrencyFormatTest()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790743
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790850
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355790950
PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355791032

From naoto at openjdk.org  Wed Oct 11 22:02:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 22:02:17 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v2]
In-Reply-To: <qP1_9-A6QegVHDypCjc1j-7eQAXgnmXeQUW7UfBOrro=.b3fe86de-ed2c-42e5-94b4-9b8698d0734d@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 <qP1_9-A6QegVHDypCjc1j-7eQAXgnmXeQUW7UfBOrro=.b3fe86de-ed2c-42e5-94b4-9b8698d0734d@github.com>
Message-ID: <8SVCe1xbvTs9SNwhKnNgS_Sli6VJXIfS31qCXkaHUeU=.c427f4da-9436-4338-8efa-f6a30ba09c24@github.com>

On Wed, 11 Oct 2023 21:20:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
>> 
>> During the switch to JUnit, the tests had the following updates (to improve readability)
>> - separate the test data generation from the actual execution of the test
>> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect review comments

test/jdk/java/text/Format/NumberFormat/Bug8132125.java line 47:

> 45:         NumberFormat nf = NumberFormat.getInstance(deCH);
> 46: 
> 47:         // "\u2019" as decimal separator, "\u002E" as grouping separator

"\u002E" is decimal, "\u2019" is grouping.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355824830

From naoto at openjdk.org  Wed Oct 11 22:02:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 11 Oct 2023 22:02:19 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v2]
In-Reply-To: <YQCV8DULuqLcT9UhdffdlOYdSKv6bIp8bSQDeHwsTKk=.9440452c-87bc-4698-825a-6e9eada2bf7d@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 <qQYvOMbIZTI23WLrlfxqDzdpD7CHa9gt72DwdV-c3OA=.2b47d72b-62ee-417a-95f4-a9aeccedd352@github.com>
 <YQCV8DULuqLcT9UhdffdlOYdSKv6bIp8bSQDeHwsTKk=.9440452c-87bc-4698-825a-6e9eada2bf7d@github.com>
Message-ID: <Fk4La9s02KhiOyH4gN63RKGdgKL4GAdf14T4ydpomak=.9860d741-063d-4f8a-86d1-4c43dc0995c1@github.com>

On Wed, 11 Oct 2023 21:15:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/text/Format/NumberFormat/CurrencyFormat.java line 62:
>> 
>>> 60:     // currencySymbolsTest() is only ran for COMPAT
>>> 61:     private static final boolean isCompat =
>>> 62:             "COMPAT".equals(System.getProperty("java.locale.providers"));
>> 
>> This check could be moved into `currencySymbolsTest()`
>
> I left it as a static declaration as although it is used in `currencySymbolsTest()`, it is also used in the data provider of `CurrencyFormatTest()`.

Missed that. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16035#discussion_r1355821515

From job at kimmeringer.de  Thu Oct 12 08:58:27 2023
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Thu, 12 Oct 2023 10:58:27 +0200
Subject: <i18n dev> Date parsing issues with SimpleDateFormat and
 DateTimeFormatter
In-Reply-To: <f38fce97-b863-4e30-b9b8-982559130ddb@oracle.com>
References: <e61d8c07-e76b-8e69-9146-3c0db9b4e5cd@kimmeringer.de>
 <0882f1a4-dd5e-4f81-a2e1-ee46cddcfea7@oracle.com>
 <83369e05-7e52-fc46-31f3-7672a2c06a0f@kimmeringer.de>
 <f38fce97-b863-4e30-b9b8-982559130ddb@oracle.com>
Message-ID: <749effa1-e5b3-9ad2-c6c7-1f801a3f8392@kimmeringer.de>



Am 11.10.2023 um 20:23 schrieb Naoto Sato:

> I think the difference MMM and LLL does not matter here. As they both represent
> short months, either context or standalone. The fundamental issue whether the
> dot in the pattern is parsed as part of the month name, or the literal in the
> pattern is the same for both M/L.

I've looked up the meaning of stand alone by now and agree ;-) Again, I think
the examples in the Javadoc description should be extended to contain one
non-EN-based one to see the differences, e.g. here "settembre" (M) and
"Settembre" (L) for italian.

>> This time though it happened between an update of Java 11.0.14 to 11.0.20 that
>> the result of a date-parsing process produced different results (I assume due
>> to the non-derterministic nature of map.keySet but I stopped debugging that
>> road when "discovering" LLL).
> 
> This is interesting, as I expect no difference between update releases as
> CLDR version remains the same for both.

I wondered myself but the reason why I dug into the insides of these classes
at all was a user not being able to parse an Ebay Revenue-summary CSV where invoice
dates are of the form "12 Dez 2023" (i.e. german month names) and I weren't able
to reproduce that problem. That only changed after I've tried it with a more recent
version of Java 11.

>> For our particular application I've solved it by setting up a SimpleDateFormat,
>> get the abbreviated months with sdf.getShortMonths(), cut them down to three
>> characters and reset them using dfs.setShortMonths.
> 
> Thanks for letting us know the workaround. This kind of information helps our future work.

I'm not sure how because it's quite specific, but you're welcome ;-)

>> ??"23. Dez. 2016 11:12:13.456" with template "dd. LLL. yyyy HH:mm:ss.S"
>> ??and
>> ??"23. Dez. 2016 11:12:13.4" with template "dd. LLL. yyyy HH:mm:ss.SSS"
> 
> The default parsing mode is "strict" in DateTimeFormatter, so the number of digits in
> those nano seconds should match. You will need to build the formatter such that:
> 
> new DateTimeFormatterBuilder().parseLenient().appendPattern("S").toFormatter()
> 
> to accept 0 to 9 digits nanosecs without padding.

Why is it only strict with nano seconds? Other parts of the time are parsed
in a lenient way as well, i.e.

   assertEquals("check parsing of short month",
    "Sun Sep 03 01:02:03 CEST 2023",
    String.valueOf(parser.executeParser("03.09.2023 01:02:03", "d.M.y H:m:s", new Locale("en", "US"))));

pass. That's a bit inconsequential. ;-)


Thanks and best regards,

Lothar Kimmeringer

From jlu at openjdk.org  Thu Oct 12 20:58:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 12 Oct 2023 20:58:21 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v3]
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: <v5rw8chH3-3brcvUr_H9NIvNBxe1Naap7shWMBvKBko=.7862ceb8-9a27-41e9-90d0-a7c2d53863e7@github.com>

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

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

  Swap grouping and decimal separator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16035/files
  - new: https://git.openjdk.org/jdk/pull/16035/files/22d7e1a6..7c62b652

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

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

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

From naoto at openjdk.org  Thu Oct 12 21:54:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 12 Oct 2023 21:54:14 GMT
Subject: <i18n dev> RFR: JDK-8317372: Refactor some NumberFormat tests
 to use JUnit [v3]
In-Reply-To: <v5rw8chH3-3brcvUr_H9NIvNBxe1Naap7shWMBvKBko=.7862ceb8-9a27-41e9-90d0-a7c2d53863e7@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
 <v5rw8chH3-3brcvUr_H9NIvNBxe1Naap7shWMBvKBko=.7862ceb8-9a27-41e9-90d0-a7c2d53863e7@github.com>
Message-ID: <oYMqKTK2V-lk-mMn7I9LYHU0PzpFehy9vhgF8zCqrjU=.3b4c115b-13c8-4d58-97b4-37464ad36c6e@github.com>

On Thu, 12 Oct 2023 20:58:21 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
>> 
>> During the switch to JUnit, the tests had the following updates (to improve readability)
>> - separate the test data generation from the actual execution of the test
>> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Swap grouping and decimal separator

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16035#pullrequestreview-1675263956

From jlu at openjdk.org  Fri Oct 13 20:51:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 13 Oct 2023 20:51:59 GMT
Subject: <i18n dev> Integrated: JDK-8317372: Refactor some NumberFormat
 tests to use JUnit
In-Reply-To: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
References: <6HiGx4utmOYLXgO_1nyTmVjNYakZeMmIJ9aG6TN117A=.a0f008e4-7c71-4e7f-9506-4ab36595d075@github.com>
Message-ID: <sAN1aDvBCm8ItNnf7Yvo9LnmXZR7V1cHx8GWbvEMTFQ=.c5796287-abd5-4e5f-9d38-b235f8c1c903@github.com>

On Tue, 3 Oct 2023 22:23:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which refactors a number of tests under `test/text/NumberFormat` to use JUnit.
> 
> During the switch to JUnit, the tests had the following updates (to improve readability)
> - separate the test data generation from the actual execution of the test
> - create distinct test methods so that all the tests aren't just run under one big method (e.g. main)

This pull request has now been integrated.

Changeset: 9622de2a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9622de2aa89923b8444df093ae1c596bc336f14f
Stats:     943 lines in 9 files changed: 390 ins; 195 del; 358 mod

8317372: Refactor some NumberFormat tests to use JUnit

Reviewed-by: naoto

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

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

From jlaskey at openjdk.org  Mon Oct 16 13:50:58 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 13:50:58 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview)
Message-ID: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>

Update String Templates for a second preview. With the addition of

- Expression type and throws are determined from the `process` method of the processor type and not the processor type.

- Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .

- Raw (generic) process types are no longer an error.

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

Commit messages:
 - Accept qualified STR and RAW
 - String Templates (second preview)

Changes: https://git.openjdk.org/jdk/pull/16202/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16202&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315457
  Stats: 91 lines in 29 files changed: 29 ins; 30 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

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

From alanb at openjdk.org  Mon Oct 16 14:30:15 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Oct 2023 14:30:15 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview)
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

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

> 134:      * @param value       value to mix in
> 135:      * @return            new length and coder
> 136:      * @since 22

The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360750529

From jlaskey at openjdk.org  Mon Oct 16 14:35:37 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 14:35:37 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview)
In-Reply-To: <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
Message-ID: <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>

On Mon, 16 Oct 2023 14:27:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> src/java.base/share/classes/java/lang/StringConcatHelper.java line 136:
> 
>> 134:      * @param value       value to mix in
>> 135:      * @return            new length and coder
>> 136:      * @since 22
> 
> The @since will be bumped when the feature becomes permanent, no need to bump it for the second preview.

Wasn't sure about that. Thx.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360757078

From jlaskey at openjdk.org  Mon Oct 16 16:20:12 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:20:12 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v2]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

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

 - Revert source
 - Revert @since 22

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/b95c799e..f077ef6f

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

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

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

From jlahoda at openjdk.org  Mon Oct 16 16:20:24 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 16 Oct 2023 16:20:24 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v2]
In-Reply-To: <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
Message-ID: <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>

On Mon, 16 Oct 2023 15:23:25 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert source
>  - Revert @since 22

javac changes look reasonable to me. Added some mostly minor comments.

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

> 1689:         }
> 1690: 
> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {

This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

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

> 255: 
> 256:         boolean isNamedProcessor(Name name) {
> 257:             Symbol sym = switch (processor) {

Maybe `TreeInfo.symbol(processor)` here?

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

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1680264976
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360841404
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360830232

From jlaskey at openjdk.org  Mon Oct 16 16:54:13 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 16 Oct 2023 16:54:13 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v2]
In-Reply-To: <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
 <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
Message-ID: <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>

On Mon, 16 Oct 2023 15:17:10 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert source
>>  - Revert @since 22
>
> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
> 
>> 1689:         }
>> 1690: 
>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
> 
> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.

I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me.

> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/TransLiterals.java line 257:
> 
>> 255: 
>> 256:         boolean isNamedProcessor(Name name) {
>> 257:             Symbol sym = switch (processor) {
> 
> Maybe `TreeInfo.symbol(processor)` here?

Only want to allow JCIdent and and JCFieldAcesss. Other expressions can't produce the STR/RAW symbols, but ...

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360965274
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1360962420

From naoto at openjdk.org  Mon Oct 16 20:14:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Oct 2023 20:14:08 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in the
 CLDR locale provider
Message-ID: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>

CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

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

Commit messages:
 - tidy up
 - substitute letters
 - initial commit

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

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

From duke at openjdk.org  Mon Oct 16 20:54:29 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 16 Oct 2023 20:54:29 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v2]
In-Reply-To: <gXavGMmsf0MJblzwBN705alqCUQ6mIzibqyGxj-BmJo=.440defe6-b23e-4cee-a6cf-a71388064a1a@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <gZPPu_aZM1nMEXbeuSmbablNeTzdEzWn8D0jO-IqKig=.25f5836a-26d1-4601-974b-413ad1afe284@github.com>
 <gXavGMmsf0MJblzwBN705alqCUQ6mIzibqyGxj-BmJo=.440defe6-b23e-4cee-a6cf-a71388064a1a@github.com>
Message-ID: <N95tFLeWP7LyZY_-ht5hDEwwR7b8YUrFC797XoiPMuQ=.70b1c491-b957-4b8f-8168-268e0376fae7@github.com>

On Mon, 16 Oct 2023 20:36:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   No longer localize printed numbers
>
> test/jdk/java/util/Formatter/BasicDateTime.java line 473:
> 
>> 471:                 Locale.forLanguageTag("th-TH-u-nu-thai"));
>> 472:         test("%tF", "2023-01-13", LocalDate.of(2023, 1, 13));
>> 473:         Locale.setDefault(locale);
> 
> This is an incompatible change. If you intend to change the behavior, this should be approved in the CSR.

Yes, the incompatibility information described in the CSR above also covers this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1361250989

From naoto at openjdk.org  Mon Oct 16 23:37:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Oct 2023 23:37:51 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v2]
In-Reply-To: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
Message-ID: <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

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

  Use ZoneOffset to parse offset

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/d38c58a5..3d221558

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

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

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

From rriggs at openjdk.org  Tue Oct 17 02:05:25 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 02:05:25 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v2]
In-Reply-To: <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>
Message-ID: <Qa8-6r1xllL5FO0j4d9bC0RXCzfvErQMsngXTM9xBx4=.e921a8b2-2546-4035-8d5a-6c9bb842cf63@github.com>

On Mon, 16 Oct 2023 23:37:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ZoneOffset to parse offset

Looks fine.
(I can't help thinking that some of this pre-processing would be easier to maintain with a bit more formal parsing and creating of records for the data in these files; but that's for another time.)

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1294:

> 1292:             .map(Path::toFile)
> 1293:             .filter(File::isFile)
> 1294:             .forEach(f -> {

I'd keep the Path going through the stream to avoid converting and then back again.
Suggestion:

            .filter(p -> p.toFile().isFile())
            .forEach(p -> {

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1681188045
PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1361419853

From joehw at openjdk.org  Tue Oct 17 04:15:25 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 17 Oct 2023 04:15:25 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v2]
In-Reply-To: <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>
Message-ID: <5r77kjlNZnAkNk9Qrf7efBx9cSbhkdNb6Qj_lT5NGpM=.c52d8342-3674-43e2-b274-408cc93700ea@github.com>

On Mon, 16 Oct 2023 23:37:51 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ZoneOffset to parse offset

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1681329184

From lkorinth at openjdk.org  Tue Oct 17 12:29:46 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 17 Oct 2023 12:29:46 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:

 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/27da7150..44af07b9

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

  Stats: 1102 lines in 462 files changed: 11 ins; 22 del; 1069 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From jlaskey at openjdk.org  Tue Oct 17 16:03:25 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:25 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v3]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

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

  Cache process method type in JCStringTemplate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/f077ef6f..ae136779

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

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

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

From jlaskey at openjdk.org  Tue Oct 17 16:03:28 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 17 Oct 2023 16:03:28 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v2]
In-Reply-To: <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <PMao0IZpedwBOyguZOrDU2JIYslHM2QW_IvZ0USpcm0=.b697c9e0-5c2e-4cfc-9e2c-142b10619623@github.com>
 <rtrlUDepGioggbx_mf87XfIhx7IQtd1psaivJxONp50=.7132a20b-7bc5-4de4-ae80-9830f8e84e50@github.com>
 <zdgstS8vpSrxnnWMelorZ6DEwBN9tCp_kBF-u3ymbtk=.c68dc6d2-72b3-4226-94bb-26fcfa3cc0f1@github.com>
Message-ID: <iSGDWs1Cgbn-orD9wgZLzDRddsoDymA_4DOz7AL8-Gw=.21ad6946-b19b-4bea-96b3-044ee1c1a121@github.com>

On Mon, 16 Oct 2023 16:51:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> src/jdk.compiler/share/classes/com/sun/tools/javac/comp/Flow.java line 1691:
>> 
>>> 1689:         }
>>> 1690: 
>>> 1691:         private Type getProcessMethodType(JCStringTemplate tree, Type processorType) {
>> 
>> This method is basically the same as in `Attr`, correct? I wonder if there's a way to avoid the duplication? One possibility would be to compute the type in `Attr`, and store it in a field on `JCStringTemplate`, and just use it in `Flow`. Alternatively, it could be shared in some class, although only `TreeInfo` and `Resolve` come to mind, and neither seem particularly suitable for that.
>
> I thought of the TreeInfo and Resolve idea but the number of arguments required made it messy. Hanging off of JCStringTemplate seemed like clutter to me. If I could use the method symbol in TransLiterals it might make sense. I'll ponder on it.

Added

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1362377976

From naoto at openjdk.org  Tue Oct 17 16:52:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 16:52:12 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
Message-ID: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

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

  Delay populating GMT format at runtime. Reflecting review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/3d221558..4559203d

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

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

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

From naoto at openjdk.org  Tue Oct 17 16:53:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 16:53:41 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v2]
In-Reply-To: <Qa8-6r1xllL5FO0j4d9bC0RXCzfvErQMsngXTM9xBx4=.e921a8b2-2546-4035-8d5a-6c9bb842cf63@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <Oul8x2ivEVZNm0Cdds72deqeh6PAN_r5hkCb2J38j4k=.b8488116-4e13-4b97-9d02-57011e2d59ab@github.com>
 <Qa8-6r1xllL5FO0j4d9bC0RXCzfvErQMsngXTM9xBx4=.e921a8b2-2546-4035-8d5a-6c9bb842cf63@github.com>
Message-ID: <9aZ-oyXU5G9Ya7mq0J9X_oPER9a25nm_SuJd-qrNFBE=.fadeb8f7-9da2-4931-9504-3f86862004bc@github.com>

On Tue, 17 Oct 2023 02:03:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use ZoneOffset to parse offset
>
> Looks fine.
> (I can't help thinking that some of this pre-processing would be easier to maintain with a bit more formal parsing and creating of records for the data in these files; but that's for another time.)

Thanks for the reviews, @RogerRiggs @JoeWang-Java . I now realized that the pre-filling of GMT format in the CLDR resource would prevent COMPAT from populating its short names (as it does today), so I changed the fix not to pre-fill GMT short names. Once COMPAT is gone in the future, this workaround needs to be revisited.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1766806066

From joehw at openjdk.org  Tue Oct 17 19:50:45 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 17 Oct 2023 19:50:45 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <2kt6xqbf9RkKp2vEmzoBJHntKtH66Gd5-F4U6mmzhFo=.580d4b70-e302-4958-b1ca-4a8d79ceeba6@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by joehw (Reviewer).

Thanks Naoto for the update. Sounds like a good plan to me.

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683235181
PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767061468

From lancea at openjdk.org  Tue Oct 17 19:57:47 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 17 Oct 2023 19:57:47 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <lyqn6kEOTTR9bKNhnjyvFc07nyHL8O198Soc8UhOxPI=.b741a6d3-e4d8-4f5d-bb05-0a506ce53f76@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683251272

From erikj at openjdk.org  Tue Oct 17 20:04:42 2023
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 17 Oct 2023 20:04:42 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <D8zK2my7M03Y2Z9z0bz7mWWHyFPMA3jxS1C066x2_i4=.80bff7a8-1121-4078-94c7-38ee907d931a@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Build change looks good.

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683266663

From jlu at openjdk.org  Tue Oct 17 20:14:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Oct 2023 20:14:14 GMT
Subject: <i18n dev> RFR: 8318322: Update IANA Language Subtag Registry to
 Version 2023-10-16
Message-ID: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>

This change updates the IANA subtag registry to the update released on 2023-10-16.

Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

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

Commit messages:
 - init

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

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

From iris at openjdk.org  Tue Oct 17 20:14:47 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 17 Oct 2023 20:14:47 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <Ak7y7eqk9lhObQMdAuYPVLj_t5IZOKThrYYwlVPdORk=.90cf2047-0f37-4ade-b7d0-13acee99de79@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683283733

From rriggs at openjdk.org  Tue Oct 17 21:35:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Oct 2023 21:35:10 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <z1NqYwYT6Ppn2oKvlkkOP8Z9uWHogCNZPYfughHQMjs=.f11560a9-de1d-463c-afa0-de6c63456ad8@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1683418583

From srl at openjdk.org  Tue Oct 17 21:48:55 2023
From: srl at openjdk.org (Steven Loomis)
Date: Tue, 17 Oct 2023 21:48:55 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <nH7ofyQ38yMyUecZyTZC-LNsF9iHW_oJ_4K5U1e5i4A=.7d90b5d4-9706-4b1e-a742-b289dd6208f1@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format. To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

This is intentional, because these short names may not be known to users.  Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`?   This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short. 

I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names.   In fact, CLDR probably has _too many_ short names for zones.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767240212

From naoto at openjdk.org  Tue Oct 17 22:19:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 22:19:08 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <nH7ofyQ38yMyUecZyTZC-LNsF9iHW_oJ_4K5U1e5i4A=.7d90b5d4-9706-4b1e-a742-b289dd6208f1@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
 <nH7ofyQ38yMyUecZyTZC-LNsF9iHW_oJ_4K5U1e5i4A=.7d90b5d4-9706-4b1e-a742-b289dd6208f1@github.com>
Message-ID: <iwYAS3xIoItnSEEFxalDWPWZIeZoi-VWU9t3mSWRUYE=.17b1c78b-88d4-4a71-ab0a-f8c8d21f1654@github.com>

On Tue, 17 Oct 2023 21:45:57 GMT, Steven Loomis <srl at openjdk.org> wrote:

> > CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format. To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
> 
> I added a note to [JDK-8317979](https://bugs.openjdk.org/browse/JDK-8317979):
> 
> This is intentional, because these short names may not be known to users. Do you have data that ja-JP, zh-CN, de-DE users expect and are familiar with `PST/PDT`? This is why CLDR fallback rules would fall back to `Los Angeles Time` for example in the longer name. It's not short, but it's understandable, and the numeric offset can work for short.

Yes, I am saying not having short names is not a bad thing, or rather better than making up uncommon names among those locals (which COMPAT is doing). GMT offset style is totally acceptable in such cases IMO. In fact, TZ database is getting away from using old three-letter short names.

> I'd encourage engaging with CLDR-TC to discuss the short names upstream if you have data on the recognizability of these short names. In fact, CLDR probably has _too many_ short names for zones.

No, I don't have any data on this. At least I can say that there are no short names for those in Japanese.

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

PR Comment: https://git.openjdk.org/jdk/pull/16206#issuecomment-1767274871

From naoto at openjdk.org  Tue Oct 17 23:48:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Oct 2023 23:48:46 GMT
Subject: <i18n dev> RFR: 8318322: Update IANA Language Subtag Registry
 to Version 2023-10-16
In-Reply-To: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
References: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
Message-ID: <Fij0fE2IXVAFWJMoYJz7YSim-3loGDHUINxNoSDuud8=.e855cd45-c78f-4033-a481-6e74c3d7959a@github.com>

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1683655344

From iris at openjdk.org  Wed Oct 18 05:36:43 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Oct 2023 05:36:43 GMT
Subject: <i18n dev> RFR: 8318322: Update IANA Language Subtag Registry
 to Version 2023-10-16
In-Reply-To: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
References: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
Message-ID: <jOul_Vx0zff_L42KaRSV1Z7vMxzPi0PerYlViNuQpTk=.20a793cd-1009-4451-8065-d2b095abbbc0@github.com>

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1684058244

From ihse at openjdk.org  Wed Oct 18 15:16:00 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Oct 2023 15:16:00 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
Message-ID: <EXGLeKI4KBASaMpEZ79XTTiLXzPl1bA0Bo9-lRcIfiM=.ffe44ba0-6078-4929-a5ce-e82d344dfaf9@github.com>

On Tue, 17 Oct 2023 16:52:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Delay populating GMT format at runtime. Reflecting review comments.

make/modules/jdk.localedata/Gensrc.gmk line 39:

> 37: GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata
> 38: CLDR_GEN_DONE := $(GENSRC_DIR)/_cldr-gensrc.marker
> 39: TZ_DATA_DIR := $(MODULE_SRC)/../java.base/share/data/tzdata

This seems like a bit of abuse of `$(MODULE_SRC)`. I thought we had a macro to get the proper source path for another module, but if we do, I cannot find it now.

If you feel up for it, I'd encourage you to change this to:

Suggestion:

TZ_DATA_DIR := $(call FindModuleSrc, java.base)/share/data/tzdata


and add 

################################################################################
# Find source dir for module
# Param 1 - module name
FindModuleSrc = \
    $(TOPDIR)/src/$(strip $1)

at a suitable place in `Utils.gmk`.

Otherwise, just replace it with:


TZ_DATA_DIR :=  $(TOPDIR)/src/java.base/share/data/tzdata

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1364065717

From lancea at openjdk.org  Wed Oct 18 15:20:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Oct 2023 15:20:59 GMT
Subject: <i18n dev> RFR: 8318322: Update IANA Language Subtag Registry
 to Version 2023-10-16
In-Reply-To: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
References: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
Message-ID: <Ei8uZnkRbqVEFbwYX0bSBR9kFzjS2tLnrOLgTvEWF50=.e12cb0a3-930c-4cc3-9ba5-9ff26ae3fafa@github.com>

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1685391866

From naoto at openjdk.org  Wed Oct 18 15:43:12 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 15:43:12 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v4]
In-Reply-To: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
Message-ID: <lmeM9_DEeThccSvZdvUHoZQQHh_0xEIpSu4McJBeV9Q=.7e389b1d-deec-42e5-aefb-ad7548549d1b@github.com>

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

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

  Fix makefile for the tz data path

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16206/files
  - new: https://git.openjdk.org/jdk/pull/16206/files/4559203d..3d6f695d

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

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

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

From naoto at openjdk.org  Wed Oct 18 15:43:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 15:43:14 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v3]
In-Reply-To: <EXGLeKI4KBASaMpEZ79XTTiLXzPl1bA0Bo9-lRcIfiM=.ffe44ba0-6078-4929-a5ce-e82d344dfaf9@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <OvAXpnl9NRFAhIwXh-o5LFOTeRoMjMV2MDkigVmqubI=.26d40094-637a-41ac-9a51-80bc4b46912a@github.com>
 <EXGLeKI4KBASaMpEZ79XTTiLXzPl1bA0Bo9-lRcIfiM=.ffe44ba0-6078-4929-a5ce-e82d344dfaf9@github.com>
Message-ID: <CHt305E3uaBBzy8FuUJdIrzUYmhP4MWqLU8y9dfxuW4=.4512692a-c81a-41f9-aa00-af172d606ef6@github.com>

On Wed, 18 Oct 2023 15:13:14 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Delay populating GMT format at runtime. Reflecting review comments.
>
> make/modules/jdk.localedata/Gensrc.gmk line 39:
> 
>> 37: GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata
>> 38: CLDR_GEN_DONE := $(GENSRC_DIR)/_cldr-gensrc.marker
>> 39: TZ_DATA_DIR := $(MODULE_SRC)/../java.base/share/data/tzdata
> 
> This seems like a bit of abuse of `$(MODULE_SRC)`. I thought we had a macro to get the proper source path for another module, but if we do, I cannot find it now.
> 
> If you feel up for it, I'd encourage you to change this to:
> 
> Suggestion:
> 
> TZ_DATA_DIR := $(call FindModuleSrc, java.base)/share/data/tzdata
> 
> 
> and add 
> 
> ################################################################################
> # Find source dir for module
> # Param 1 - module name
> FindModuleSrc = \
>     $(TOPDIR)/src/$(strip $1)
> 
> at a suitable place in `Utils.gmk`.
> 
> Otherwise, just replace it with:
> 
> 
> TZ_DATA_DIR :=  $(TOPDIR)/src/java.base/share/data/tzdata

Thanks, Magnus. In fact, I was wondering if I should move back tzdata into make as it is shared like cldr, but it would revert the work you did before, so I ended up traversing the directory structure. Fixed with the latter suggestion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16206#discussion_r1364102062

From srl at openjdk.org  Wed Oct 18 16:01:02 2023
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 18 Oct 2023 16:01:02 GMT
Subject: <i18n dev> RFR: 8318322: Update IANA Language Subtag Registry
 to Version 2023-10-16
In-Reply-To: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
References: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
Message-ID: <oRo57tZsakMiXwrE_LSxCGntSS0a9uDLyDA6QwiaQfo=.9b408277-51b6-4830-9f94-352d1c4b0769@github.com>

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

Marked as reviewed by srl (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16227#pullrequestreview-1685483927

From ihse at openjdk.org  Wed Oct 18 18:01:43 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 18 Oct 2023 18:01:43 GMT
Subject: <i18n dev> RFR: 8317979: Use TZ database style abbreviations in
 the CLDR locale provider [v4]
In-Reply-To: <lmeM9_DEeThccSvZdvUHoZQQHh_0xEIpSu4McJBeV9Q=.7e389b1d-deec-42e5-aefb-ad7548549d1b@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
 <lmeM9_DEeThccSvZdvUHoZQQHh_0xEIpSu4McJBeV9Q=.7e389b1d-deec-42e5-aefb-ad7548549d1b@github.com>
Message-ID: <ESpFhd_GGCJlKgS9p1HfB3Ueevyz_gJCbNgw1cWNEQk=.b7b12246-f206-4184-afd5-2fdf45b62568@github.com>

On Wed, 18 Oct 2023 15:43:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
>> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix makefile for the tz data path

Build changes look good now

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16206#pullrequestreview-1685776520

From naoto at openjdk.org  Wed Oct 18 18:29:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Oct 2023 18:29:43 GMT
Subject: <i18n dev> Integrated: 8317979: Use TZ database style abbreviations
 in the CLDR locale provider
In-Reply-To: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
References: <U-zlJnigV8YhwGYnx5MNEDdExS1Fai_jfsFmYCyjmBs=.3f67b898-e05a-4c98-a255-0529bec9c337@github.com>
Message-ID: <j3WpiQHAw5k0pe-5VZqFqB6wLugrkE06qYVgJbLnQ80=.64bd72b2-3746-4bc3-8659-1b5baf1bd455@github.com>

On Mon, 16 Oct 2023 19:57:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> CLDR provides very few short names for time zones, such as PST/PDT. This will typically end up substituting names from the COMPAT provider. Once the COMPAT is removed, they will be displayed in the GMT format, i.e., GMT+XX:YY. Although some of the short names in the COMPAT provider are somewhat questionable (less common ones are simply made up from the long names by taking the initials), it would not be desirable for them to fall back to the GMT format.
> To mitigate the situation, CLDR can use the abbreviated names from the TZ database, which contains legacy (major) short names as FORMAT. The CLDR provider can use them instead of the GMT offset style. This enhancement is a precursor to the future removal of the COMPAT provider.

This pull request has now been integrated.

Changeset: ce8ebebc
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce8ebebc77f4ef73852364f6188b43c482337350
Stats:     161 lines in 6 files changed: 138 ins; 1 del; 22 mod

8317979: Use TZ database style abbreviations in the CLDR locale provider

Reviewed-by: rriggs, joehw, lancea, erikj, iris, ihse

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

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

From lkorinth at openjdk.org  Thu Oct 19 15:16:13 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:13 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:

 - Batch update using sed
   
   find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
   find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
 - Merge branch '_master_jdk' into _8315097
 - explain usage
 - Revert "8315097: Rename createJavaProcessBuilder"
   
   This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
 - Revert "copyright"
   
   This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
 - Revert "fix static import"
   
   This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
 - fix static import
 - copyright
 - 8315097: Rename createJavaProcessBuilder

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

Changes: https://git.openjdk.org/jdk/pull/15452/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15452&range=04
  Stats: 894 lines in 560 files changed: 34 ins; 10 del; 850 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Thu Oct 19 15:16:42 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 19 Oct 2023 15:16:42 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v4]
In-Reply-To: <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <4pRda3ZAZzVzGiVrDv6LN9Pw__DhrmTm4qZjTHzaq80=.a009bb29-4869-4047-8b62-80fbe7bef692@github.com>
Message-ID: <3XTw5IAFj_YpaMrqyLdO9mNbWDENFMVkwk8JBmKHDcE=.5e4b1c70-0b36-4ff5-9cce-ee4f25a8e3bb@github.com>

On Tue, 17 Oct 2023 12:29:46 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.

If this looks roughly acceptable, I will manually add indentation spaces. I am now running tests.

The changes can be verified by running the following commands:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9 

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"

git diff HEAD f80dda8d7109c2ef6bc1f685d0b611704dec645e


Only the documentation changes should be visible.  When I have manually indented everything it should be easy to that verify that change as a whitespace-only change. But that is for tomorrow (at best).

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1771194189

From jlu at openjdk.org  Thu Oct 19 18:30:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 18:30:31 GMT
Subject: <i18n dev> Integrated: 8318322: Update IANA Language Subtag
 Registry to Version 2023-10-16
In-Reply-To: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
References: <lgqImE64cn45V-Hjwivw9m8NZDVipRlQOriTQSMmvso=.457db46e-a39c-4ff6-bb4a-0268a1c51c3b@github.com>
Message-ID: <FTpLCRY6JBLDqOjbbz6ot80HwZLlBx_dJAcGxQ31SYU=.fb868644-cc1b-42ee-8557-a3022c7599b8@github.com>

On Tue, 17 Oct 2023 20:06:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This change updates the IANA subtag registry to the update released on 2023-10-16.
> 
> Announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2023-October/000089.html

This pull request has now been integrated.

Changeset: cc8f8da2
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc8f8da293914c25cb15d38caad994bc761a3957
Stats:     53 lines in 2 files changed: 50 ins; 0 del; 3 mod

8318322: Update IANA Language Subtag Registry to Version 2023-10-16

Reviewed-by: naoto, iris, lancea, srl

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

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

From jlu at openjdk.org  Thu Oct 19 21:44:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 21:44:33 GMT
Subject: <i18n dev> RFR: JDK-7061097: [Doc] Inconsistenency between the spec
 and the implementation for DateFormat.Field
Message-ID: <BQykqDpSSnglxA74lVKb160mz4xuWTI-xNLGHf2tk8Q=.a7c4e105-4a56-431b-9cf0-cdb89bf017e3@github.com>

Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.

`getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.

Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.

The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

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

Commit messages:
 - this implementation -> the default implementation
 - init

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

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

From jlu at openjdk.org  Thu Oct 19 22:55:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Oct 2023 22:55:42 GMT
Subject: <i18n dev> Integrated: JDK-8315064: j.text.ChoiceFormat provides no
 specification on quoting behavior
In-Reply-To: <de9zHai6-4m_2GW1JMuHA_vdmaSlXQQMfLz1N0bOHo4=.8ca7599d-63e8-43e8-b840-c50ea41b418d@github.com>
References: <de9zHai6-4m_2GW1JMuHA_vdmaSlXQQMfLz1N0bOHo4=.8ca7599d-63e8-43e8-b840-c50ea41b418d@github.com>
Message-ID: <qR1v1y6bvUJtjDlBHRLPrc9gpBMsQI8hnEagXnU3aJk=.840e5c43-2eca-4e4b-9176-789ad095a50d@github.com>

On Fri, 29 Sep 2023 20:46:44 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and which adjusts the pattern section of java.text.ChoiceFormat to specify the single quote behavior within a String pattern.
> 
> The other Format classes that take a String pattern such as DecimalFormat, CompactNumberFormat, and MessageFormat all provide specification on single quote behavior within a String pattern. ChoiceFormat should have similar specification.

This pull request has now been integrated.

Changeset: 684b91ef
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/684b91efbb22f16cd0952283e8c960846c39d1db
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8315064: j.text.ChoiceFormat provides no specification on quoting behavior

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Thu Oct 19 23:01:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 19 Oct 2023 23:01:27 GMT
Subject: <i18n dev> RFR: JDK-7061097: [Doc] Inconsistenency between the
 spec and the implementation for DateFormat.Field
In-Reply-To: <BQykqDpSSnglxA74lVKb160mz4xuWTI-xNLGHf2tk8Q=.a7c4e105-4a56-431b-9cf0-cdb89bf017e3@github.com>
References: <BQykqDpSSnglxA74lVKb160mz4xuWTI-xNLGHf2tk8Q=.a7c4e105-4a56-431b-9cf0-cdb89bf017e3@github.com>
Message-ID: <cJiK9Ypi5DMLVpOSegJRBddemjXl4KTIYZIbwUD5eag=.0a15f982-baae-47c1-8565-97a874fd4df7@github.com>

On Thu, 19 Oct 2023 21:31:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.
> 
> `getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.
> 
> Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.
> 
> The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16279#pullrequestreview-1688819904

From lkorinth at openjdk.org  Fri Oct 20 08:34:35 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 20 Oct 2023 08:34:35 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v5]
In-Reply-To: <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <uC0TE90D-q3e-Zj64YAyow9DkIridnaRbzlXi0zmr2Q=.b32622c2-fdc3-4fd9-862c-cc9f934dbfe2@github.com>
Message-ID: <CQLu4BqqXQpv1m-Z4mKvfK890bjfytSkMMBunchwlmc=.95e9f73e-0275-4dcf-bdbb-707ce50c4902@github.com>

On Thu, 19 Oct 2023 15:16:13 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains ten commits:
> 
>  - Batch update using sed
>    
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createJavaTestProcessBuilder(/g"
>    find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedJavaTestProcessBuilder/g"
>  - Merge branch '_master_jdk' into _8315097
>  - explain usage
>  - Revert "8315097: Rename createJavaProcessBuilder"
>    
>    This reverts commit 4b2d171133c40c5c48114602bfd0d4da75531317.
>  - Revert "copyright"
>    
>    This reverts commit f3418c80cc0d4cbb722ee5e368f1a001e898b43e.
>  - Revert "fix static import"
>    
>    This reverts commit 27da71508aec9a4bec1c0ad07031887286580171.
>  - fix static import
>  - copyright
>  - 8315097: Rename createJavaProcessBuilder

Just ignore what I just pushed, I will have a new version out

sorry...

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309579
PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1772309992

From jlu at openjdk.org  Fri Oct 20 17:40:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Oct 2023 17:40:43 GMT
Subject: <i18n dev> Integrated: JDK-7061097: [Doc] Inconsistenency between
 the spec and the implementation for DateFormat.Field
In-Reply-To: <BQykqDpSSnglxA74lVKb160mz4xuWTI-xNLGHf2tk8Q=.a7c4e105-4a56-431b-9cf0-cdb89bf017e3@github.com>
References: <BQykqDpSSnglxA74lVKb160mz4xuWTI-xNLGHf2tk8Q=.a7c4e105-4a56-431b-9cf0-cdb89bf017e3@github.com>
Message-ID: <4Gv7scNRzPIXmvWkj7cjaK8Ual2fWSroDEe_ngdorHQ=.2c59334b-6515-4c65-b0fb-a3a20bf5dde5@github.com>

On Thu, 19 Oct 2023 21:31:13 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adjusts the specification of `DateFormat.Field::getCalendarField` to conform to the implementation.
> 
> `getCalendarField()` claims that it will return -1 if there is no corresponding `Calendar` constant.
> 
> Although the built-in DateFormat.Fields with no associated `Calendar` constant are created with a `calendarField` equal to -1, a subclass can create a DateFormat.Field with no associated `Calendar` constant with `calendarField` equal to anything.
> 
> The specification of `getCalendarField()` should be adjusted to reflect this. That is, a separate implementation may or may not return -1 if there is no associated `Calendar` constant.

This pull request has now been integrated.

Changeset: 4dfa3799
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4dfa3799a60cb11092b699db5bc0cc1f44d24484
Stats:     6 lines in 1 file changed: 3 ins; 0 del; 3 mod

7061097: [Doc] Inconsistenency between the spec and the implementation for DateFormat.Field

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Fri Oct 20 18:03:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 20 Oct 2023 18:03:53 GMT
Subject: <i18n dev> RFR: 8318569: Add getter methods for Locale and Patterns
 in ListFormat
Message-ID: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>

Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

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

Commit messages:
 - Simplified the method spec
 - initial commit

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

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

From joehw at openjdk.org  Fri Oct 20 20:54:37 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 20 Oct 2023 20:54:37 GMT
Subject: <i18n dev> RFR: 8318569: Add getter methods for Locale and
 Patterns in ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: <H1RQJwj4Hj-P2eFaNo_YPegynhBN_6SI_w3N_GoF3kg=.47c1304a-82d5-45f8-961e-ad5f9b034252@github.com>

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Looks good to me.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690887480

From rriggs at openjdk.org  Fri Oct 20 21:20:26 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Oct 2023 21:20:26 GMT
Subject: <i18n dev> RFR: 8318569: Add getter methods for Locale and
 Patterns in ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: <hy7mmUVfe3vP2m--Xs6eH_qg6qLN9dUxNcpDZccGivU=.0f11c5a5-5691-4b55-8550-11b6a1349447@github.com>

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690913429

From iris at openjdk.org  Fri Oct 20 21:25:35 2023
From: iris at openjdk.org (Iris Clark)
Date: Fri, 20 Oct 2023 21:25:35 GMT
Subject: <i18n dev> RFR: 8318569: Add getter methods for Locale and
 Patterns in ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: <yv6Q9bM0Hd2kX6URuXsase2GFiMzT1rp3MdC114GQCE=.646243ce-f6b1-409b-9c20-bb29d5f2cb64@github.com>

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

Corresponding CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1690917007

From mli at openjdk.org  Sun Oct 22 11:40:41 2023
From: mli at openjdk.org (Hamlin Li)
Date: Sun, 22 Oct 2023 11:40:41 GMT
Subject: <i18n dev> RFR: 8318569: Add getter methods for Locale and
 Patterns in ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: <mP8If3vBFXP6Qe0nMunZdwKUetqpxP6pM7Ne_zqagkk=.a12a5b3a-717d-41d2-8c51-51eb4f36fd81@github.com>

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

LGTM

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16293#pullrequestreview-1691418437

From jlu at openjdk.org  Mon Oct 23 17:22:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Oct 2023 17:22:45 GMT
Subject: <i18n dev> RFR: 8318186: ChoiceFormat inconsistency between
 applyPattern() and setChoices()
Message-ID: <tfp-FCQu7xes8ScMt5VyxE_xuiN-ojseinMPlIRU0Tk=.f3f0be5c-ecab-4a22-8d88-1341b0639ab6@github.com>

Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.

A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

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

Commit messages:
 - change from impl spec to API spec
 - init

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

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

From naoto at openjdk.org  Mon Oct 23 18:04:28 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 18:04:28 GMT
Subject: <i18n dev> RFR: 8318186: ChoiceFormat inconsistency between
 applyPattern() and setChoices()
In-Reply-To: <tfp-FCQu7xes8ScMt5VyxE_xuiN-ojseinMPlIRU0Tk=.f3f0be5c-ecab-4a22-8d88-1341b0639ab6@github.com>
References: <tfp-FCQu7xes8ScMt5VyxE_xuiN-ojseinMPlIRU0Tk=.f3f0be5c-ecab-4a22-8d88-1341b0639ab6@github.com>
Message-ID: <N4-Hb8AW0_uu2yiQ4bS6MfzeC1BfjDybzoGd7OFKj_8=.d2174286-6a67-40a2-a827-22734716400a@github.com>

On Mon, 23 Oct 2023 17:16:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.
> 
> A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16317#pullrequestreview-1693182794

From naoto at openjdk.org  Mon Oct 23 18:46:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Oct 2023 18:46:46 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the ListFormat.equals()
 method can be improved
Message-ID: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>

Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

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

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

Commit messages:
 - Fixing typo
 - Removed redundant wording
 - initial commit

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

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

From darcy at openjdk.org  Tue Oct 24 04:34:29 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 24 Oct 2023 04:34:29 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v2]
In-Reply-To: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
Message-ID: <-mPIn7ApH5XYSRKZmnjXS8GO0MAkBpgPsBxpwpKDvQk=.a5e70ba4-22d9-4000-87f2-16ad9d9d2237@github.com>

On Fri, 6 Oct 2023 18:07:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
>> 
>> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tag setChoices as well

I assume this issue was filed (directly or indirectly) in response to the javac lint warning added in JDK 21 under JDK-8015831.

I recommend considering how to address the underlying issue of the constructors calling overridable methods. For example, can a private method be defined that is called from the constructor and the public method?

In any case, I think one goal of bug should be to remove the warning condition, preferably by removing the condition, but, if not, by adding a `@SuppressedException((this-escape")`.

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

PR Comment: https://git.openjdk.org/jdk/pull/16064#issuecomment-1776523348

From lkorinth at openjdk.org  Tue Oct 24 07:49:30 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 07:49:30 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>

> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
> 
> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
> 
> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
> 
>    /**
>      * Create ProcessBuilder using the java launcher from the jdk to
>      * be tested.
>      *
>      * <p><b> Please observe that you likely should use
>      * createTestJvm() instead of this method because createTestJvm()
>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>      * </b> and this method will not do that.
>      *
>      * @param command Arguments to pass to the java command.
>      * @return The ProcessBuilder instance representing the java command.
>      */
> 
> 
> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
> 
> I have run tier 1 testing, and I have started more exhaustive testing.

Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:

 - static import
 - copyright
 - whitespace
 - whitespace
 - sed
 - fix test/lib/jdk/test/lib/process/ProcessTools.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/f80dda8d..2f57a32d

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

  Stats: 1580 lines in 560 files changed: 44 ins; 34 del; 1502 mod
  Patch: https://git.openjdk.org/jdk/pull/15452.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15452/head:pull/15452

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

From lkorinth at openjdk.org  Tue Oct 24 09:10:43 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Tue, 24 Oct 2023 09:10:43 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <U_NEwp1RAk4Dq_2OXmgi4TOR6vYQF9IVj-PU6X7-h-M=.8ee4eda5-7d48-44d7-b896-3237fae1620d@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Hi, if you want to see what I have modified manually, you can do my sed commands and compare to this pull request:

git switch -c _reproduce 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9

find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createLimitedTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/createTestJvm(/createTestJavaProcessBuilder(/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createJavaProcessBuilder/import static jdk.test.lib.process.ProcessTools.createLimitedTestJavaProcessBuilder/g"
find -name "*.java" | xargs -n 1 sed -i -e "s/import static jdk.test.lib.process.ProcessTools.createTestJvm/import static jdk.test.lib.process.ProcessTools.createTestJavaProcessBuilder/g"
git add -u; git commit -m sed

git diff-tree --no-commit-id --name-only -r 15acf4b8d7cffcd0d74bf1b9c43cde9acaf31ea9..HEAD | xargs sed -i -e "s%^( * Copyright (c) ....)[^[:alpha:]]*(Oracle.*)%\1, 2023, \2%"
git ls-files -m | xargs sed -i -e "s%(Copyright (c) 2023), 2023, (Oracle.*)%\1, \2%"
git add -u; git commit -m copyright

git diff HEAD 2f57a32df8d17da51a04177563327ca2a75e8061


It will give you an easier way to review.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1776817287

From stefank at openjdk.org  Tue Oct 24 09:51:39 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Tue, 24 Oct 2023 09:51:39 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <gQyz0Ymz5D09Wuwv4hsUjuWMSHG32Fkp_vhzQtrMAhI=.806fba1c-cc72-452e-b3d2-316b25600e3c@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> Rename createJavaProcessBuilder so that it is not used by mistake instead of createTestJvm.
>> 
>> I have used the following sed script: `find -name "*.java" | xargs -n 1 sed -i -e "s/createJavaProcessBuilder(/createJavaProcessBuilderIgnoreTestJavaOpts(/g"`
>> 
>> Then I have manually modified ProcessTools.java. In that file I have moved one version of createJavaProcessBuilder so that it is close to the other version. Then I have added a javadoc comment in bold telling:
>> 
>>    /**
>>      * Create ProcessBuilder using the java launcher from the jdk to
>>      * be tested.
>>      *
>>      * <p><b> Please observe that you likely should use
>>      * createTestJvm() instead of this method because createTestJvm()
>>      * will add JVM options from "test.vm.opts" and "test.java.opts"
>>      * </b> and this method will not do that.
>>      *
>>      * @param command Arguments to pass to the java command.
>>      * @return The ProcessBuilder instance representing the java command.
>>      */
>> 
>> 
>> I have used the name createJavaProcessBuilderIgnoreTestJavaOpts because of the name of Utils.prependTestJavaOpts that adds those VM flags. If you have a better name I could do a rename of the method. I kind of like that it is long and clumsy, that makes it harder to use...
>> 
>> I have run tier 1 testing, and I have started more exhaustive testing.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1694437335

From rriggs at openjdk.org  Tue Oct 24 14:11:30 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 14:11:30 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v2]
In-Reply-To: <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <0ErSUbWpfJ7Ogdh8AuW6ChxgXKilFbgXTr54wec7zdc=.6e37688f-8209-4822-b9c9-99d145107250@github.com>
Message-ID: <N6wg5qK3HnWiBuWhu3A8cE0n9xYuTuT1pMimOrVyR7w=.bf70c1f9-a099-4254-854d-7ac181c54b0d@github.com>

On Fri, 6 Oct 2023 18:07:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
>> 
>> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tag setChoices as well

Drive-by comment: typo  "the the" in ChoiceFormat.toPattern(): line 322

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

PR Comment: https://git.openjdk.org/jdk/pull/16064#issuecomment-1777295653

From naoto at openjdk.org  Tue Oct 24 16:58:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 16:58:45 GMT
Subject: <i18n dev> Integrated: 8318569: Add getter methods for Locale and
 Patterns in ListFormat
In-Reply-To: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
References: <7szzuDvcyT97l5YS90oTisyJnxb14M3Ad5-JaQYEo8w=.df9a4a76-e6f6-46d2-861d-e821a7848c94@github.com>
Message-ID: <VNWN6MKICykmtUMm0A8vPC45HiiKb9YfX0geLwZnz3s=.7089fe71-a539-4f07-ba0d-c861d6a49945@github.com>

On Fri, 20 Oct 2023 17:57:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing adding getter methods for `locale` and `patterns` fields in the `ListFormat` instances. Those fields are used for `equals()`, but without the public getter methods, users cannot tell the reasoning of the equality of two instances. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 11650375
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/116503754c4c4bdb91685955ef4456bc76f751c4
Stats:     60 lines in 2 files changed: 59 ins; 0 del; 1 mod

8318569: Add getter methods for Locale and Patterns in ListFormat

Reviewed-by: joehw, rriggs, iris, mli

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

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

From lmesnik at openjdk.org  Tue Oct 24 17:04:41 2023
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 24 Oct 2023 17:04:41 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <G2CSM_N-_TwMdAlZX8c-AJtweGPX39TTxuu9HXtGrbc=.1d47edf7-9d08-46ba-9e3b-3549574ebbea@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

Marked as reviewed by lmesnik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1695447658

From joehw at openjdk.org  Tue Oct 24 17:07:48 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Oct 2023 17:07:48 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v2]
In-Reply-To: <cC4RhyGKBb8V8Mf3eVZRA1KWCcdFGouXkGNpASqveyg=.fd8c2635-c288-4d95-b685-3a92540d6a43@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <cC4RhyGKBb8V8Mf3eVZRA1KWCcdFGouXkGNpASqveyg=.fd8c2635-c288-4d95-b685-3a92540d6a43@github.com>
Message-ID: <WShQzqZ0AsSvoKw5Pai_Nl1V1eWtdpaLvmawmuO17QY=.b0ea6ed8-380a-4961-bce4-97c598e230c4@github.com>

On Tue, 24 Oct 2023 17:05:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A 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 six commits:
> 
>  - Merge branch 'master' into JDK-8318487-ListFormat-equals
>  - Fixing typo
>  - Removed redundant wording
>  - initial commit
>  - Simplified the method spec
>  - initial commit

Looks fine to me. 

Alternatively (or more explicitly), it could be: Compares the specified object with this {@code ListFormat} for equality. Returns true if the given object is also a {@code ListFormat}  and the two represent the same formats, specifically, if both {@code locale} and {@code patterns}, returned from {@link #getLocale()} and {@link #getPatterns()} respectively, are equal.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695451108

From naoto at openjdk.org  Tue Oct 24 17:07:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:07:47 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v2]
In-Reply-To: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
Message-ID: <cC4RhyGKBb8V8Mf3eVZRA1KWCcdFGouXkGNpASqveyg=.fd8c2635-c288-4d95-b685-3a92540d6a43@github.com>

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A 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 six commits:

 - Merge branch 'master' into JDK-8318487-ListFormat-equals
 - Fixing typo
 - Removed redundant wording
 - initial commit
 - Simplified the method spec
 - initial commit

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

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

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

From naoto at openjdk.org  Tue Oct 24 17:58:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:58:48 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
Message-ID: <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

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

  Reflecting review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16321/files
  - new: https://git.openjdk.org/jdk/pull/16321/files/0e586395..57b91b4b

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

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

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

From naoto at openjdk.org  Tue Oct 24 17:58:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 24 Oct 2023 17:58:49 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <WShQzqZ0AsSvoKw5Pai_Nl1V1eWtdpaLvmawmuO17QY=.b0ea6ed8-380a-4961-bce4-97c598e230c4@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <cC4RhyGKBb8V8Mf3eVZRA1KWCcdFGouXkGNpASqveyg=.fd8c2635-c288-4d95-b685-3a92540d6a43@github.com>
 <WShQzqZ0AsSvoKw5Pai_Nl1V1eWtdpaLvmawmuO17QY=.b0ea6ed8-380a-4961-bce4-97c598e230c4@github.com>
Message-ID: <zRszg51XEgg_OHxrG5Bg4U0zgCrBrNZTDtbehY-Ew-M=.f2f3ad2e-1c81-46d8-8850-3aebde56adcf@github.com>

On Tue, 24 Oct 2023 17:04:25 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflecting review comments
>
> Looks fine to me. 
> 
> Alternatively (or more explicitly), it could be: Compares the specified object with this {@code ListFormat} for equality. Returns true if the given object is also a {@code ListFormat}  and the two represent the same formats, specifically, if both {@code locale} and {@code patterns}, returned from {@link #getLocale()} and {@link #getPatterns()} respectively, are equal.

Thanks, @JoeWang-Java 
In fact, your suggested style aligns with other `Format` classes, such as `DateFormat`/`NumberFormat`. Modified the wording to align with them.

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

PR Comment: https://git.openjdk.org/jdk/pull/16321#issuecomment-1777742029

From joehw at openjdk.org  Tue Oct 24 18:43:30 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 24 Oct 2023 18:43:30 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
Message-ID: <lN8rvbGp5JU9jYXC990lPm_hy0ThtXtshW1w2l0jiME=.e0fde5fc-7eaf-45e4-8e45-49b39a7d8a93@github.com>

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Thanks for the update, looks good again :-). Nice to know the javadoc styles are aligned.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695642472

From rriggs at openjdk.org  Tue Oct 24 18:48:35 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 18:48:35 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
Message-ID: <iDupA1n_BMqqQwvLxzDoXzDXUwj5GGmj0jV9Zhl82G8=.71d7345a-7d87-4f67-a4a4-11b3a3350bb7@github.com>

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695650865

From lancea at openjdk.org  Tue Oct 24 18:53:36 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 24 Oct 2023 18:53:36 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
Message-ID: <TQchRx9FIqWhRCGHECrjonPEhYIZFZZX16KiWtw0B1Q=.6c216d5e-4e03-4777-b3ea-b25fa30b1e79@github.com>

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695659263

From iris at openjdk.org  Tue Oct 24 18:58:29 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 24 Oct 2023 18:58:29 GMT
Subject: <i18n dev> RFR: 8318487: Specification of the
 ListFormat.equals() method can be improved [v3]
In-Reply-To: <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
 <ZfsS9udDMhEKw_9867KmIxJP4CiiJ4RI1VR9Wsv8ZxA=.f5ff95e2-5cb1-442c-bf27-cca0abc127e1@github.com>
Message-ID: <yKGQhbFv84buM5l-fstmgjO4BP-AhSKRfBAyzg-dbfE=.62bb9aec-b600-40d7-a51b-76de8c62dd57@github.com>

On Tue, 24 Oct 2023 17:58:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review comments

Corresponding CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16321#pullrequestreview-1695669443

From rriggs at openjdk.org  Tue Oct 24 19:42:43 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 24 Oct 2023 19:42:43 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v6]
In-Reply-To: <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <CxPRMRrp5YUzS45-ci5i1hRr3pLNRE_y1QsPH-_NnSM=.0bd7e9ea-f56c-4f52-8bb4-a8aa06501881@github.com>
Message-ID: <6qyfRp98A2DA7Q7YhscmdmokkIvVVn9HxB_XjRdM47g=.615d7a65-e109-41db-b955-31c0a934debd@github.com>

On Tue, 24 Oct 2023 07:49:30 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - static import
>  - copyright
>  - whitespace
>  - whitespace
>  - sed
>  - fix test/lib/jdk/test/lib/process/ProcessTools.java

test/lib/jdk/test/lib/process/ProcessTools.java line 506:

> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {
> 506:         return createTestJavaProcessBuilder(command.toArray(String[]::new));

The javadoc shoul d describe all of the options being added to the ProcessBuilder.
They were inadequated described previously and still are.
The other options (seem to be from the code), test.noclasspath, java.class.path, and test.thread.factory.
The description of test.thread.factory and addTestThreadFactoryArgs method seems inadequately described.

test/lib/jdk/test/lib/process/ProcessTools.java line 527:

> 525:      * Create ProcessBuilder using the java launcher from the jdk to
> 526:      * be tested.
> 527:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for `reateTestJavaProcessBuilder(...)`

test/lib/jdk/test/lib/process/ProcessTools.java line 549:

> 547:      * Create ProcessBuilder using the java launcher from the jdk to
> 548:      * be tested.
> 549:      *

As above, should described the limited options that are added to the ProcessBuilder, the same as for reateTestJavaProcessBuilder(...)

test/lib/jdk/test/lib/process/ProcessTools.java line 599:

> 597:      */
> 598:     public static OutputAnalyzer executeTestJvm(String... cmds) throws Exception {
> 599:         ProcessBuilder pb = createTestJavaProcessBuilder(cmds);

This should also describe *all* of the options being set in the ProcessBuilder before executing the process.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370728371
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729609
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370729925
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1370730637

From stefank at openjdk.org  Wed Oct 25 07:27:32 2023
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 25 Oct 2023 07:27:32 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v3]
In-Reply-To: <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <yXSuvUGhjCND4oyxnP9Aa0LP-t0XFaMebLzPqEZEGpA=.1658ad96-5848-4a9f-ae75-776cb4076705@github.com>
 <5o5B7LbCQN_C9xzd1EvrvTp04-6Atr0gih5WH69LeK4=.3a977034-8fe9-4da8-a167-f5dad3a97d75@github.com>
 <CZcrmy99xK8GvWF8BD1TmmM_Q8F0po6d3zExg2zNtSY=.9d126ffd-f3ad-4257-a0e4-0a83e3e17a47@github.com>
Message-ID: <BYTPUH_b0INyCGVwslaQVyQkTYKNOQvJfnLhKv6mlLM=.bbd8a311-3af8-4288-9491-55c8098af7c8@github.com>

On Tue, 5 Sep 2023 18:05:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I have created an alternative that uses enums to force the user to make a decision: https://github.com/openjdk/jdk/compare/master...lkorinth:jdk:+process_tools . Another alternative is to do the same but instead using an enum (I think it is not as good). A third alternative is to use the current pull request with a better name.
>> 
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test cases.
>
>> What do you prefer? Do you have a better alternative? Do someone still think the current code is good? I think what we have today is inferior to all these improvements, and I would like to make it harder to develop bad test ca
> 
> The current API (name) is fine and fit for purpose; it does not promise or hide extra functionality under a simple name.
> 
> There needs to be an explicit intention in the test(s) to support after the fact that arbitrary flags can be added.
> @AlanBateman's proposal for naming [above](https://github.com/openjdk/jdk/pull/15452#issuecomment-1700459277) (or similar) would capture more clearly that test options are propagated to the child process.
> Every test writer should be aware that additional command line options may be mixed in.
> 
> There are many cases in which the ProcessTools APIs are not used to create child processes and do not need to be used in writing tests. They provide some convenience but also add a dependency and another API layer to work through in the case of failures.
> 
> As far as I'm aware, there is no general guidance or design pattern outside of hotspot tests to propagate flags or use ProcessTools. Adding that as a requirement will need a different level of communication and change.

@RogerRiggs You seem to know what you want w.r.t. the extra java doc comments. Could you help write those? Could we also do that as a separate RFE? I think that would make it easier to get this PR and the javadoc update through the door.

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1778669353

From lkorinth at openjdk.org  Wed Oct 25 08:44:29 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Wed, 25 Oct 2023 08:44:29 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

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

  fix copyright year and indentation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15452/files
  - new: https://git.openjdk.org/jdk/pull/15452/files/2f57a32d..4cc3865a

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

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

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

From naoto at openjdk.org  Wed Oct 25 16:53:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 25 Oct 2023 16:53:42 GMT
Subject: <i18n dev> Integrated: 8318487: Specification of the
 ListFormat.equals() method can be improved
In-Reply-To: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
References: <qHrJEPtyygvPDOhIsyIqU5RII7KhfM1comEk6-wyeCo=.a743b8e1-b55c-4470-8b08-a2c1ab10c71a@github.com>
Message-ID: <tDXwReDIPuinVnQiA63C7tXEZI5Htulve3fFexomuXg=.2a42744d-4fbf-49df-a8e5-7fae823b27d2@github.com>

On Mon, 23 Oct 2023 18:40:26 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Spec clarification of `ListFormat.equals()` method, utilizing newly introduced `getLocale()` and `getPatterns()`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

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

8318487: Specification of the ListFormat.equals() method can be improved

Reviewed-by: joehw, rriggs, lancea, iris

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

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

From jlu at openjdk.org  Wed Oct 25 17:15:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 25 Oct 2023 17:15:43 GMT
Subject: <i18n dev> Integrated: 8318186: ChoiceFormat inconsistency between
 applyPattern() and setChoices()
In-Reply-To: <tfp-FCQu7xes8ScMt5VyxE_xuiN-ojseinMPlIRU0Tk=.f3f0be5c-ecab-4a22-8d88-1341b0639ab6@github.com>
References: <tfp-FCQu7xes8ScMt5VyxE_xuiN-ojseinMPlIRU0Tk=.f3f0be5c-ecab-4a22-8d88-1341b0639ab6@github.com>
Message-ID: <GdLcg9nRwsBM7Gc_QG4XG8BW_8TppWA-hWlYQf4Q4kQ=.d0238297-e338-4a9c-b1ed-600a15e21636@github.com>

On Mon, 23 Oct 2023 17:16:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies inconsistency between `ChoiceFormat::applyPattern` and `ChoiceFormat::setChoices`.
> 
> A `ChoiceFormat` is composed of limits and formats. `applyPattern()` will throw an exception if limits are not in ascending order, while `setChoices()` will not. This should be clarified in the specification of `applyPattern()`.

This pull request has now been integrated.

Changeset: ca3bdfc0
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca3bdfc0c7a74e23329cd9487279992e345b2efd
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8318186: ChoiceFormat inconsistency between applyPattern() and setChoices()

Reviewed-by: naoto

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

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

From rriggs at openjdk.org  Wed Oct 25 22:00:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 25 Oct 2023 22:00:31 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <qyv3_2FCcacwbDL17B7JewcsR5XazNJjio3Z_WNTq_U=.88ec5e8f-7929-443c-a85f-617260b584e4@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Suggestions to complete the descriptions of the createXXXJavaProcessBuilder methods.

test/lib/jdk/test/lib/process/ProcessTools.java line 505:

> 503:      * @return The ProcessBuilder instance representing the java command.
> 504:      */
> 505:     public static ProcessBuilder createTestJavaProcessBuilder(List<String> command) {

Include the same description of other properties that are included in creating the ProcessBuilder...
```     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 520:

> 518:      * @return The ProcessBuilder instance representing the java command.
> 519:      */
> 520:     public static ProcessBuilder createTestJavaProcessBuilder(String... command) {

Include the same description of other properties that are included in creating the ProcessBuilder...

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 538:

> 536:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 537:      * anotation as to not waste energy and test resources.
> 538:      *

Consider adding this description of what this method does.
Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

test/lib/jdk/test/lib/process/ProcessTools.java line 560:

> 558:      * it in combination with <b>@requires vm.flagless</b> JTREG
> 559:      * anotation as to not waste energy and test resources.
> 560:      *

Suggestion:

     * Unless the "test.noclasspath" property is "true"
     * the classpath property "java.class.path" is appended to the command line and
     * the environment of the ProcessBuilder is modified to remove "CLASSPATH".
     * If the property "test.thread.factory" is provided the command args are
     * updated and appended to invoke ProcessTools main() and provide the 
     * name of the thread factory.
     * The "-Dtest.thread.factory" is appended to the arguments with the thread factory value.
     * The remaining command args are scanned for unsupported options and 
     * are appended to the ProcessBuilder.

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

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1698308785
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364800
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372364171
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372361862
PR Review Comment: https://git.openjdk.org/jdk/pull/15452#discussion_r1372362333

From lkorinth at openjdk.org  Thu Oct 26 15:33:38 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 26 Oct 2023 15:33:38 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <CZyt2tGATgYnxwwXcRUx-f2W4UTwCRouztmSTtinrTw=.6dc482ad-77ad-4d75-94ab-0ae273d0a2a8@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Would it be okay if we handle the new method documentation in a separate pull request? 

After applying your changes, I also noted that the existing description `The command line will be like: {test.jdk}/bin/java {test.vm.opts} {test.java.opts} cmds` is not only incorrect (or at least incomplete), but now also clashes with the added description. I then removed the sentence, but after I did that I also found out that similar wording exist in `executeTestJvm` and I fear that if I continue to pull strings, I will create more and more changes that you will have opinions on.

Is it all right if we push what we have now, and that I create a new pull requests with these improvements in documentation that are actually not related to the changes in this pull request?

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1781359450

From rriggs at openjdk.org  Thu Oct 26 16:29:40 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 26 Oct 2023 16:29:40 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <Yx-2Zuy3fBrCV9jiHIiGJSLOBBy7Hv9BVRBeB1ytvLk=.e3026827-3141-4ee4-b8ea-2d459d42eabf@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

ok, to correct the javadoc in a subsequent PR.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15452#pullrequestreview-1700061972

From lkorinth at openjdk.org  Fri Oct 27 08:50:47 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 08:50:47 GMT
Subject: <i18n dev> Integrated: 8315097: Rename createJavaProcessBuilder
In-Reply-To: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
Message-ID: <n5Oky40OR8ZXdkJbSQiivcZCzZ6XP12wnJEWzcY4xYw=.d997c70c-cae2-4bf3-9d83-2f24d1cbcb22@github.com>

On Mon, 28 Aug 2023 15:54:08 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
> 
> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.

This pull request has now been integrated.

Changeset: d52a995f
Author:    Leo Korinth <lkorinth at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d52a995f35de26c2cc4074297a75141e4a363e1b
Stats:     1574 lines in 560 files changed: 44 ins; 10 del; 1520 mod

8315097: Rename createJavaProcessBuilder

Reviewed-by: lmesnik, dholmes, rriggs, stefank

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

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

From lkorinth at openjdk.org  Fri Oct 27 09:00:48 2023
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 27 Oct 2023 09:00:48 GMT
Subject: <i18n dev> RFR: 8315097: Rename createJavaProcessBuilder [v7]
In-Reply-To: <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
References: <uiRsPN6Y-xlpEwV-mnXYs8JbFseCnxbtGrxfgUAk2XE=.c9be5d27-e11f-401b-9797-c2943e7a83db@github.com>
 <fUZIxEzy3YZUqfx87qCu8fVP3jSaRzQKKNMIHjmu9F0=.ae9a3e9c-70a8-42cf-bf81-8e7193c72003@github.com>
Message-ID: <b2XfkO_Ez_LuJQZffSPp63wciX1NImzAD5l3Xy1elOU=.48bdc440-238c-4a86-b8b8-c2f37e2277a7@github.com>

On Wed, 25 Oct 2023 08:44:29 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This pull request renames `createJavaProcessBuilder` to `createLimitedTestJavaProcessBuilder` and renames `createTestJvm` to `createTestJavaProcessBuilder`. Both are implemented through a private `createJavaProcessBuilder`. It also updates the java doc.
>> 
>> This is so that it should be harder to by mistake use `createLimitedTestJavaProcessBuilder` that is problematic because it will not forward JVM flags to the tested JVM.
>
> Leo Korinth has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright year and indentation

Thanks, see:
https://bugs.openjdk.org/browse/JDK-8318962

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

PR Comment: https://git.openjdk.org/jdk/pull/15452#issuecomment-1782552641

From jlu at openjdk.org  Fri Oct 27 17:31:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 17:31:43 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v3]
In-Reply-To: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
Message-ID: <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317630) which makes the implications of overriding _ChoiceFormat::applyPattern_ and _MessageFormat::applyPattern_ apparent by adding a implSpec tag to the method. 
> 
> That is, the constructors of both ChoiceFormat and MessageFormat call the public and non-final applyPattern method; any changes in the applyPattern of a subclass will be reflected in the constructors as well.

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

 - additional cleanup/wording changes
 - replace spec fix with private methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/dc9cbae6..74847121

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

  Stats: 64 lines in 2 files changed: 35 ins; 13 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/16064.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16064/head:pull/16064

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

From naoto at openjdk.org  Fri Oct 27 18:04:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 18:04:33 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v3]
In-Reply-To: <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
Message-ID: <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>

On Fri, 27 Oct 2023 17:31:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - additional cleanup/wording changes
>  - replace spec fix with private methods

src/java.base/share/classes/java/text/ChoiceFormat.java line 560:

> 558:      * @see #previousDouble
> 559:      */
> 560:     public static double nextDouble (double d) {

Is removing `final` OK here? Wouldn't this allow defining the static method in the subclass?

src/java.base/share/classes/java/text/ChoiceFormat.java line 575:

> 573:      * @see #nextDouble
> 574:      */
> 575:     public static double previousDouble (double d) {

same here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374892774
PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374892964

From jlu at openjdk.org  Fri Oct 27 18:40:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 18:40:56 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v4]
In-Reply-To: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
Message-ID: <qL5rvkFbQJdZXxl13Y7dvh80OCIZijk_FG8fOQWWXxM=.e5cbec86-e13c-43d8-9819-d0054b9eb83c@github.com>

> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
> 
> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.

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

  re-apply 'final' to the static methods in ChoiceFormat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16064/files
  - new: https://git.openjdk.org/jdk/pull/16064/files/74847121..a44ea641

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

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

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

From jlu at openjdk.org  Fri Oct 27 18:40:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Oct 2023 18:40:59 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v3]
In-Reply-To: <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <-oqg7gWebD3KgZJj67_mukYJ_71WY7S2ZE5KBZWXBoI=.3d56d213-c6d0-4740-8703-3c1c0509c83f@github.com>
 <6VdB_bdBBUJqBHKnpfO5uyRWODjhJHFDcKWCXl281Bw=.a7ecdeb8-6a06-4c66-8d2f-4a8110cccd02@github.com>
Message-ID: <N7AmHG2ouZMQBhPl0WpBSoc61Pe6TSxF4IcEnkQPLZc=.5781a4a9-3653-4678-9c7a-ce7ac3c8ba5f@github.com>

On Fri, 27 Oct 2023 18:00:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - additional cleanup/wording changes
>>  - replace spec fix with private methods
>
> src/java.base/share/classes/java/text/ChoiceFormat.java line 560:
> 
>> 558:      * @see #previousDouble
>> 559:      */
>> 560:     public static double nextDouble (double d) {
> 
> Is removing `final` OK here? Wouldn't this allow defining the static method in the subclass?

Right, we don't want those methods to now have the ability to be hidden. Got carried away with the IDE suggested tips. Reverted here and in the other occurrence, thanks for correcting.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16064#discussion_r1374928055

From naoto at openjdk.org  Fri Oct 27 18:55:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 27 Oct 2023 18:55:34 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v4]
In-Reply-To: <qL5rvkFbQJdZXxl13Y7dvh80OCIZijk_FG8fOQWWXxM=.e5cbec86-e13c-43d8-9819-d0054b9eb83c@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <qL5rvkFbQJdZXxl13Y7dvh80OCIZijk_FG8fOQWWXxM=.e5cbec86-e13c-43d8-9819-d0054b9eb83c@github.com>
Message-ID: <REEII4Qz-UAGiSj8bKoF1eDaVaOeNhQ2ojzaXGz9TWA=.99c40dc4-7c8a-46d7-a8e8-a09e72073859@github.com>

On Fri, 27 Oct 2023 18:40:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-apply 'final' to the static methods in ChoiceFormat

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16064#pullrequestreview-1702372815

From lancea at openjdk.org  Fri Oct 27 19:11:32 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 27 Oct 2023 19:11:32 GMT
Subject: <i18n dev> RFR: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method [v4]
In-Reply-To: <qL5rvkFbQJdZXxl13Y7dvh80OCIZijk_FG8fOQWWXxM=.e5cbec86-e13c-43d8-9819-d0054b9eb83c@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
 <qL5rvkFbQJdZXxl13Y7dvh80OCIZijk_FG8fOQWWXxM=.e5cbec86-e13c-43d8-9819-d0054b9eb83c@github.com>
Message-ID: <bjmfkhWoQCCEobr9gOfJbFB-mrpy48peSEj_7B832CU=.e70e034a-b80a-498c-a2fc-69a6f4cc5ef1@github.com>

On Fri, 27 Oct 2023 18:40:56 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
>> 
>> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-apply 'final' to the static methods in ChoiceFormat

Looks reasonable.  I assume you validated the links work in the generated docs as a sanity check

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16064#pullrequestreview-1702392861