From jlu at openjdk.org  Tue Mar  4 01:42:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 01:42:15 GMT
Subject: <i18n dev> RFR: 8351074: Disallow null prefix and suffix in
 DecimalFormat
Message-ID: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>

Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.

Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Tue Mar  4 01:47:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 01:47:40 GMT
Subject: <i18n dev> RFR: 8351074: Disallow null prefix and suffix in
 DecimalFormat [v2]
In-Reply-To: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
References: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
Message-ID: <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

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

  correct bug ID for test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23880/files
  - new: https://git.openjdk.org/jdk/pull/23880/files/56af293b..e13ac0d0

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

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

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

From darcy at openjdk.org  Tue Mar  4 03:06:57 2025
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 4 Mar 2025 03:06:57 GMT
Subject: <i18n dev> RFR: 8343478: Remove unnecessary @SuppressWarnings
 annotations (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <W8BPBHtpkYLbekVYCqKGsSeApyGK60RNxTllOXVrtps=.c6f70097-023c-4576-adca-24af472b29d3@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

The changes in java.base look fine.

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

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2655808338

From asemenyuk at openjdk.org  Tue Mar  4 15:33:18 2025
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 4 Mar 2025 15:33:18 GMT
Subject: <i18n dev> RFR: 8343478: Remove unnecessary @SuppressWarnings
 annotations (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <U_4rxRfTLxWD5hsA5ijRVf2WtFs9OZIaRgipndWaYF0=.cfdcaed5-bca2-4709-bd8f-73d2a0bf8e10@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

jpackage looks good

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

Marked as reviewed by asemenyuk (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2658012030

From acobbs at openjdk.org  Tue Mar  4 15:50:57 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 4 Mar 2025 15:50:57 GMT
Subject: <i18n dev> RFR: 8343478: Remove unnecessary @SuppressWarnings
 annotations (core-libs) [v12]
In-Reply-To: <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <S0beG1Fkvlnv5Y1faGvPsIraOef-3HFjgQXfjGXARqE=.355baf5c-d33a-4206-8eeb-12d1a1bacf41@github.com>
Message-ID: <usXIhWpm-DANq2l3PeiNZIXORXwrePyQTgwrxrclAAc=.59105abf-ecbd-481a-a9ea-ed8a39bfeeec@github.com>

On Sat, 15 Feb 2025 21:27:56 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits:
> 
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs to fix conflicts.
>  - Remove a few more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update @LastModified tags.
>  - Revert changes under src/java.desktop (to be moved into a separate PR).
>  - Bump copyright year to 2025.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/ba281196...340ca514

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2698092830

From jlu at openjdk.org  Tue Mar  4 17:11:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 17:11:59 GMT
Subject: <i18n dev> Integrated: 4745837: Make grouping usage during parsing
 apparent in relevant NumberFormat methods
In-Reply-To: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
References: <Wm3MOM992rHEwa6bIbGd-760YQ4cdMcI8g0bQLFmvAw=.96a42b20-fbee-434e-8523-29612634f77e@github.com>
Message-ID: <XBsCDzYYdMMdapMY8X1vakeJ7pGTZ7cvg-a9W_ydKDM=.e10e1ef1-4fb5-4ac4-be19-d526044fd7f1@github.com>

On Wed, 26 Feb 2025 22:18:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies some behavior regarding NumberFormat grouping specifically in the grouping related methods.
> 
> Please see the corresponding CSR for further detail. Note that an alternative would be to specify this at the DecimalFormat level, allowing NumberFormat subclasses to define this behavior how they want. IMO, I would expect `setGroupingUsed(boolean)` to affect both; a subclass could define `(is|set)(Parsing|Formatting)GroupingUsed` if need be, thus the proposed solution.

This pull request has now been integrated.

Changeset: 5b8d3491
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5b8d3491bf685a64b72b0ae763697353d09f61a1
Stats:     14 lines in 1 file changed: 9 ins; 0 del; 5 mod

4745837: Make grouping usage during parsing apparent in relevant NumberFormat methods

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Tue Mar  4 17:56:06 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Mar 2025 17:56:06 GMT
Subject: <i18n dev> RFR: 8351074: Disallow null prefix and suffix in
 DecimalFormat [v2]
In-Reply-To: <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>
References: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
 <9YlrvHo8RszYEXGvitEoOr1l6cLODkGXiCV57cD2EJw=.526e1e82-be7b-4b5d-8899-6aa9cb8b66d6@github.com>
Message-ID: <ZoW4h0wuD3aTR3RCjbKvdIvksmK3coVTV7YsgfWThVU=.7973c50d-ba4e-4880-a76f-02d8a5dbf592@github.com>

On Tue, 4 Mar 2025 01:47:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
>> 
>> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct bug ID for test

src/java.base/share/classes/java/text/DecimalFormat.java line 2815:

> 2813:      * <P>Examples: +123, $123, sFr123
> 2814:      *
> 2815:      * @param newValue the new positive prefix

Although it may be apparent with the `@throws` tag, `@param` can also mention the new value is non-null.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/23880#discussion_r1979942411

From jlu at openjdk.org  Tue Mar  4 18:12:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 4 Mar 2025 18:12:48 GMT
Subject: <i18n dev> RFR: 8351074: Disallow null prefix and suffix in
 DecimalFormat [v3]
In-Reply-To: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
References: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
Message-ID: <qDaImU2zxdO61yEK7CL1QrITjNHWHlKScEEj7QNu-ZU=.e345b305-4413-4cb8-93df-e6e554384907@github.com>

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

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

  Make non-null apparent in param tag as well

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23880/files
  - new: https://git.openjdk.org/jdk/pull/23880/files/e13ac0d0..623bfdac

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

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

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

From naoto at openjdk.org  Tue Mar  4 18:32:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 4 Mar 2025 18:32:04 GMT
Subject: <i18n dev> RFR: 8351074: Disallow null prefix and suffix in
 DecimalFormat [v3]
In-Reply-To: <qDaImU2zxdO61yEK7CL1QrITjNHWHlKScEEj7QNu-ZU=.e345b305-4413-4cb8-93df-e6e554384907@github.com>
References: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
 <qDaImU2zxdO61yEK7CL1QrITjNHWHlKScEEj7QNu-ZU=.e345b305-4413-4cb8-93df-e6e554384907@github.com>
Message-ID: <Ch4yUxXbr0nxPg3h2IZLChDKsqNRe7JeKMpXkPhcdqw=.bdbd5b3c-1f3a-4acf-b600-e463226b5003@github.com>

On Tue, 4 Mar 2025 18:12:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
>> 
>> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make non-null apparent in param tag as well

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23880#pullrequestreview-2658576784

From acobbs at openjdk.org  Wed Mar  5 17:36:13 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 5 Mar 2025 17:36:13 GMT
Subject: <i18n dev> Integrated: 8343478: Remove unnecessary
 @SuppressWarnings annotations (core-libs)
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <icYlXrDtiwdWI9MZiwebjTsB4KdwFL1dUxcwmGAJzaU=.fecd1705-787d-4be0-b2a3-081e6a81236e@github.com>

On Sat, 2 Nov 2024 15:40:30 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

This pull request has now been integrated.

Changeset: 661bd5bf
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/661bd5bfe883a7449c6949c9f4bd6b5d82d20e10
Stats:     211 lines in 93 files changed: 0 ins; 90 del; 121 mod

8343478: Remove unnecessary @SuppressWarnings annotations (core-libs)

Reviewed-by: darcy, asemenyuk, joehw

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

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

From jlu at openjdk.org  Wed Mar  5 18:16:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 5 Mar 2025 18:16:08 GMT
Subject: <i18n dev> Integrated: 8351074: Disallow null prefix and suffix in
 DecimalFormat
In-Reply-To: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
References: <fzX67iNjt7TCtUK5-YKYM4yX1wsB6nRghuFI9EVuGjw=.b2c088b6-e917-4d72-87e1-b51946d2c38a@github.com>
Message-ID: <HQPmQzJVF-kS7VUy-bzVVMOBJ0Gqw-MrJZY6xyQQekY=.04210d49-5b33-468e-8f5a-f52fc5a660fb@github.com>

On Tue, 4 Mar 2025 01:37:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and associated CSR which disallows passing null to 4 `DecimalFormat` prefix/suffix setter methods.
> 
> Currently these setters do not check the input String for null. When the prefix/suffix is null, any such DecimalFormat instances are effectively non-functional as it will throw NPE for most operations.

This pull request has now been integrated.

Changeset: c3b48196
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3b48196af40356a8251b42db13e02ed905c2139
Stats:     64 lines in 2 files changed: 59 ins; 0 del; 5 mod

8351074: Disallow null prefix and suffix in DecimalFormat

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Thu Mar  6 23:42:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 6 Mar 2025 23:42:25 GMT
Subject: <i18n dev> RFR: 8351017: ChronoUnit.MONTHS.between() not giving
 correct result when date is in February
Message-ID: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>

Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

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

Commit messages:
 - initial commit

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

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

From scolebourne at openjdk.org  Fri Mar  7 06:50:51 2025
From: scolebourne at openjdk.org (Stephen Colebourne)
Date: Fri, 7 Mar 2025 06:50:51 GMT
Subject: <i18n dev> RFR: 8351017: ChronoUnit.MONTHS.between() not giving
 correct result when date is in February
In-Reply-To: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
References: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
Message-ID: <_SL0c6sLPnjoMI5DUDK6Qf0WRvUDGWYvfeEIzpwXFIY=.30f0ae78-e7a9-4db7-bb05-57fd5fff3564@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

Marked as reviewed by scolebourne (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/23937#pullrequestreview-2666401651

From rriggs at openjdk.org  Fri Mar  7 15:47:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 7 Mar 2025 15:47:54 GMT
Subject: <i18n dev> RFR: 8351017: ChronoUnit.MONTHS.between() not giving
 correct result when date is in February
In-Reply-To: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
References: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
Message-ID: <1Tovre03xAO-vYF_SbW_0NcE7MzFUF3LMF93kfXWsO4=.d071de1b-9e79-4ad0-a41c-aa2ff1c0b892@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

A nice, simple and direct clarification.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23937#pullrequestreview-2667651475

From swen at openjdk.org  Sun Mar  9 15:42:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:42:57 GMT
Subject: <i18n dev> RFR: 8337279: Optimize format instant [v15]
In-Reply-To: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
Message-ID: <C2XA_xtGUjjHUKzgXBmksGjOqiXK3g38qFBpquAEEOA=.bf218e51-f96c-432a-bd14-2f967aae9789@github.com>

On Mon, 3 Feb 2025 22:31:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @natoj

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/20353#issuecomment-2708921754

From swen at openjdk.org  Sun Mar  9 15:43:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 9 Mar 2025 15:43:55 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v11]
In-Reply-To: <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
 <pZyjbkMKNfkml8IbnMEy5oF3rwOnKHGG6J99sUA6PUw=.33c09e07-3d3a-4b8f-8e59-e568a01dda66@github.com>
Message-ID: <MUgIJOMOU0tY2O-qajiFjSNPatuSbKbMxPW4M_xxNlA=.c182ec3b-444b-493c-9ed5-d337bdb5af86@github.com>

On Tue, 4 Feb 2025 13:39:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
>> 
>> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
>> 
>> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
>> 
>> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
>> 
>> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more use getInt & add more test

Keep it alive.

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

PR Comment: https://git.openjdk.org/jdk/pull/23384#issuecomment-2708922153

From naoto at openjdk.org  Mon Mar 10 16:16:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Mar 2025 16:16:03 GMT
Subject: <i18n dev> RFR: 8351017: ChronoUnit.MONTHS.between() not giving
 correct result when date is in February
In-Reply-To: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
References: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
Message-ID: <arDyIUPDtHbdDPVBwgIN-UqaUPKhBUatN4dWbMFLtk4=.01997249-8b86-477e-b67d-975487e2c21c@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23937#issuecomment-2711119572

From naoto at openjdk.org  Mon Mar 10 16:16:04 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 10 Mar 2025 16:16:04 GMT
Subject: <i18n dev> Integrated: 8351017: ChronoUnit.MONTHS.between() not
 giving correct result when date is in February
In-Reply-To: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
References: <wMAA7uGfB23qJas75QjGn3hG_Ypnmp_e7RbLNONR9eg=.f3911155-0c6f-4a6e-9830-e67e16826e8e@github.com>
Message-ID: <z9kWO6ZmsbMUW3A_uJhp96bSaOj0X7boznHnMqw4Ywk=.a235623d-8bce-4083-9020-71a8462eb32b@github.com>

On Thu, 6 Mar 2025 23:36:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Clarifying the explanation for `TemporalUnit.between()`. There is already an example for the `HOURS` case where the minutes are not enough to make a full hour. Explaining how smaller units contribute to determining the whole number, along with an explicit `MONTHS` example, which was the case reported by the bug submitter, will help users.

This pull request has now been integrated.

Changeset: 32f2c2d8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32f2c2d80894552b8c5329cfa51c7e836314901f
Stats:     9 lines in 1 file changed: 6 ins; 0 del; 3 mod

8351017: ChronoUnit.MONTHS.between() not giving correct result when date is in February

Reviewed-by: scolebourne, rriggs

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

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

From jlu at openjdk.org  Tue Mar 11 00:37:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:56 GMT
Subject: <i18n dev> RFR: 8345940: Migrate security-related resources
 from Java classes to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <dFKNY64YaNuM4dyOdANWxnWFoeMEtfxl9Hm1mT5LM9E=.609167ac-4f2b-46a6-acee-a87b3d0264f7@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Skimmed some tricky values and the conversions looked correct to me.
Since it was tested that the values are the same before and after, this change looks good to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2672454949

From jlu at openjdk.org  Tue Mar 11 00:37:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 11 Mar 2025 00:37:57 GMT
Subject: <i18n dev> RFR: 8345940: Migrate security-related resources
 from Java classes to properties files [v4]
In-Reply-To: <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <CrDEoZ4YYF_3j3dEB6qS5ATetPC4PjX6m8KFrlJVafc=.fd7410c8-979f-4afd-9b9f-2960c6d2e62f@github.com>
 <UvpBWDcBWmfaGJ8gfV74bguzvutUC5aXH67Na9Kjc88=.7451338c-6526-4c3d-891d-777bb058f528@github.com>
 <z291o0LyFlrFzcn_4SiqlLPiFaY56KCQ8rjEbQXaqzY=.e6d69344-1bd9-47a0-840e-87bcfda710ab@github.com>
Message-ID: <Xht5uew8BRiPQ24x2llPx98CwaT2R8HRdbLk1iXkZRo=.fd3f725b-89ff-4062-a594-b8118dfbef69@github.com>

On Mon, 10 Mar 2025 14:33:14 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> src/jdk.jartool/share/classes/sun/security/tools/jarsigner/resources/jarsigner_de.properties line 40:
>> 
>>> 38: If.keystore.is.not.password.protected.then.storepass.and.keypass.must.not.be.specified=Wenn der Keystore nicht kennwortgesch?tzt ist, d?rfen -storepass und -keypass nicht angegeben werden
>>> 39: Usage.jarsigner.options.jar.file.alias=Verwendung: jarsigner [options] jar-file alias
>>> 40: .jarsigner.verify.options.jar.file.alias.=\u0020      jarsigner -verify [options] jar-file [alias...]
>> 
>> We have generally kept `\u0020` in these properties files for the purpose of making it clear that trailing white space in a value is intentional. Can we convert these non trailing `\u0020` to just ` `?
>
> In properties files the whitespaces after `=` get trimmed when compiled, so when we replace `\u0020` with ` ` we get an incorrect string.

Ah, you're right, I am used to seeing those cases starting with `` to preserve the leading white space. Since it's just a stylistic choice, this seems fine then.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22774#discussion_r1988192291

From erikj at openjdk.org  Tue Mar 11 15:45:56 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 11 Mar 2025 15:45:56 GMT
Subject: <i18n dev> RFR: 8345940: Migrate security-related resources
 from Java classes to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <5irTdPcTdpBrzwzWUiAaZqHKbGINiONFtIYDLIguyws=.1f241454-7cae-4f45-9383-57953b37de8b@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

Build changes look good. Thanks for removing this special case in the build!

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

Marked as reviewed by erikj (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22774#pullrequestreview-2675130279

From duke at openjdk.org  Tue Mar 11 19:29:06 2025
From: duke at openjdk.org (duke)
Date: Tue, 11 Mar 2025 19:29:06 GMT
Subject: <i18n dev> RFR: 8345940: Migrate security-related resources
 from Java classes to properties files [v9]
In-Reply-To: <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
 <eVJOWg2rsj7ENp1IIDpSPg3xEyQGkjOmaRFxyZCE9LE=.41ada26b-95ae-4e54-b886-4d2aac8def11@github.com>
Message-ID: <joV_S3_Xkms97gK-ZPrW3mA3GyTTDTa0YsRUtuutZ8w=.5bad390d-c0bf-4dfc-9fbf-86c5d3b4882a@github.com>

On Mon, 10 Mar 2025 17:57:42 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
>> 
>> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
>> ./src/java.base/share/classes/sun/security/util/Resources.java
>> ./src/java.base/share/classes/sun/security/util/AuthResources.java
>> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java
>
> Artur Barashev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Keep the original copyright year

@artur-oracle 
Your change (at version 7d911bce09aa7ee1684a6f35cdb11e96167a53a3) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22774#issuecomment-2715472109

From abarashev at openjdk.org  Tue Mar 11 20:10:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 11 Mar 2025 20:10:04 GMT
Subject: <i18n dev> Integrated: 8345940: Migrate security-related resources
 from Java classes to properties files
In-Reply-To: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
References: <VcYaW7c8VemxErRph_vV-6R4oBLH95COplu5MkXTO6k=.1ba5c655-d0b4-4d00-a295-07ec01b935bf@github.com>
Message-ID: <FCtiyh0S_yfUYdLgDUGKtOQkoK0lNKLxRlzJbVtCgcQ=.7b72dbba-e11c-4717-a32d-8c1a75b19c42@github.com>

On Mon, 16 Dec 2024 22:03:59 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

> These resources files are in Java classes. If converted to properties files, the localized versions can use UTF-8 encoding directly.
> 
> ./src/java.base/share/classes/sun/security/tools/keytool/Resources.java
> ./src/java.base/share/classes/sun/security/util/Resources.java
> ./src/java.base/share/classes/sun/security/util/AuthResources.java
> ./src/jdk.jartool/share/classes/sun/security/tools/jarsigner/Resources.java

This pull request has now been integrated.

Changeset: 9a494181
Author:    Artur Barashev <abarashev at openjdk.org>
Committer: Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a49418138b93bc8ed8879be5c9b9b9c85ef47e1
Stats:     16201 lines in 83 files changed: 6064 ins; 10109 del; 28 mod

8345940: Migrate security-related resources from Java classes to properties files

Reviewed-by: jlu, weijun, erikj

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

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

From acobbs at openjdk.org  Thu Mar 13 01:26:38 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Mar 2025 01:26:38 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in Javadoc
Message-ID: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>

This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

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

Commit messages:
 - Fix minor Javadoc typos.

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

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

From naoto at openjdk.org  Thu Mar 13 01:38:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 13 Mar 2025 01:38:52 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <VXJx5_UlaJ1xNJxXLUWSMX2UvM6KT902SJ3U9LHx6Mc=.1a475e04-4ed2-46cb-b2d8-3394f7245a7c@github.com>

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

The change in `MessageFormat.java` looks good

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

PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2680224832

From iris at openjdk.org  Thu Mar 13 01:50:52 2025
From: iris at openjdk.org (Iris Clark)
Date: Thu, 13 Mar 2025 01:50:52 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <D4ouxVHx7Av0jP2dFrQvTL8w1JwF0Zg9yD2ulJtdxa4=.cd5e9f45-f312-4cc4-bc4b-9fb20f1c0cb2@github.com>

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

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

> 325:  *       <th scope="row" style="font-weight:normal">{@code unit}
> 326:  *       <td>{@link ListFormat#getInstance(Locale, ListFormat.Type, ListFormat.Style)
> 327:  *       ListFormat.getInstance}{@code (getLocale()}, {@link ListFormat.Type#UNIT}, {@link ListFormat.Style#FULL})

The new ')' at the end of the line.  Where's the matching '('?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r1992525288

From acobbs at openjdk.org  Thu Mar 13 01:59:51 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 13 Mar 2025 01:59:51 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <D4ouxVHx7Av0jP2dFrQvTL8w1JwF0Zg9yD2ulJtdxa4=.cd5e9f45-f312-4cc4-bc4b-9fb20f1c0cb2@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
 <D4ouxVHx7Av0jP2dFrQvTL8w1JwF0Zg9yD2ulJtdxa4=.cd5e9f45-f312-4cc4-bc4b-9fb20f1c0cb2@github.com>
Message-ID: <h6QxBQCtbqCLH7St7kVgDQuWqA6bAUQeYRXV_-wmAOU=.4ed847f8-a70e-4073-943c-62efab78c15c@github.com>

On Thu, 13 Mar 2025 01:46:53 GMT, Iris Clark <iris at openjdk.org> wrote:

> Where's the matching `(`?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.

You are correct - the matching `(` is the one preceding `getLocale()`.

I'm not sure what you mean by "I suspect that javadoc won't agree with that". This change is simply making this row of the table consistent with the ones above it. You can see how they currently appear [here](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/text/MessageFormat.html). In this row, the closing `}` should have been a `)`.

Thanks for taking a look.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r1992531755

From dfuchs at openjdk.org  Thu Mar 13 10:18:08 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 13 Mar 2025 10:18:08 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <oYWlllLOumaKEbCL34xITmFQSyumKmLwovhRem1n8TI=.0315816b-a20a-4601-b1ee-997b3bf3eb31@github.com>

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

LGTM

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

PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2681298904

From naoto at openjdk.org  Wed Mar 19 17:37:29 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Mar 2025 17:37:29 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0
Message-ID: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>

Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.

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

Commit messages:
 - Updated the CLDR chart
 - .md files update
 - TestUnicodeExtension version
 - LikelySubtagLocalesTest
 - release-47
 - CLDR-17484: English day periods are wrong
 - release-47-beta2
 - release-47-beta1
 - CLDR-18268: Add timeData for GS (#4319)
 - release-47-alpha2
 - ... and 4 more: https://git.openjdk.org/jdk/compare/4a02de82...3606a05e

Changes: https://git.openjdk.org/jdk/pull/24120/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24120&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346948
  Stats: 2731 lines in 1109 files changed: 931 ins; 261 del; 1539 mod
  Patch: https://git.openjdk.org/jdk/pull/24120.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24120/head:pull/24120

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

From naoto at openjdk.org  Wed Mar 19 17:48:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 19 Mar 2025 17:48:20 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0 [v2]
In-Reply-To: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
Message-ID: <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>

> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.

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

  Copyright year/bugid update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24120/files
  - new: https://git.openjdk.org/jdk/pull/24120/files/3606a05e..03863f07

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

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

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

From jlu at openjdk.org  Thu Mar 20 18:34:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 20 Mar 2025 18:34:10 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0 [v2]
In-Reply-To: <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
 <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
Message-ID: <g1l0JEW1t3ZD-6k4vK6T6RVnatpXxhWCM__astiOy7E=.17a069d3-79fa-41ec-8cc6-aada6e3daf6e@github.com>

On Wed, 19 Mar 2025 17:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year/bugid update

Spec change in spi and test changes LGTM. Spot checked some data which corresponds to v47. (E.g. en-AU time zone name changes)

test/jdk/sun/util/resources/cldr/LikelySubtagLocalesTest.java line 44:

> 42:     public static final List<Locale> AVAILABLE_LOCALES = Arrays.asList(Locale.getAvailableLocales());
> 43: 
> 44:     /* Samples of locales that do not exist as .xml CLDR source files, but derived from

New test looks good and is easier to understand. It was unclear to me why the previous test said "_Tests LikelySubtags is correctly reflected in Locale.getAvailableLocales()_" when it was testing all of the non-inferred locale tags.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/24120#pullrequestreview-2703662674
PR Review Comment: https://git.openjdk.org/jdk/pull/24120#discussion_r2006187889

From naoto at openjdk.org  Thu Mar 20 19:02:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 20 Mar 2025 19:02:10 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0 [v2]
In-Reply-To: <g1l0JEW1t3ZD-6k4vK6T6RVnatpXxhWCM__astiOy7E=.17a069d3-79fa-41ec-8cc6-aada6e3daf6e@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
 <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
 <g1l0JEW1t3ZD-6k4vK6T6RVnatpXxhWCM__astiOy7E=.17a069d3-79fa-41ec-8cc6-aada6e3daf6e@github.com>
Message-ID: <HsZu8lqZA9Uhp2ORq-USIbaN-E0GFI8C-8IQVcq5BNA=.9f023d73-64b9-413e-961e-7cb99ad504a6@github.com>

On Thu, 20 Mar 2025 18:04:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright year/bugid update
>
> test/jdk/sun/util/resources/cldr/LikelySubtagLocalesTest.java line 44:
> 
>> 42:     public static final List<Locale> AVAILABLE_LOCALES = Arrays.asList(Locale.getAvailableLocales());
>> 43: 
>> 44:     /* Samples of locales that do not exist as .xml CLDR source files, but derived from
> 
> New test looks good and is easier to understand. It was unclear to me why the previous test said "_Tests LikelySubtags is correctly reflected in Locale.getAvailableLocales()_" when it was testing all of the non-inferred locale tags.

Thanks Justin. The test has been checking *all* the available locales which should contain likelySubtag inferred ones. While this ensures comprehensive testing, it is not practical to logically derive the expected locale sets, as it is not as simple as listing .xml files + likelySubtag inferred. Maintaining the locale set per CLDR release does not seem practical, which is why this change was made.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24120#discussion_r2006276054

From joehw at openjdk.org  Thu Mar 20 21:31:08 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 20 Mar 2025 21:31:08 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0 [v2]
In-Reply-To: <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
 <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
Message-ID: <GmKJpbBbH3XzkCXBPxmiMgH_9MHqLev4FRp7-T51Ovw=.524820c1-cd45-4a4d-bd5a-c4eedb0067aa@github.com>

On Wed, 19 Mar 2025 17:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year/bugid update

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24120#pullrequestreview-2704160712

From liach at openjdk.org  Sat Mar 22 00:38:09 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 22 Mar 2025 00:38:09 GMT
Subject: <i18n dev> RFR: 8337279: Share StringBuilder to format instant
 [v15]
In-Reply-To: <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
 <9ntqc-mXvifLuLvIuP8WVd2fcfz8kx3TSUiwLmHOqjA=.6e455335-2ff3-48ad-9ad4-b71193cf7f3e@github.com>
Message-ID: <2ZlXVYGFjcQ3kpoUv__542mfEGwlXw1FvBVGlrwjspM=.e245bb75-7822-468a-8116-cec1355013e2@github.com>

On Mon, 3 Feb 2025 22:31:10 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> 1. Create a tool class jdk.internal.util.DateTimeHelper, move the formatTo method of LocalDateTime/LocalDate/LocalTime to it, so that these methods can be used across packages within JDK, so that StringBuilder can be shared, avoiding multiple creation of StringBuilder and toString.
>> 2. Refactor DateTimeFormatterBuilder::format to use the jdk.internal.util.DateTimeHelper::formatTo method.
>> 3. Split the DateTimeFormatterBuilder::format method, separate the currentEra and beforeCurrentEra sub-methods, so that codeSize < 325 can be inlined. Most scenarios call currentEra, so performance is improved.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @natoj

Refactor looks harmless. Optimization is splitting methods to help profiling and avoid one string copy in ZonedDateTime.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20353#pullrequestreview-2707617525

From swen at openjdk.org  Sat Mar 22 01:38:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 22 Mar 2025 01:38:33 GMT
Subject: <i18n dev> Integrated: 8337279: Share StringBuilder to format
 instant
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <CZ0P20nisqj083DmchZ_JVRP4Hu1_Y92-ALGUWFl3hc=.601056cb-dd83-4b1e-b687-98f80141a142@github.com>

On Fri, 26 Jul 2024 14:20:07 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 1. Create a tool class jdk.internal.util.DateTimeHelper, move the formatTo method of LocalDateTime/LocalDate/LocalTime to it, so that these methods can be used across packages within JDK, so that StringBuilder can be shared, avoiding multiple creation of StringBuilder and toString.
> 2. Refactor DateTimeFormatterBuilder::format to use the jdk.internal.util.DateTimeHelper::formatTo method.
> 3. Split the DateTimeFormatterBuilder::format method, separate the currentEra and beforeCurrentEra sub-methods, so that codeSize < 325 can be inlined. Most scenarios call currentEra, so performance is improved.

This pull request has now been integrated.

Changeset: 74420391
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74420391faff5614d3c9254be1fd2e764c3f0731
Stats:     449 lines in 10 files changed: 326 ins; 107 del; 16 mod

8337279: Share StringBuilder to format instant

Reviewed-by: naoto, liach

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

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

From liach at openjdk.org  Mon Mar 24 05:26:11 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 05:26:11 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <h6QxBQCtbqCLH7St7kVgDQuWqA6bAUQeYRXV_-wmAOU=.4ed847f8-a70e-4073-943c-62efab78c15c@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
 <D4ouxVHx7Av0jP2dFrQvTL8w1JwF0Zg9yD2ulJtdxa4=.cd5e9f45-f312-4cc4-bc4b-9fb20f1c0cb2@github.com>
 <h6QxBQCtbqCLH7St7kVgDQuWqA6bAUQeYRXV_-wmAOU=.4ed847f8-a70e-4073-943c-62efab78c15c@github.com>
Message-ID: <QpMBxf88r5WYiO4mwkpeJI9m2sUWj9S1dYxyGSZZhsA=.30976d9c-5811-4462-b77a-bf9d51ae47d3@github.com>

On Thu, 13 Mar 2025 01:57:20 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/MessageFormat.java line 327:
>> 
>>> 325:  *       <th scope="row" style="font-weight:normal">{@code unit}
>>> 326:  *       <td>{@link ListFormat#getInstance(Locale, ListFormat.Type, ListFormat.Style)
>>> 327:  *       ListFormat.getInstance}{@code (getLocale()}, {@link ListFormat.Type#UNIT}, {@link ListFormat.Style#FULL})
>> 
>> The new ')' at the end of the line.  Where's the matching '('?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.
>
>> Where's the matching `(`?  I'm guessing that the IDE thinks it's the one immediately before the `getLocale()`, but I suspect that javadoc won't agree with that.
> 
> You are correct - the matching `(` is the one preceding `getLocale()`.
> 
> I'm not sure what you mean by "I suspect that javadoc won't agree with that". This change is simply making this row of the table consistent with the ones above it. You can see how they currently appear [here](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/text/MessageFormat.html). In this row, the closing `}` should have been a `)`.
> 
> Thanks for taking a look.

Shouldn't this closing `)` be wrapped in `{@code}` like `{@code )}` to match with the code format in `{@code (getLocale()}`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r2009479111

From acobbs at openjdk.org  Mon Mar 24 12:30:02 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Mar 2025 12:30:02 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc [v2]
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <w03LyBj79X8eZy6oz2YdGPCR4Xv7SydG1momI6HtynE=.7073ba26-b92e-4119-bf2d-6a08978a0857@github.com>

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

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

  Apply font fixes per review suggestion.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24022/files
  - new: https://git.openjdk.org/jdk/pull/24022/files/784dad33..dde1c867

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

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

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

From acobbs at openjdk.org  Mon Mar 24 12:32:19 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Mar 2025 12:32:19 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc [v2]
In-Reply-To: <QpMBxf88r5WYiO4mwkpeJI9m2sUWj9S1dYxyGSZZhsA=.30976d9c-5811-4462-b77a-bf9d51ae47d3@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
 <D4ouxVHx7Av0jP2dFrQvTL8w1JwF0Zg9yD2ulJtdxa4=.cd5e9f45-f312-4cc4-bc4b-9fb20f1c0cb2@github.com>
 <h6QxBQCtbqCLH7St7kVgDQuWqA6bAUQeYRXV_-wmAOU=.4ed847f8-a70e-4073-943c-62efab78c15c@github.com>
 <QpMBxf88r5WYiO4mwkpeJI9m2sUWj9S1dYxyGSZZhsA=.30976d9c-5811-4462-b77a-bf9d51ae47d3@github.com>
Message-ID: <Jm19j9ZKFkph6Lyx0DCaeIzGInGRsrp8-EGApFlQKec=.11cb0f91-67ee-4b49-a265-2a4a843458f0@github.com>

On Mon, 24 Mar 2025 05:23:58 GMT, Chen Liang <liach at openjdk.org> wrote:

> Shouldn't this closing `)` be wrapped in `{@code}` like `{@code )}` to match with the code format in `{@code (getLocale()}`?

Yes it should - thanks. The two rows above also have the same problem, i.e., I was just making this row consistent with the ones above it, but you're right that we should be fixing the font mismatch instead of propagating it.

I've fixed all three in dde1c86740d.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24022#discussion_r2010086508

From acobbs at openjdk.org  Mon Mar 24 13:29:24 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Mar 2025 13:29:24 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc [v3]
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <OrX4RPOB_Pql8cDK8ptAsR5mY8VYuG3y2kbFd9Zg2Pc=.49a2e136-7958-4d72-8706-ae04441d688b@github.com>

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

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

  Revert accidental file change.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24022/files
  - new: https://git.openjdk.org/jdk/pull/24022/files/dde1c867..26cca6c5

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

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

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

From liach at openjdk.org  Mon Mar 24 13:59:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 24 Mar 2025 13:59:08 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc [v3]
In-Reply-To: <OrX4RPOB_Pql8cDK8ptAsR5mY8VYuG3y2kbFd9Zg2Pc=.49a2e136-7958-4d72-8706-ae04441d688b@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
 <OrX4RPOB_Pql8cDK8ptAsR5mY8VYuG3y2kbFd9Zg2Pc=.49a2e136-7958-4d72-8706-ae04441d688b@github.com>
Message-ID: <L4EFvsS1z436rgza_5PdjVRp_E8bz-5O1S_C7TBDDxQ=.a020b690-5e72-441b-922a-e425e15de114@github.com>

On Mon, 24 Mar 2025 13:29:24 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert accidental file change.

Looks good, these locations in the JDK 24 docs indeed have extra braces (besides AbstractTask which is not public API)

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24022#pullrequestreview-2710484440

From acobbs at openjdk.org  Mon Mar 24 14:05:14 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Mon, 24 Mar 2025 14:05:14 GMT
Subject: <i18n dev> RFR: 8351897: Extra closing curly brace typos in
 Javadoc [v3]
In-Reply-To: <L4EFvsS1z436rgza_5PdjVRp_E8bz-5O1S_C7TBDDxQ=.a020b690-5e72-441b-922a-e425e15de114@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
 <OrX4RPOB_Pql8cDK8ptAsR5mY8VYuG3y2kbFd9Zg2Pc=.49a2e136-7958-4d72-8706-ae04441d688b@github.com>
 <L4EFvsS1z436rgza_5PdjVRp_E8bz-5O1S_C7TBDDxQ=.a020b690-5e72-441b-922a-e425e15de114@github.com>
Message-ID: <aK24PF0gvPt9xD-Wa_tV8yXcsfwsCUXcu92vyYya3ek=.84cd6d33-a99e-46cb-8081-31f72e8cf3bb@github.com>

On Mon, 24 Mar 2025 13:56:21 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert accidental file change.
>
> Looks good, these locations in the JDK 24 docs indeed have extra braces (besides AbstractTask which is not public API)

@liach thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/24022#issuecomment-2748241211

From naoto at openjdk.org  Mon Mar 24 19:32:19 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Mar 2025 19:32:19 GMT
Subject: <i18n dev> RFR: 8350442: Update copyright
In-Reply-To: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
References: <cneifM5QORloB6I2qGdeCy7YyOuvWh0nHz89vy1vQLs=.6105f832-76f9-4643-8e8b-4e3e3bfc988c@github.com>
Message-ID: <jfvN0b_rpLpQaBUrHd8IvOwUzKK-d9TtzXb-NTgrouI=.7340af08-0865-4c00-94f6-31b5d7bed89e@github.com>

On Thu, 20 Feb 2025 17:01:36 GMT, Ivan ?ipka <isipka at openjdk.org> wrote:

> @naotoj  @coffeys @mahendrachhipa 
> 
> update of copyright years. Details on ticket.

@frkator Just wondering if you forgot to issue `/integrate` command on this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/23714#issuecomment-2749193959

From jlu at openjdk.org  Mon Mar 24 21:26:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Mar 2025 21:26:50 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior for
 reserved pattern letter
Message-ID: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>

Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.

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

Commit messages:
 - Make behavior normative
 - init

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

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

From naoto at openjdk.org  Mon Mar 24 23:04:07 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 24 Mar 2025 23:04:07 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior
 for reserved pattern letter
In-Reply-To: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
Message-ID: <TeQNoDFordrmp8yarJrsBt5WhBxzgfEPJdZoGDgDy7U=.d1bbafa2-7709-48d7-a9c7-21eb304067b4@github.com>

On Mon, 24 Mar 2025 21:21:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.

Looks good

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

> 93:  * {@code 'A'} to {@code 'Z'} and from {@code 'a'} to
> 94:  * {@code 'z'} not in the table below are reserved). Using unquoted reserved
> 95:  * characters in a pattern throws {@code IllegalArgumentException}.

`Using` part could be more specific, ie, in the constructors or `applyPattern()`

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

PR Review: https://git.openjdk.org/jdk/pull/24207#pullrequestreview-2711860724
PR Review Comment: https://git.openjdk.org/jdk/pull/24207#discussion_r2011035210

From jlu at openjdk.org  Mon Mar 24 23:13:48 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Mar 2025 23:13:48 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior
 for reserved pattern letter [v2]
In-Reply-To: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
Message-ID: <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>

> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.

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

  Naoto's review - link the throwing methods/ctor

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24207/files
  - new: https://git.openjdk.org/jdk/pull/24207/files/77c1737d..a80023ed

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

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

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

From jwaters at openjdk.org  Tue Mar 25 11:34:14 2025
From: jwaters at openjdk.org (Julian Waters)
Date: Tue, 25 Mar 2025 11:34:14 GMT
Subject: <i18n dev> RFR: 8342868: Errors related to unused code on
 Windows after 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <pI2RcMsaCSr0iYJVJR2CuHnhqLKaDgC4G7zqT0_3zf8=.1a4e362b-b12d-48c5-8af4-4b43de3d82af@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Keep it open please. Life is not being kind to me at the moment, I apologize for the delays

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2750958007

From acobbs at openjdk.org  Tue Mar 25 14:31:30 2025
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 25 Mar 2025 14:31:30 GMT
Subject: <i18n dev> Integrated: 8351897: Extra closing curly brace typos in
 Javadoc
In-Reply-To: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
References: <XFoWMzOkFcWAQT27BvWMMwXmopTj-NgDUEWc_g-G6q4=.09895d4b-9da7-486c-9ff9-60ec876d3600@github.com>
Message-ID: <vPYQUyD4C1MxMlIZ77BVLBJEWgQ5lFy0D_Kkousk2co=.1324c86c-30b6-440f-869b-d856f52c1ef4@github.com>

On Thu, 13 Mar 2025 01:21:54 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

> This PR fixes minor Javadoc typos in a few `java.base` classes. Extra curly braces have been sneaking in.

This pull request has now been integrated.

Changeset: fe03e2ec
Author:    Archie Cobbs <acobbs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe03e2ecbd5c4d5d06ad1703fa969043d1127c0f
Stats:     14 lines in 5 files changed: 0 ins; 0 del; 14 mod

8351897: Extra closing curly brace typos in Javadoc

Reviewed-by: liach

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

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

From naoto at openjdk.org  Tue Mar 25 15:55:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Mar 2025 15:55:27 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior
 for reserved pattern letter [v2]
In-Reply-To: <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
 <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
Message-ID: <OaCsOJh9QhA8XcLY1XoR3H9WNlI4UyKn7jokvFrVdiE=.5476541a-d7e0-4269-9833-402bf4aaba0d@github.com>

On Mon, 24 Mar 2025 23:13:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - link the throwing methods/ctor

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24207#pullrequestreview-2714311343

From naoto at openjdk.org  Tue Mar 25 15:55:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Mar 2025 15:55:27 GMT
Subject: <i18n dev> Integrated: 8346948: Update CLDR to Version 47.0
In-Reply-To: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
Message-ID: <mBY_K956ERpVjD2nUelerMFPsK3l8qdulv-A2ToE7JU=.b27fef7a-9f4a-486c-b340-f353fe1013e3@github.com>

On Wed, 19 Mar 2025 17:29:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 993eae4a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/993eae4aa591ec9610b9d8bc03382a225c93d844
Stats:     2735 lines in 1109 files changed: 932 ins; 261 del; 1542 mod

8346948: Update CLDR to Version 47.0

Reviewed-by: jlu, joehw

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

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

From naoto at openjdk.org  Tue Mar 25 15:55:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Mar 2025 15:55:26 GMT
Subject: <i18n dev> RFR: 8346948: Update CLDR to Version 47.0 [v2]
In-Reply-To: <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
References: <bDRw_4j0dFzjR0NZrtSP5mpUlebjYmVO4yPWrzivU4Y=.6532b63b-8487-480a-b5a3-78820572a512@github.com>
 <o86sPNcedvXZpHfYBq71i7eZclEQ_DL68d7ze2B6Ke4=.d604c37a-9786-4708-9dbb-da702c4fa992@github.com>
Message-ID: <ui0dzCQPQUAoZNHFYtPOpb_14QzIU98NOFzIL2Jv80M=.49d4950d-971c-4d99-8cfb-60a8adc66b7e@github.com>

On Wed, 19 Mar 2025 17:48:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 47.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright year/bugid update

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/24120#issuecomment-2751731346

From naoto at openjdk.org  Tue Mar 25 16:57:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 25 Mar 2025 16:57:42 GMT
Subject: <i18n dev> RFR: 8352716: (tz) Update Timezone Data to 2025b
Message-ID: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>

Incorporating the latest IANA Time Zone Database (2025b). Manually confirmed the newly introduced time zone stays at the same offset (-03) on/after 2025-04-06:

jshell> ZoneId.of("America/Coyhaique").getRules().getValidOffsets(LocalDateTime.of(2025, 4, 6, 0, 0))
$198 ==> [-03:00]

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

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/24234/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8352716
  Stats: 96 lines in 5 files changed: 77 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/24234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24234/head:pull/24234

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

From coffeys at openjdk.org  Tue Mar 25 17:35:07 2025
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 25 Mar 2025 17:35:07 GMT
Subject: <i18n dev> RFR: 8352716: (tz) Update Timezone Data to 2025b
In-Reply-To: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
References: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
Message-ID: <1saPT0I81Rlu9M8nIt1RWzaO_qG-9j-UxYXikgATZ-c=.9cccef20-f566-4b57-a96b-fe40482a709e@github.com>

On Tue, 25 Mar 2025 16:52:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Incorporating the latest IANA Time Zone Database (2025b). Manually confirmed the newly introduced time zone stays at the same offset (-03) on/after 2025-04-06:
> 
> jshell> ZoneId.of("America/Coyhaique").getRules().getValidOffsets(LocalDateTime.of(2025, 4, 6, 0, 0))
> $198 ==> [-03:00]

LGTM

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24234#pullrequestreview-2714614328

From rriggs at openjdk.org  Tue Mar 25 18:33:08 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Mar 2025 18:33:08 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior
 for reserved pattern letter [v2]
In-Reply-To: <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
 <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
Message-ID: <QBAOxLfKKaa-vXQaZ4ba3qRAiBarRwVv9jxbuS1MoN8=.5f1fb39c-3f36-4d96-9e6f-f502b304e5b0@github.com>

On Mon, 24 Mar 2025 23:13:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - link the throwing methods/ctor

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24207#pullrequestreview-2714818759

From joehw at openjdk.org  Tue Mar 25 22:26:20 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 25 Mar 2025 22:26:20 GMT
Subject: <i18n dev> RFR: 8352716: (tz) Update Timezone Data to 2025b
In-Reply-To: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
References: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
Message-ID: <V0Y7WZgHsPndPq-3U1c1VtQsh3XAI6vyJ7Jy8OgMtjM=.f2436256-c3e8-4481-93e0-72bd5e32e915@github.com>

On Tue, 25 Mar 2025 16:52:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Incorporating the latest IANA Time Zone Database (2025b). Manually confirmed the newly introduced time zone stays at the same offset (-03) on/after 2025-04-06:
> 
> jshell> ZoneId.of("America/Coyhaique").getRules().getValidOffsets(LocalDateTime.of(2025, 4, 6, 0, 0))
> $198 ==> [-03:00]

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24234#pullrequestreview-2715339875

From naoto at openjdk.org  Wed Mar 26 16:12:20 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Mar 2025 16:12:20 GMT
Subject: <i18n dev> Integrated: 8352716: (tz) Update Timezone Data to 2025b
In-Reply-To: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
References: <PqBiSNe4b2Yeud1H7cpMZfY1P2FU2Lfj8Y1Pn_qQNx0=.94a5b5e8-530b-423c-9599-f3ff2ef86b25@github.com>
Message-ID: <4oIgfDnjf5fylDdbGCf5JrPntWgK9UdG-B-c6W11q-8=.95b2b5c5-5b84-4034-bba9-05db0209e55e@github.com>

On Tue, 25 Mar 2025 16:52:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Incorporating the latest IANA Time Zone Database (2025b). Manually confirmed the newly introduced time zone stays at the same offset (-03) on/after 2025-04-06:
> 
> jshell> ZoneId.of("America/Coyhaique").getRules().getValidOffsets(LocalDateTime.of(2025, 4, 6, 0, 0))
> $198 ==> [-03:00]

This pull request has now been integrated.

Changeset: 1d205f5f
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d205f5f0704f251eb68165f3caf1e70d542ae63
Stats:     96 lines in 5 files changed: 77 ins; 4 del; 15 mod

8352716: (tz) Update Timezone Data to 2025b

Reviewed-by: coffeys, joehw

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

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

From jlu at openjdk.org  Wed Mar 26 20:35:39 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Mar 2025 20:35:39 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about j.text.DecimalFormat
 digits during parsing
Message-ID: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>

Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.

There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.

Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Wed Mar 26 21:48:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Mar 2025 21:48:09 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing
In-Reply-To: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
Message-ID: <iEAgwqVCP9VJqJRrab2URxWZ6evGHIME5u24b3xRmLQ=.85b922d2-3e30-40ee-9198-390025493573@github.com>

On Wed, 26 Mar 2025 20:31:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
> 
> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
> 
> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.

Looks good

src/java.base/share/classes/java/text/DecimalFormat.java line 4047:

> 4045:      * #setMaximumIntegerDigits(int)} or {@link #applyPattern(String)}.
> 4046:      * See the {@link ##patterns Pattern Section} for comprehensive rules regarding
> 4047:      * maximum integer digits in patterns.

This part only exists in this method and other getter methods do not have one. Either removing this (as this is explained in the class description), or add it to all other getters would be consistent ( the former is better IMO).

src/java.base/share/classes/java/text/NumberFormat.java line 938:

> 936:      * also be set to the new value.
> 937:      *
> 938:      * @apiNote

I think this is `@implNote` as this is for subclass implemntors, not the users of this API. (apply to other locations)

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

PR Review: https://git.openjdk.org/jdk/pull/24265#pullrequestreview-2718678916
PR Review Comment: https://git.openjdk.org/jdk/pull/24265#discussion_r2015035862
PR Review Comment: https://git.openjdk.org/jdk/pull/24265#discussion_r2015037836

From jlu at openjdk.org  Wed Mar 26 22:17:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Mar 2025 22:17:19 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing
In-Reply-To: <iEAgwqVCP9VJqJRrab2URxWZ6evGHIME5u24b3xRmLQ=.85b922d2-3e30-40ee-9198-390025493573@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <iEAgwqVCP9VJqJRrab2URxWZ6evGHIME5u24b3xRmLQ=.85b922d2-3e30-40ee-9198-390025493573@github.com>
Message-ID: <h47jzWN9oPD0nrcMhSWjRDkt3JVW6VdTQ8CrNRfSco4=.34f0cd7b-3afe-4151-a4eb-e7cc1520955d@github.com>

On Wed, 26 Mar 2025 21:41:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
>> 
>> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
>> 
>> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
>> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
>> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 4047:
> 
>> 4045:      * #setMaximumIntegerDigits(int)} or {@link #applyPattern(String)}.
>> 4046:      * See the {@link ##patterns Pattern Section} for comprehensive rules regarding
>> 4047:      * maximum integer digits in patterns.
> 
> This part only exists in this method and other getter methods do not have one. Either removing this (as this is explained in the class description), or add it to all other getters would be consistent ( the former is better IMO).

That commentary is only in this method because of the non-obvious behavior for the maximum integer digits. (The pattern does not change the `maximumIntegerDigits`). Since not all users may read that section in the class description, that is why this method has the explicit call-out, so I think it may be beneficial to keep this wording. I am fine either way, if you don't think it's worth it, I'll remove.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24265#discussion_r2015068415

From naoto at openjdk.org  Wed Mar 26 22:38:15 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 26 Mar 2025 22:38:15 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing
In-Reply-To: <h47jzWN9oPD0nrcMhSWjRDkt3JVW6VdTQ8CrNRfSco4=.34f0cd7b-3afe-4151-a4eb-e7cc1520955d@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <iEAgwqVCP9VJqJRrab2URxWZ6evGHIME5u24b3xRmLQ=.85b922d2-3e30-40ee-9198-390025493573@github.com>
 <h47jzWN9oPD0nrcMhSWjRDkt3JVW6VdTQ8CrNRfSco4=.34f0cd7b-3afe-4151-a4eb-e7cc1520955d@github.com>
Message-ID: <vr8fEBMG8U_nqCFtY5lwRTFPJCbfQsGo8cNjuafG7Wo=.94cfda38-1115-4566-966d-38fe724b84e3@github.com>

On Wed, 26 Mar 2025 22:14:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DecimalFormat.java line 4047:
>> 
>>> 4045:      * #setMaximumIntegerDigits(int)} or {@link #applyPattern(String)}.
>>> 4046:      * See the {@link ##patterns Pattern Section} for comprehensive rules regarding
>>> 4047:      * maximum integer digits in patterns.
>> 
>> This part only exists in this method and other getter methods do not have one. Either removing this (as this is explained in the class description), or add it to all other getters would be consistent ( the former is better IMO).
>
> That commentary is only in this method because of the non-obvious behavior for the maximum integer digits. (The pattern does not change the `maximumIntegerDigits`). Since not all users may read that section in the class description, that is why this method has the explicit call-out, so I think it may be beneficial to keep this wording. I am fine either way, if you don't think it's worth it, I'll remove.

If there is some oddity in this getter, would it be helpful if we add more to it, eg, "Unlike other getter methods..."?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24265#discussion_r2015084203

From jlu at openjdk.org  Wed Mar 26 23:05:46 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Mar 2025 23:05:46 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing [v2]
In-Reply-To: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
Message-ID: <7sWJN1g4-AZsDNd0EpEfzwkn2SdcZV3nvezZks_qJEY=.c52213b8-5bb5-4070-96b1-2cc5e3a0f5e7@github.com>

> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
> 
> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
> 
> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.

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

  Naoto's review: apiN -> implN. Rewording of maxintdig callout

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24265/files
  - new: https://git.openjdk.org/jdk/pull/24265/files/19d05f9c..5fc8f37f

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

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

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

From jlu at openjdk.org  Wed Mar 26 23:05:46 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Mar 2025 23:05:46 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing [v2]
In-Reply-To: <vr8fEBMG8U_nqCFtY5lwRTFPJCbfQsGo8cNjuafG7Wo=.94cfda38-1115-4566-966d-38fe724b84e3@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <iEAgwqVCP9VJqJRrab2URxWZ6evGHIME5u24b3xRmLQ=.85b922d2-3e30-40ee-9198-390025493573@github.com>
 <h47jzWN9oPD0nrcMhSWjRDkt3JVW6VdTQ8CrNRfSco4=.34f0cd7b-3afe-4151-a4eb-e7cc1520955d@github.com>
 <vr8fEBMG8U_nqCFtY5lwRTFPJCbfQsGo8cNjuafG7Wo=.94cfda38-1115-4566-966d-38fe724b84e3@github.com>
Message-ID: <K-sCMhz3PWtztoGBOTJlIu8RvBtWi7UTZY8ZKFzOqxU=.3a076f59-d847-48c3-8b11-7e7729f67d2a@github.com>

On Wed, 26 Mar 2025 22:35:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> That commentary is only in this method because of the non-obvious behavior for the maximum integer digits. (The pattern does not change the `maximumIntegerDigits`). Since not all users may read that section in the class description, that is why this method has the explicit call-out, so I think it may be beneficial to keep this wording. I am fine either way, if you don't think it's worth it, I'll remove.
>
> If there is some oddity in this getter, would it be helpful if we add more to it, eg, "Unlike other getter methods..."?

That's a good point, it should be phrased as a call out the unique behavior. New wording is also more concise. Changed in https://github.com/openjdk/jdk/pull/24265/commits/5fc8f37f951555a48b78a133a528e298faabd9b7.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24265#discussion_r2015104518

From naoto at openjdk.org  Thu Mar 27 00:40:07 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 27 Mar 2025 00:40:07 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing [v2]
In-Reply-To: <7sWJN1g4-AZsDNd0EpEfzwkn2SdcZV3nvezZks_qJEY=.c52213b8-5bb5-4070-96b1-2cc5e3a0f5e7@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <7sWJN1g4-AZsDNd0EpEfzwkn2SdcZV3nvezZks_qJEY=.c52213b8-5bb5-4070-96b1-2cc5e3a0f5e7@github.com>
Message-ID: <iZpgqKWfftsg_al6j4JrsNdYRzjGv7rf4dHZrYx5lpA=.84f8ba07-343b-44d7-9a6e-617a1ab6dedd@github.com>

On Wed, 26 Mar 2025 23:05:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which clarifies the behavior for integer and fraction limits in NumberFormat and implementing classes. An associated CSR is filed.
>> 
>> There have been a few bugs submitted which indicate a misconception that these limits impact parsing. The actual behavior is that these limits only affect formatting. The specification is vague regarding this, and can be explicitly updated to eliminate confusion. As the implementing classes are updated to use `inheritDoc`, some shuffling around in the method specs are included in this change as well.
>> 
>> Alternatively I considered making this change as implementation specific to DecimalFormat and CompactNumberFormat only. (i.e. leave flexibility for other NumberFormat subclasses to define their own behavior on whether the limits affect parsing.) I am open to this option as well, but initially decided against it as 
>> 1) Unlike formatting, it seems like a rare use case that you would want to suppress the range of digits of accepted during parsing. `setParseIntegerOnly()` already provides functionality to toggle between integer and fraction parsing.
>> 2) The limits affecting formatting only has been the long-standing behavior for all the subclasses of NumberFormat provided by the OpenJDK reference implementation.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review: apiN -> implN. Rewording of maxintdig callout

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24265#pullrequestreview-2718912163

From swen at openjdk.org  Thu Mar 27 05:49:35 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 27 Mar 2025 05:49:35 GMT
Subject: <i18n dev> RFR: 8349189: Speed up DateTime parse & format via
 Class File API [v12]
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <14RPo58zhyI8f1q73ZKijB9pj_HxyIqicLOeoxforgA=.1dd516d9-eff7-488c-b66c-34d40e3417fd@github.com>

> By using the Class File API to dynamically generate a CompositePrinterParser, and defining DateTimePrinterParser[] printerParsers as a specific field, C2 can do TypeProfile optimization.
> 
> Since the CompositePrinterParser is generated based on the pattern, we can make the following optimizations:
> 
> 1. For example, for the parse and print of Month/DayOfMonth/Hour/Minute/Second with a fixed length of 2, do targeted parse and print optimization.
> 
> 2. Parse uses LocalDate/LocalTime/LocalDateTime/OffsetDateTime for TemporalQuery to avoid the overhead of constructing DateTimeParseContext.
> 
> These optimizations can significantly improve performance, with more than 100% performance improvement in many scenarios.

Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 26 commits:

 - Merge remote-tracking branch 'upstream/master' into datetime_fmt_202502
   
   # Conflicts:
   #	src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
 - more use getInt & add more test
 - refactor test
 - more test
 - code style
 - code style
 - add instance test
 - add test and bug fix
 - speed up format via wrapper
 - use get & formatInt
 - ... and 16 more: https://git.openjdk.org/jdk/compare/24833403...c8528dd8

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

Changes: https://git.openjdk.org/jdk/pull/23384/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23384&range=11
  Stats: 2090 lines in 9 files changed: 1948 ins; 88 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/23384.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/23384/head:pull/23384

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

From jlu at openjdk.org  Thu Mar 27 20:43:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Mar 2025 20:43:21 GMT
Subject: <i18n dev> Integrated: 5061061: SimpleDateFormat: unspecified
 behavior for reserved pattern letter
In-Reply-To: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
Message-ID: <Ky5-b7UayCO12kvrpDnLq5V1qMjx8e_M_jNnmHYTuWg=.51e5f895-16f9-416b-83b9-35ce8b71d83f@github.com>

On Mon, 24 Mar 2025 21:21:20 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.

This pull request has now been integrated.

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

5061061: SimpleDateFormat: unspecified behavior for reserved pattern letter

Reviewed-by: naoto, rriggs

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

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

From jlu at openjdk.org  Thu Mar 27 20:43:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 27 Mar 2025 20:43:21 GMT
Subject: <i18n dev> RFR: 5061061: SimpleDateFormat: unspecified behavior
 for reserved pattern letter [v2]
In-Reply-To: <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
References: <lCGYL2QDyRd0rBNui7LgAT1nQrQjZfQYL9NZV-wSijQ=.155cf52e-a189-4855-a9f5-1d00ac0a80f1@github.com>
 <uBaD6fZjDnqqRivoCiCesr5sn2K1o_5xOrce1e1udoM=.496f9ea5-9d12-4b08-aeb6-888edd64f7d7@github.com>
Message-ID: <Rd1Zro9_SO9KgBaeTKPpX9iEifNbS8nWk3IU_Jx6No4=.186240e5-8e8c-46dc-8515-35d7128c9405@github.com>

On Mon, 24 Mar 2025 23:13:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this specification update for `SimpleDateFormat` which explicitly specifies the behavior for 'reserved' pattern letters. This is a specification update and has the potential low risk of making an implementation non-compliant. Thus, an associated CSR is filed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto's review - link the throwing methods/ctor

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24207#issuecomment-2759424712

From naoto at openjdk.org  Fri Mar 28 20:23:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 28 Mar 2025 20:23:53 GMT
Subject: <i18n dev> RFR: 8353118: Deprecate the use of
 `java.locale.useOldISOCodes` system property
Message-ID: <Y5lKt8Bm_eKhppijJpIGDp4pP5uegQv_fmye2xVG7q8=.38b5ddfc-7caf-4f4e-a891-fbfdd077b0b2@github.com>

Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to true (no behavioral change except the warning). The plan is eventually to remove it after JDK25. A corresponding CSR has been drafted.

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

Commit messages:
 - initial commit

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

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

From iris at openjdk.org  Fri Mar 28 20:51:42 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 28 Mar 2025 20:51:42 GMT
Subject: <i18n dev> RFR: 8353118: Deprecate the use of
 `java.locale.useOldISOCodes` system property
In-Reply-To: <Y5lKt8Bm_eKhppijJpIGDp4pP5uegQv_fmye2xVG7q8=.38b5ddfc-7caf-4f4e-a891-fbfdd077b0b2@github.com>
References: <Y5lKt8Bm_eKhppijJpIGDp4pP5uegQv_fmye2xVG7q8=.38b5ddfc-7caf-4f4e-a891-fbfdd077b0b2@github.com>
Message-ID: <-B4LyhpLXLhGZzNDH9zTQquAiPr-6gFdp99S7Mh1Rb8=.117cf5db-d9bf-4fa9-92ac-1ab4696f7215@github.com>

On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to true (no behavioral change except the warning). The plan is eventually to remove it after JDK25. A corresponding CSR has been drafted.

Looks good.

Associated CSR Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24302#pullrequestreview-2726735221

From jlu at openjdk.org  Mon Mar 31 16:39:28 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 31 Mar 2025 16:39:28 GMT
Subject: <i18n dev> RFR: 8353118: Deprecate the use of
 `java.locale.useOldISOCodes` system property
In-Reply-To: <Y5lKt8Bm_eKhppijJpIGDp4pP5uegQv_fmye2xVG7q8=.38b5ddfc-7caf-4f4e-a891-fbfdd077b0b2@github.com>
References: <Y5lKt8Bm_eKhppijJpIGDp4pP5uegQv_fmye2xVG7q8=.38b5ddfc-7caf-4f4e-a891-fbfdd077b0b2@github.com>
Message-ID: <K2ZrbBlG2yckzMvwBm9zpuDpY63gauVhyp-8g9WdRyM=.75d97a9c-e651-4993-9c37-24fd4837bb83@github.com>

On Fri, 28 Mar 2025 20:17:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Proposing to remove the `java.locale.useOldISOCodes` system property. This property is for backward compatibility introduced back in JDK17 and I believe it is now fine to remove it. In this PR targeting JDK25, it emits a deprecate-for-removal warning on startup if the system property is set to true (no behavioral change except the warning). The plan is eventually to remove it after JDK25. A corresponding CSR has been drafted.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/24302#pullrequestreview-2729873125