From liach at openjdk.org  Thu May  1 14:01:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 1 May 2025 14:01:55 GMT
Subject: <i18n dev> RFR: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <t-F0z47daZdDhKEPS5QkWmUScRwUtzCB0bQk9whzRJc=.961ae188-ed08-49a0-aba4-f77fd92180e9@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

Thanks for this cleanup, indeed equivalent.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809839693

From rriggs at openjdk.org  Thu May  1 13:55:46 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 1 May 2025 13:55:46 GMT
Subject: <i18n dev> RFR: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <ahZq9FgLjDCY-rUhZEptP6qMgfzQYWUp2SDSybsm8dc=.fc91b02a-340d-4fde-af76-95dc3d1bdc57@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

lgltm

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24971#pullrequestreview-2809829827

From swen at openjdk.org  Thu May  1 15:49:53 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 1 May 2025 15:49:53 GMT
Subject: <i18n dev> Integrated: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <oVLrM8_PSiIa83nY13nrBKPGBM13bVnOmiaIiYKcNt8=.f61becd6-edde-45fb-bd81-486df9aee5c1@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

This pull request has now been integrated.

Changeset: 2ad639f1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ad639f1b33fcd8e218e8ad549caf32024a36cb2
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8356021: Use Double::hashCode in java.util.Locale::hashCode

Reviewed-by: rriggs, liach

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

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

From naoto at openjdk.org  Thu May  1 16:29:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 1 May 2025 16:29:50 GMT
Subject: <i18n dev> RFR: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
Message-ID: <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>

On Wed, 30 Apr 2025 18:01:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
> 
> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.

Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845189930

From swen at openjdk.org  Thu May  1 18:16:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 1 May 2025 18:16:50 GMT
Subject: <i18n dev> RFR: 8356021: Use Double::hashCode in
 java.util.Locale::hashCode
In-Reply-To: <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>
References: <RmUa-pqbPbCVv3AvflAYEIZ6nIqbdq9rdeKmHnYLPeE=.0e720ac8-8030-4963-b1e8-9e5f7ac12046@github.com>
 <Axi4jX3mW1MR-2PyX-XIkWaxBZukzivV_aXtvkwrGok=.c75649a5-b82e-4e7d-a2d1-1317b5232705@github.com>
Message-ID: <9DKNGgorVgpZOig2AsE3iVx3ZsexlX9r7WDTbBsY6lA=.8b79a8b2-4a61-4d66-99ab-a254adb09fb0@github.com>

On Thu, 1 May 2025 16:27:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Similar to #24959, java.util.Locale.hashCode can also make the same improvement.
>> 
>> Replace manual bitwise operations in hashCode implementations of java.util.Locale with Double::hashCode.
>
> Thanks for the fix. Even though the fix is trivial and small, please keep the PR open at least for 24 hours so that every region of the globe can see the fix.

@naotoj Thank you for your reminder. There is a problem with GitHub's prompt. It shows yesterday in less than 24 hours. I will avoid this problem next time.

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

PR Comment: https://git.openjdk.org/jdk/pull/24971#issuecomment-2845399910

From jlu at openjdk.org  Fri May  2 15:53:22 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 15:53:22 GMT
Subject: <i18n dev> RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out
Message-ID: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>

Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.

This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.

Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Fri May  2 17:18:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 May 2025 17:18:51 GMT
Subject: <i18n dev> RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <Iomf-tx3GsG0uRH8wf9_LWEYYkABjleMzZB8s4fnHlE=.271f762d-407a-425a-87f0-be18f705cd54@github.com>

On Fri, 2 May 2025 15:49:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

Looks good.

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 61:

> 59:      * This is not an exhaustive test. Such a test would require iterating (1000x1000)+
> 60:      * inputs. Instead, we check against Japanese lang locales which guarantees
> 61:      * we will run into cases where the CLDR is not preferred and the SPI has defined

It would be helpful to mention why CLDR is not the preferred provider (as the SPI impl has variants of the Japanese locale)

test/jdk/java/util/PluggableLocale/LocaleNameProviderTest.java line 92:

> 90:         String jresctry = null;
> 91:         String jresvrnt = null;
> 92:         if (!lang.equals("")) {

Can be replaced with `isEmpty()`

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

PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812517069
PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071912893
PR Review Comment: https://git.openjdk.org/jdk/pull/25009#discussion_r2071918059

From jlu at openjdk.org  Fri May  2 17:39:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 17:39:08 GMT
Subject: <i18n dev> RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2]
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

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

  Naoto review - update comment, isEmpty()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25009/files
  - new: https://git.openjdk.org/jdk/pull/25009/files/c3e77cde..579c1ebe

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

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

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

From naoto at openjdk.org  Fri May  2 18:42:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 2 May 2025 18:42:45 GMT
Subject: <i18n dev> RFR: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out [v2]
In-Reply-To: <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
 <ny4l-50hJsEa69IOxJkcdtPOr1l8uv-3gmG9kAXRvSE=.4fbd4581-580c-41ca-9af2-777b1b0f05b4@github.com>
Message-ID: <vg2atXbtnYPHwgpDqZLmnK05laqPQFY630_MKr1pYoc=.9f040ee0-a28d-4259-8c7c-2ad93229c422@github.com>

On Fri, 2 May 2025 17:39:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
>> 
>> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
>> 
>> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Naoto review - update comment, isEmpty()

LGTM. Thanks for simplifying the test

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25009#pullrequestreview-2812676717

From jlu at openjdk.org  Fri May  2 20:55:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 2 May 2025 20:55:54 GMT
Subject: <i18n dev> RFR: 8356096: ISO 4217 Amendment 179 Update
Message-ID: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>

Please review this PR which implements ISO 4217 update 179.

The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

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

Commit messages:
 - init

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

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

From duke at openjdk.org  Sun May  4 19:45:56 2025
From: duke at openjdk.org (duke)
Date: Sun, 4 May 2025 19:45:56 GMT
Subject: <i18n dev> Withdrawn: 8349189: Speed up DateTime parse & format via
 Class File API
In-Reply-To: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
References: <iChvwEtPctCMp5okK1K8tMj-6XSS7GS9VqfdfhkgOk0=.c7f3307b-22ce-45a6-a3b5-0bac4bbfba7a@github.com>
Message-ID: <nrEdd0NZNzebZAyRF8vBaZdl46PnU1pLhyqFbA-ujEE=.c17aa894-9538-424f-ac71-6cca2a509b8f@github.com>

On Fri, 31 Jan 2025 10:29:53 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.

This pull request has been closed without being integrated.

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

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

From jlu at openjdk.org  Mon May  5 16:45:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 5 May 2025 16:45:51 GMT
Subject: <i18n dev> Integrated: 8356040:
 java/util/PluggableLocale/LocaleNameProviderTest.java timed out
In-Reply-To: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
References: <ZlNw-uu8c-LYrPGPOzC2ab4YHelGWdKD0mo12m3CFT0=.d43f7119-3594-48aa-90ed-d92c502ee3a5@github.com>
Message-ID: <k1wJgWgFmKlsGQeZACp3_PbV-u1MA4p55eph99f0xeA=.4ac45fb8-9056-44df-982f-16bbb8a74c3b@github.com>

On Fri, 2 May 2025 15:49:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which reduces the amount of combinations tested by `LocaleNameProviderTest`.
> 
> This test was exhaustively testing over 1000x1000 `Locale` combinations which was expensive and caused a timeout in tier 5. Narrowing down the tested locales to Japanese language ones can reduce our tested input to 9x9 and provides most of the same value the test previously did. (Since our SPI provider has defined preferred Japanese Locale name values.) This change also refactors the test to use JUnit. The test now runs around ~20 times faster.
> 
> Most of the diff is attributed to separating the method source from the test itself. But notice the filtering of `Locale`s done on `availloc` and `jreImplLoc`.

This pull request has now been integrated.

Changeset: 32f67a3e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/32f67a3e38be807164435ea0841c01d2b7c73652
Stats:     133 lines in 1 file changed: 64 ins; 48 del; 21 mod

8356040: java/util/PluggableLocale/LocaleNameProviderTest.java timed out

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Mon May  5 17:22:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 5 May 2025 17:22:45 GMT
Subject: <i18n dev> RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <TMoKyst2Q91UwdgX-DfV0lLk5cB6RTsQKsjk_PEbM4g=.904b3259-8b16-4a24-b014-cbbe2796162f@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815515425

From iris at openjdk.org  Mon May  5 17:31:45 2025
From: iris at openjdk.org (Iris Clark)
Date: Mon, 5 May 2025 17:31:45 GMT
Subject: <i18n dev> RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <Ry5_4qxqnprIddsFyz33W34DvHwJ9Q8eCt0JpxdBAps=.10370f86-0a5d-4d46-931b-cb52491d0b8f@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25014#pullrequestreview-2815543817

From ihse at openjdk.org  Tue May  6 14:16:32 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 14:16:32 GMT
Subject: <i18n dev> RFR: 8354273: Replace even more Unicode characters
 with ASCII [v3]
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>

> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

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

 - Merge branch 'master' into restore-more-ascii
 - Remove incorrectly copied "?anchor"
 - 8354273: Restore even more pointless unicode characters to ASCII

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24567/files
  - new: https://git.openjdk.org/jdk/pull/24567/files/876708c2..a07ef96d

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

  Stats: 273049 lines in 2453 files changed: 80961 ins; 183018 del; 9070 mod
  Patch: https://git.openjdk.org/jdk/pull/24567.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24567/head:pull/24567

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

From ihse at openjdk.org  Tue May  6 15:12:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:12:19 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
 <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
 <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
Message-ID: <9Q_tHeUczynfbPen9yg52qG1NY6z_jVXFgIEnPcsh84=.7544bce2-ed3d-47fe-bb00-5c23bad638a8@github.com>

On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)
>> 
>> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README.
>> 
>> Is there some specific problem you are worried about on Windows that you were thinking about?
>
>> Is there some specific problem you are worried about on Windows that you were thinking about?
> 
> I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas.

@naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale.

I'll ping Yi Yang who was behind https://github.com/openjdk/jdk/pull/3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. 

@y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2854924350

From ihse at openjdk.org  Tue May  6 15:25:43 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:25:43 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v4]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <j5PlYeoS1GTp8KizABIEWkGmacjxdU1cVbXNFU6Q05Y=.46cca0c8-7e0b-4eab-b59b-b6920fad8557@github.com>

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/452f42dc..9ce59e1f

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

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

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

From ihse at openjdk.org  Tue May  6 15:29:27 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:29:27 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
Message-ID: <0yCHTP7eQgosQh4hZ5khOXUulKb6gRx_uCr7Rl785Zg=.16873d03-5d82-49f0-9ad4-26330b3282d0@github.com>

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Also document UTF-8 requirements (solves JDK-8338973)
>>  - Let configure only accept utf-8 locales
>>  - Address review comments from Kim
>
> make/autoconf/basic.m4 line 155:
> 
>> 153:       else
>> 154:         AC_MSG_RESULT([no UTF-8 locale found])
>> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])
> 
> Seems we run into this 'else' part  on  AIX
> 
> 
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> 
> maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

@MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2075728219

From ihse at openjdk.org  Tue May  6 15:39:04 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:39:04 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

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

 - Merge branch 'master' into go-full-utf8
 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error
 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim
 - Also tell javadoc that we have utf-8 now
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - Don't convert properties files to iso-8859-1.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/e43ea2cd...bea19a70

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24574/files
  - new: https://git.openjdk.org/jdk/pull/24574/files/9ce59e1f..bea19a70

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

  Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

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

From ihse at openjdk.org  Tue May  6 15:39:24 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:39:24 GMT
Subject: <i18n dev> RFR: 8354273: Replace even more Unicode characters
 with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <NO4E3P79QlBsrC6zcQwwbnA4FgXHvAaMZXAwucxFtps=.7f0248af-a382-4f2d-a5c8-ebb1af37e5bd@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

Ping?

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

PR Comment: https://git.openjdk.org/jdk/pull/24567#issuecomment-2855052189

From ihse at openjdk.org  Tue May  6 15:46:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 15:46:03 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v2]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

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

 - Merge branch 'master' into unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/ae1166af..694b33dc

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

  Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

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

From naoto at openjdk.org  Tue May  6 16:45:26 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 16:45:26 GMT
Subject: <i18n dev> RFR: 8354273: Replace even more Unicode characters
 with ASCII [v3]
In-Reply-To: <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
 <Ynl7ATLqF5wm7um0BI3RwZC2IO9VObO1blOBXNny1Sk=.0fedb3c5-dd77-4123-82a8-ecde62b4f01f@github.com>
Message-ID: <i7yFd48vuJdikLZgeiz-IA4ww7ecKEDHrgLWiE_P7Oo=.fc92ab9b-8fc2-480d-81e5-61be832f6014@github.com>

On Tue, 6 May 2025 14:16:32 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge branch 'master' into restore-more-ascii
>  - Remove incorrectly copied "?anchor"
>  - 8354273: Restore even more pointless unicode characters to ASCII

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24567#pullrequestreview-2818989660

From naoto at openjdk.org  Tue May  6 17:21:18 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 17:21:18 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v2]
In-Reply-To: <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
Message-ID: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>

On Tue, 6 May 2025 15:46:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
>> 
>> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
>> 
>> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
>> 
>> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - Merge branch 'master' into unicode-sequence-in-comments
>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters

src/java.base/share/classes/java/text/Collator.java line 141:

> 139:      * considered significant during comparison. The assignment of strengths
> 140:      * to language features is locale dependent. A common example is for
> 141:      * different accented forms of the same base letter ("a" vs "?") to be

Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:

> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
> 593:         //
> 594:         // String:              A     a     B   ?

Maybe "? (\u00e9, e-acute)"?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075933987
PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075935811

From erikj at openjdk.org  Tue May  6 17:26:23 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 6 May 2025 17:26:23 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <IKLgNAus-pIoBbMxsqdXHglNuc_uwV9gCgqLhddOxbs=.a3c0e925-af6b-4fcb-9520-5f2ed471cf0b@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/e6fcaea5...bea19a70

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2819093476

From ihse at openjdk.org  Tue May  6 18:02:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:02:19 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>

On Tue, 6 May 2025 17:15:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/Collator.java line 141:
> 
>> 139:      * considered significant during comparison. The assignment of strengths
>> 140:      * to language features is locale dependent. A common example is for
>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
> 
> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.

I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).

If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 

But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2075997573

From ihse at openjdk.org  Tue May  6 18:03:22 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 6 May 2025 18:03:22 GMT
Subject: <i18n dev> Integrated: 8354273: Replace even more Unicode
 characters with ASCII
In-Reply-To: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
References: <lAPeufGi1EtPg5xe5fSfqHW1bwqz9SYYN6GthGqVMJQ=.4c9f7036-82d9-4644-9bc7-4c05bf7bf1eb@github.com>
Message-ID: <ozQlBoLORphUUvXLzjs_gDH9cMgvcJVlVzgbt3b6pR0=.df8da50a-67f9-4ee4-b87f-52b49445cefb@github.com>

On Thu, 10 Apr 2025 10:18:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As a follow-up to [JDK-8354213](https://bugs.openjdk.org/browse/JDK-8354213), I found some additional places where unicode characters are unnecessarily used instead of pure ASCII.

This pull request has now been integrated.

Changeset: 08dd4a75
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/08dd4a75c5b751a66d2e088b0ec9c6d6c443c14a
Stats:     11 lines in 8 files changed: 0 ins; 1 del; 10 mod

8354273: Replace even more Unicode characters with ASCII

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Tue May  6 18:09:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 6 May 2025 18:09:25 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v2]
In-Reply-To: <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
 <05oLqW_SUMUc1lusuWCbsJD_BL9g6or613do3-Dwrug=.bfcb16e9-169d-4a61-8b42-61333cceda66@github.com>
Message-ID: <g1nEEI-RAaG_MRVesbDb13DDKf_oe49wObM9oeXSHzM=.864f4b77-66e6-48e2-a021-8348550d23ec@github.com>

On Tue, 6 May 2025 17:59:18 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/Collator.java line 141:
>> 
>>> 139:      * considered significant during comparison. The assignment of strengths
>>> 140:      * to language features is locale dependent. A common example is for
>>> 141:      * different accented forms of the same base letter ("a" vs "?") to be
>> 
>> Since this (and the other one in RuleBasedCollator) is in the explanation of text handling, I think keeping the original code point makes sense. So I'd have both UTF-8 string and its Unicode escape notation here.
>
> I'm not sure what you mean by "both" here. Do you mean something along the lines of `? (\u00e9, e-acute)` as you suggested below? An additional complication here is that this is part of a javadoc block. I assumed (but must admit that I have not checked) that the `\u00E4` notation will be replaced with unicode characters by Javadoc in the generated html. If so, there should be no difference in the generated javadoc between the original `"\u00E4"` and my suggested patch `"?"`. (There is a change for someone reading the code directly in Collator.java, though).
> 
> If I am right, and if you want the generated Javadoc to contain `\u00E4`, I assume you would need to escape the backslash. 
> 
> But then again, perhaps I am not correct and javadoc keeps the `\u00E4` as a literal. I'd have to check that.

Yes, I meant literally `\u00e9` or `\u00E4`, but I think it is better described as `U+00E9` emphasizing the code point. So in this case, I'd suggest

"a" vs "?" (U+00E9)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2076008258

From jlu at openjdk.org  Tue May  6 18:30:18 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 May 2025 18:30:18 GMT
Subject: <i18n dev> RFR: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <GYgygbtYt8IzxZ3zeYidNd8LjZaIv_D08fbesCTlOp0=.3d74dbe3-5e45-4c25-87fb-e6de2f0a5afe@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

Thanks for reviewing.

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

PR Comment: https://git.openjdk.org/jdk/pull/25014#issuecomment-2855531302

From jlu at openjdk.org  Tue May  6 18:30:19 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 6 May 2025 18:30:19 GMT
Subject: <i18n dev> Integrated: 8356096: ISO 4217 Amendment 179 Update
In-Reply-To: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
References: <t_HZGUxyI7nw6rIYMbN1LO2PBJpI3KMqrc7IJHvY2_4=.ad7fec4a-9966-48b5-abfe-e55f9311f65c@github.com>
Message-ID: <iQRC1oOGdik853F2QycpQ2Kdi047Zbd80ley1eds_C4=.df6b00ed-25a5-4ba7-ab01-6e639fb22628@github.com>

On Fri, 2 May 2025 20:51:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which implements ISO 4217 update 179.
> 
> The _Arab Accounting Dinar_ currency is added under an _agency_, (not _country_) entity. As a result it is not added as an entry in the country to currency mapping in `currencyData.properties`. It has a numeric code of 396, and minor units of 2 (so it is not added to any of the `minorX` entries in `currencyData.properties`).

This pull request has now been integrated.

Changeset: 0cb355ee
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb355ee921183423c8ffc44491f428c49c62c28
Stats:     11 lines in 4 files changed: 2 ins; 0 del; 9 mod

8356096: ISO 4217 Amendment 179 Update

Reviewed-by: naoto, iris

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

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

From yyang at openjdk.org  Wed May  7 01:43:18 2025
From: yyang at openjdk.org (Yi Yang)
Date: Wed, 7 May 2025 01:43:18 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <L61KEZBpl0QV70RZVdSL3fo8R_sAE5WFC5BYK7R4_dg=.0d304f25-bc33-4f66-8f2e-85cda92cb8d4@github.com>
 <j0CHZTYVTsJKo4n5PTtDk23ZVbrwiELWAL9qOrX95GE=.fe1d18fe-c312-47c7-82b6-f6d1780024cc@github.com>
 <TDmCfGJjSU6S6OtslOdj06Mx2-15BuufvsalEcQWt7Q=.df27883d-e6f4-48e5-82ed-9ad2be53340e@github.com>
Message-ID: <iKAMfZmlpXTmnJLgCGhdewo9fZ55a4mZldY0jBNJ-28=.8ba2b92f-9305-4004-8940-f5af4ac79dcb@github.com>

On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment)
>> 
>> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README.
>> 
>> Is there some specific problem you are worried about on Windows that you were thinking about?
>
>> Is there some specific problem you are worried about on Windows that you were thinking about?
> 
> I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas.

> @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale.
> 
> I'll ping Yi Yang who was behind #3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before.
> 
> @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale?

Sorry, I haven't worked on JDK for a while. Maybe @Glavo?

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2856775920

From mbaesken at openjdk.org  Wed May  7 07:23:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 May 2025 07:23:16 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v3]
In-Reply-To: <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Zi_WJQ3MeHDGOXFqZUUJP1lcmn-NcAAgqLMWwVkuwNI=.f98534ce-4730-47b1-8283-cd01361130bb@github.com>
 <mv1LIyvIryUorv8s6UP5jSqhSqj14dNOUEF4TIpQC84=.fd0a5b7d-4cf1-42ab-bd17-615c6fc913a9@github.com>
Message-ID: <xu85M14VHYRGCeJ-RrzVxDVp6G6xSshwxjWx245axMo=.2524f3b6-5526-4241-9b4b-bd3195ebb56b@github.com>

On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Also document UTF-8 requirements (solves JDK-8338973)
>>  - Let configure only accept utf-8 locales
>>  - Address review comments from Kim
>
> make/autoconf/basic.m4 line 155:
> 
>> 153:       else
>> 154:         AC_MSG_RESULT([no UTF-8 locale found])
>> 155:         AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.])
> 
> Seems we run into this 'else' part  on  AIX
> 
> 
> checking for locale to use... no UTF-8 locale found
> configure: error: No UTF-8 locale found. This is required for building successfully.
> configure exiting with result code 1
> 
> maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity?  (have to check if there are other names on AIX)

> @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :)


Sounds good to me ,  thanks for adjusting !

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2076970234

From mbaesken at openjdk.org  Wed May  7 08:17:21 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 7 May 2025 08:17:21 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <NvIKz3MmweON_wbHZOzy5CM3s6EQWn0C_mbsY2aSzA4=.3463dd3e-8893-488f-84b3-86752610560f@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2820807425

From mdoerr at openjdk.org  Wed May  7 08:17:22 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 7 May 2025 08:17:22 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v5]
In-Reply-To: <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <Jb7VOfKdtOj2kvoGjgBsmb-J31uB_FHlkLY_ulG1um4=.7027776d-c936-4ff7-9afc-7e91ca110d21@github.com>
Message-ID: <iRorxVeBIUdj16jxRIY6oUOmpyViZLwLp9aNWRNtLFo=.58a7cf19-9891-4fb6-9cc1-413fb0d10a3b@github.com>

On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - Don't convert properties files to iso-8859-1.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70

@sxa I guess UTF-8 locales will need to be documented for Adoptium AIX build requirements, too, when this change goes in.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2857536070

From ihse at openjdk.org  Thu May  8 10:19:31 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 May 2025 10:19:31 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into go-full-utf8
 - Merge branch 'master' into go-full-utf8
 - Add informative message  about supported locales.
 - Allow C locale with warning instead of fatal error
 - Also document UTF-8 requirements (solves JDK-8338973)
 - Let configure only accept utf-8 locales
 - Address review comments from Kim
 - Also tell javadoc that we have utf-8 now
 - Fix flags for Windows
 - Mark java and native source code as utf-8
 - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

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

Changes: https://git.openjdk.org/jdk/pull/24574/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=05
  Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/24574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574

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

From lkorinth at openjdk.org  Thu May  8 15:02:42 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 15:02:42 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
Message-ID: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>

This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).

The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.

In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).

My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.

These fixes have been created when I have plown through testcases:
JDK-8352719: Add an equals sign to the modules statement
JDK-8352709: Remove bad timing annotations from WhileOpTest.java
JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
CODETOOLS-7903961: Make default timeout configurable

Sometime in the future I will also fix:
8260555: Change the default TIMEOUT_FACTOR from 4 to 1

for which I am awaiting:
CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1

*After the review I will revert the two first commits, and update the copyrights*

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

Commit messages:
 - 8356171: Increase timeout for testcases as preparation for change of default timeout factor
 - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER
 - 8260555

Changes: https://git.openjdk.org/jdk/pull/25122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8356171
  Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod
  Patch: https://git.openjdk.org/jdk/pull/25122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122

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

From stefank at openjdk.org  Thu May  8 16:09:00 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 8 May 2025 16:09:00 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion.

I made a cursory look through some GC files and I think that looked good.

doc/testing.md line 385:

> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
> 384: certain amount of time will apply this factor. If we run in
> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)

Maybe
Suggestion:

interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

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

PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242
PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720

From dfuchs at openjdk.org  Thu May  8 16:28:53 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 16:28:53 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <VKBSy10yl0qvIk0P_JQb3KGFkmaDEtWYzncAlEW7VV8=.bd136181-45be-437e-b684-2ad16ac419b5@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

@lkorinth have you run all the tiers where the old default timeout factor of 4 applied?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579

From lkorinth at openjdk.org  Thu May  8 16:45:56 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 16:45:56 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Before this version, I had run tiers 1-8, with 11 fails.

** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700
** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 03 tools/javac/util/IteratorsTest.java 480
** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480
** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER
** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER
** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480
** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER
** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER
** DONE 10 java/foreign/TestMismatch.java 480
** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER

Six of those seems not related to my changes (marked `OTHER`),  five  I have updated for this run with new timeout.

I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time.

After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496
PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379

From erikj at openjdk.org  Thu May  8 16:55:02 2025
From: erikj at openjdk.org (Erik Joelsson)
Date: Thu, 8 May 2025 16:55:02 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <fPux4cGBwIwNR4DXUuxBR8ErjRjnII1aGfXSLjbySVc=.8a1cc9ea-78bf-4b43-af65-8a11c381fb05@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

Marked as reviewed by erikj (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2825782371

From lkorinth at openjdk.org  Thu May  8 17:06:02 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 8 May 2025 17:06:02 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
Message-ID: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>

On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> doc/testing.md line 385:
> 
>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>> 384: certain amount of time will apply this factor. If we run in
>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
> 
> Maybe
> Suggestion:
> 
> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)

Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016

From dfuchs at openjdk.org  Thu May  8 17:43:54 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 May 2025 17:43:54 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
Tests have not finished running - but I already see one intermittent failure:
`java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
It would be good to flush out any such intermittent failures before this PR is integrated.
This might require multiple runs before we can get confidence.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648

From jlu at openjdk.org  Thu May  8 18:07:42 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 18:07:42 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing [v3]
In-Reply-To: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
Message-ID: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - CSR review - directed inheritDoc; make 'concrete subclass' wording normative
 - Merge branch 'master' into JDK-8352755-limit-clarifications
 - Merge branch 'master' into JDK-8352755-limit-clarifications
 - Naoto's review: apiN -> implN. Rewording of maxintdig callout
 - init

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

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

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

  Stats: 347915 lines in 3714 files changed: 120818 ins; 211994 del; 15103 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  Thu May  8 19:01:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 19:01:55 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <rMGUrYJ9KLsppRGF6Doy6GWs2k3lFEYIIVItmBCaQRM=.04d51a5b-f41a-4919-9ad8-3e2bbd471e13@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2826102855

From prr at openjdk.org  Thu May  8 20:02:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 8 May 2025 20:02:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

test/jdk/java/awt/font/NumericShaper/MTTest.java

- * @run main/timeout=300/othervm MTTest
+ * @run main/timeout=1200/othervm MTTest

I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.

https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java

So 300 was fine, and 1200 isn't needed.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534

From naoto at openjdk.org  Thu May  8 21:06:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 21:06:31 GMT
Subject: <i18n dev> RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl for
 tzdata downgrades after JDK-8342550
Message-ID: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>

Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

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

Commit messages:
 - initial commit

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

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

From bpb at openjdk.org  Thu May  8 21:37:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 May 2025 21:37:52 GMT
Subject: <i18n dev> RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl
 for tzdata downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <A5JbV9XQNz8ZylGtTgFgEjbPUZu9xEkE_KPrW5ntNUw=.79fbbbbe-816a-4223-a1c0-ee224dffb2ae@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Looks all right to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826417729

From jlu at openjdk.org  Thu May  8 21:37:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 21:37:53 GMT
Subject: <i18n dev> RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl
 for tzdata downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <p8DYgRQBThPIpFQdeGzymfSZ05V-glMuIXr7y1ZMmL4=.8488cf34-66fd-4c11-91b8-cda124a875a5@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

lgtm

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826420607

From joehw at openjdk.org  Thu May  8 22:05:52 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 8 May 2025 22:05:52 GMT
Subject: <i18n dev> RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl
 for tzdata downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <lYCR6beOJcANFu0iuIK2_VIDQxSXxVokXvldsRbpzhU=.b9816bb4-8a31-4a68-8d55-3cc3c7445f62@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25130#pullrequestreview-2826461648

From jlu at openjdk.org  Thu May  8 23:00:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:00:26 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set
Message-ID: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>

Please review this PR which stems from discussion in the PR of JDK-8347949.

The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.

(This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Thu May  8 23:10:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:10:52 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>

On Thu, 8 May 2025 22:55:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

src/java.base/share/classes/java/util/Currency.java line 471:

> 469: 
> 470:     // Builds and returns the set of available Currencies
> 471:     private static HashSet<Currency> getCurrencies() {

I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080606583

From lmesnik at openjdk.org  Thu May  8 23:12:52 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 8 May 2025 23:12:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com>
 <KviAqsI-z3Gh_lbVlBACoM9sv01Z9SH-VFHwQBWfguw=.90eea9c8-c960-4d77-8649-50f80d5c57ff@github.com>
Message-ID: <inHeApQE1qTo35yQi6vzs6LYuATsr8NxmEMOU_1x_5c=.6ea734d1-63f2-47dc-a245-23d3233c76e4@github.com>

On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> doc/testing.md line 385:
>> 
>>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a
>>> 384: certain amount of time will apply this factor. If we run in
>>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk)
>> 
>> Maybe
>> Suggestion:
>> 
>> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk)
>
> Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk.

yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853

From jlu at openjdk.org  Thu May  8 23:30:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set [v2]
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

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

  Chen's review - method name clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25134/files
  - new: https://git.openjdk.org/jdk/pull/25134/files/f9e9c6b2..e2672ba1

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

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

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

From liach at openjdk.org  Thu May  8 23:30:06 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <8fE6Y01KMk7bPnaE1KLFGMagSIZYdykjOMQdWsdk-X8=.8f190772-2f47-4a72-95eb-177c111d0799@github.com>

On Thu, 8 May 2025 23:26:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

Looks great to me. Thanks!

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826594504

From jlu at openjdk.org  Thu May  8 23:30:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 8 May 2025 23:30:06 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set [v2]
In-Reply-To: <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <rMhgAOuhaVz9_97MeJIdg8pPrLZm_g8oO8GGkjc15i4=.d3ab9d25-cb31-4c9d-a334-3dbd93684b72@github.com>
Message-ID: <Zxc-E85yFzY2rKYx1bN_3CIffj6V3dmRo36Ij_ksbRE=.f124276b-9574-4a7a-b061-9f34de998d62@github.com>

On Thu, 8 May 2025 23:08:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Chen's review - method name clarification
>
> src/java.base/share/classes/java/util/Currency.java line 471:
> 
>> 469: 
>> 470:     // Builds and returns the set of available Currencies
>> 471:     private static HashSet<Currency> getCurrencies() {
> 
> I think we should rename this to `computeCurrencies` or `makeCurrencies` to indicate we are creating a new instance.

Definitely; updated in https://github.com/openjdk/jdk/pull/25134/commits/e2672ba1846c17b723d6bcbee0ef20488c0dca24.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25134#discussion_r2080621783

From naoto at openjdk.org  Thu May  8 23:38:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 8 May 2025 23:38:50 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <3Lj7qiOyPZvgDYuu8-O2INL8jaNVuTzRDbKxf3lhqeg=.71db798a-2fee-45c1-9ca2-639061127015@github.com>

On Thu, 8 May 2025 23:30:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25134#pullrequestreview-2826610413

From lmesnik at openjdk.org  Fri May  9 00:55:54 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Fri, 9 May 2025 00:55:54 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990

From dholmes at openjdk.org  Fri May  9 04:57:50 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 04:57:50 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in.

** though another option would be to update the jtreg default timeout instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247

From dfuchs at openjdk.org  Fri May  9 07:18:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 07:18:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
Message-ID: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>

On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI.
> Tests have not finished running - but I already see one intermittent failure:
> `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows.
> It would be good to flush out any such intermittent failures before this PR is integrated.
> This might require multiple runs before we can get confidence.

Results came back - another intermittent timeout failure (much more frequent) observed in:
`java/net/httpclient/CancelledResponse.java` on macOS x64

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003

From cstein at openjdk.org  Fri May  9 07:36:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 07:36:51 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <RY1U1_FEDrD_vm1RnfRFeQXKYhrm9frg1hkGnCFd5EE=.47796bf1-4b49-4572-9ea3-f8e43f0d350b@github.com>
Message-ID: <P_bn9YLGadoCvpQ4U3pQCWqa_FgbqOs_Smf_TRfTUxw=.5db4086c-fef8-437b-aa77-26124ea44177@github.com>

On Fri, 9 May 2025 04:54:52 GMT, David Holmes <dholmes at openjdk.org> wrote:

> [...]
> ** though another option would be to update the jtreg default timeout instead.

And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908

From alanb at openjdk.org  Fri May  9 08:12:52 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 9 May 2025 08:12:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <N027ImJIxB-7XV_sMWQf9VR2KTnUK6Fq8Tmkn8uXNYg=.f2a0f896-88a1-4702-adef-4514c9e155c1@github.com>
Message-ID: <togAOydR2ZGmRMpEDKHz7PXzdWIRLYaU6sFIlHUXUw4=.cdb2a446-5f7c-438e-8f1e-2d8bad8c9327@github.com>

On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
>> 
>> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
>> 
>> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
>> 
>> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
>> 
>> These fixes have been created when I have plown through testcases:
>> JDK-8352719: Add an equals sign to the modules statement
>> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
>> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
>> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
>> CODETOOLS-7903961: Make default timeout configurable
>> 
>> Sometime in the future I will also fix:
>> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
>> 
>> for which I am awaiting:
>> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
>> 
>> *After the review I will revert the two first commits, and update the copyrights*
>
> After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again.

@lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ?  If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927

From lkorinth at openjdk.org  Fri May  9 08:32:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:32:55 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <uabWdORniwCo0BELgwEHL9xwszL7WvN02cMLTu253K4=.de2529aa-23d2-4c86-9133-504f4146c93e@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966

From lkorinth at openjdk.org  Fri May  9 08:42:58 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 08:42:58 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
Message-ID: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>

On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence.

My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. 

The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066

From stefank at openjdk.org  Fri May  9 08:48:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 08:48:51 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.

Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701

From lkorinth at openjdk.org  Fri May  9 09:02:55 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:02:55 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>

On Thu, 8 May 2025 20:00:21 GMT, Phil Race <prr at openjdk.org> wrote:

> test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
>     * * @run main/timeout=300/othervm MTTest
> 
> 
>     * * @run main/timeout=1200/othervm MTTest
> 
> 
> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> 
> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> 
> So 300 was fine, and 1200 isn't needed.

I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871

From ihse at openjdk.org  Fri May  9 09:09:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 09:09:02 GMT
Subject: <i18n dev> RFR: 8301971: Make JDK source code UTF-8 [v6]
In-Reply-To: <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
 <tBEVMB0n8bNbzfjJy7jgJUxOa0Z-4OojY27IiXoxci8=.eec6f271-a45c-47f7-9f20-9ca219f1faea@github.com>
Message-ID: <YuqyLDE7wSJcsedHIHISMEw_2b31nTcosz7H1jqifjQ=.03fcaa89-eea3-4b20-8901-7f69345498ff@github.com>

On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
>> 
>> The fix is basically simple, and includes the following steps:
>> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
>> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into go-full-utf8
>  - Merge branch 'master' into go-full-utf8
>  - Add informative message  about supported locales.
>  - Allow C locale with warning instead of fatal error
>  - Also document UTF-8 requirements (solves JDK-8338973)
>  - Let configure only accept utf-8 locales
>  - Address review comments from Kim
>  - Also tell javadoc that we have utf-8 now
>  - Fix flags for Windows
>  - Mark java and native source code as utf-8
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db

It seems to be difficult to find someone to get this tested on a Chinese locale on Windows. I'll integrate this, and handle any problems that might arise as followups.

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

PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2865761193

From ihse at openjdk.org  Fri May  9 09:09:03 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 09:09:03 GMT
Subject: <i18n dev> Integrated: 8301971: Make JDK source code UTF-8
In-Reply-To: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
References: <YuP1aazfKG8yS6NxnkqDOen9G_IZu-Hi0qAJaN4PEOs=.82f51ccd-29e9-417a-8484-217befb5fcf4@github.com>
Message-ID: <1fDziF7qdWQ1gvZZ2pPh0MYEqRKAS0w3lPQbuYVUOa0=.f9283dc7-b8a0-4bfc-8dd5-4d124b225aa1@github.com>

On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4.
> 
> The fix is basically simple, and includes the following steps:
> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already
> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc).

This pull request has now been integrated.

Changeset: 3aa2ea7e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3aa2ea7e67c879dafa0f967073c2d8b98d62c996
Stats:     177 lines in 13 files changed: 49 ins; 105 del; 23 mod

8301971: Make JDK source code UTF-8
8338973: Document need to have UTF-8 locale available to build the JDK

Reviewed-by: erikj, naoto, mbaesken

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

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

From lkorinth at openjdk.org  Fri May  9 09:12:19 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:12:19 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> - * @run main/timeout=300/othervm MTTest
>> + * @run main/timeout=1200/othervm MTTest
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
>
>> test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>>     * * @run main/timeout=300/othervm MTTest
>> 
>> 
>>     * * @run main/timeout=1200/othervm MTTest
>> 
>> 
>> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
>> 
>> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
>> 
>> So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

> @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs.

The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times?

At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064

From cstein at openjdk.org  Fri May  9 09:15:51 2025
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 9 May 2025 09:15:51 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
 <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com>
Message-ID: <LWO7Q1kcmK2ygzbo5WovS47Dbuj_vfNTrTCvtPe8eLs=.4247df94-1d6d-4be7-bd56-77257bea18f7@github.com>

On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork.

Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769

From lkorinth at openjdk.org  Fri May  9 09:15:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 09:15:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
Message-ID: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>

On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

> > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> 
> Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?

I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195

From stefank at openjdk.org  Fri May  9 09:19:51 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Fri, 9 May 2025 09:19:51 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
 <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com>
 <SmaG9WzhdR3hL3bZpPNbC6_0GYx9sQ9knU4WJUqk614=.9de2872d-396f-425c-8096-1d0b725e27d2@github.com>
Message-ID: <rN9e2v3Ja1Kz4w4CsS6pDyFKNs88tAacAG4wiwWaK6w=.abf1d75b-861b-4de9-8e7b-61deca3e5e05@github.com>

On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration.
> > 
> > 
> > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1?
> 
> I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert.

I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555?

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474

From dfuchs at openjdk.org  Fri May  9 09:33:52 2025
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 May 2025 09:33:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <Jcf97xCR7qOc2AP78rYPfx8LZPloVRpb9a1xfyJyNIY=.873b34c4-e4cf-4b79-b819-66a40ad71cde@github.com>
 <bwBKVa6r3t5CTOTZK1pErpB1hgFdzm9X4TUj1K3HoLc=.cd421890-b1a2-48d7-832e-914bee047375@github.com>
 <PMQVll64pUTOaANd4itfY08A95oDXdFxCjWFdsbXNws=.081897dc-31ce-476d-929a-283b6735c492@github.com>
Message-ID: <vhPQ5uxCX4mkm_a34_Elnbjxazr49tOXu_ezw8YbY_g=.81d3c926-7a82-4f4a-95b2-336c63350801@github.com>

On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE)

Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069

From ihse at openjdk.org  Fri May  9 10:04:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:04:09 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v3]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <OaO3i0WE6Wt6FDeg9Chm58zh4Vg-jJ5oMOkpvc0PRhA=.208dfa65-1b75-4952-9a65-c326b1118c06@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

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

 - Merge branch 'master' into unicode-sequence-in-comments
 - Merge branch 'master' into unicode-sequence-in-comments
 - 8354968: Replace unicode sequences in comment text with UTF-8 characters

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/694b33dc..dd9a77c5

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

  Stats: 14771 lines in 491 files changed: 7892 ins; 4380 del; 2499 mod
  Patch: https://git.openjdk.org/jdk/pull/24727.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24727/head:pull/24727

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

From ihse at openjdk.org  Fri May  9 10:12:09 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:09 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v4]
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Clarify non-ASCII characters with unicode code point

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24727/files
  - new: https://git.openjdk.org/jdk/pull/24727/files/dd9a77c5..53aa4066

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

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

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

From ihse at openjdk.org  Fri May  9 10:12:12 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:12:12 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v2]
In-Reply-To: <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <TfQ6I-f17f0PV1C21EgU-3e62Msf3fqVh8AOQME-FdI=.e47d62ff-5998-476c-a6c7-16fa5c6cd722@github.com>
 <64mRUVMED7EZ58a61YYZ6I3MPmJ7GxgycwF4ZRU4LCw=.5dc3ee3b-b166-458c-b2e6-bc24cdb12e0a@github.com>
Message-ID: <T7BaCfqTjE-a2Soo1fPYD3PnJ64bsS-YM27NLwxcuKY=.aa500d13-5cad-4bea-aaa5-c94f7118b21b@github.com>

On Tue, 6 May 2025 17:16:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - Merge branch 'master' into unicode-sequence-in-comments
>>  - 8354968: Replace unicode sequences in comment text with UTF-8 characters
>
> src/java.base/share/classes/java/text/RuleBasedCollator.java line 594:
> 
>> 592:         // a three-digit number, one digit for primary, one for secondary, etc.
>> 593:         //
>> 594:         // String:              A     a     B   ?
> 
> Maybe "? (\u00e9, e-acute)"?

I used the `U+` code point notation here as well. I think that is better to make sure there are no misunderstandings, and no risk of the escaped character inadvertently being converted into an actual unicode character down the line by processors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24727#discussion_r2081372676

From ihse at openjdk.org  Fri May  9 10:47:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 May 2025 10:47:53 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v4]
In-Reply-To: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
Message-ID: <xA7HUgNAtNicDp0v65bJcACLZBbMCZQjiUgARidIM0U=.fac13cc3-1cb0-4b99-a514-8584238d7ff0@github.com>

On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
>> 
>> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
>> 
>> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
>> 
>> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify non-ASCII characters with unicode code point

Now that [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971) is committed, this PR is ready to be integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/24727#issuecomment-2866080024

From dholmes at openjdk.org  Fri May  9 12:21:54 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 9 May 2025 12:21:54 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479

From lkorinth at openjdk.org  Fri May  9 12:51:52 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 12:51:52 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <d4WeSYdxBsFQG_bsWZgsyGDKPbRL5ks8pTVVkck5foc=.5f39ab1e-bbab-483c-8b19-568c6e5a80e4@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers.  I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937.

Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573

From lkorinth at openjdk.org  Fri May  9 13:06:01 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Fri, 9 May 2025 13:06:01 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <zfwQsPX7kHwfbD2VUx3dhQwyy1VjAsb-yITfpShYhLM=.2c91dacc-78e2-4393-a7c5-b196fb5be962@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

Changing the timeout factor might be preferable to do after the fork.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008

From duke at openjdk.org  Fri May  9 13:12:30 2025
From: duke at openjdk.org (Abhishek N)
Date: Fri, 9 May 2025 13:12:30 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special cases
 coverage for currency.getInstance()
Message-ID: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>

Create a Test case to have special cases coverage for currency.getInstance().

The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.

test results:

jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
Directory "JTwork" not found: creating
Directory "JTreport" not found: creating
Test results: passed: 1
Report written to JTreport\html\report.html
Results written to JTwork

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

Commit messages:
 - remove trailing space
 - remove carriage return from txt and properties file
 - Update ValidateCurrencyCoverage.java test code and add more date cut off to properties and txt file
 - Update ValidateCurrncyCoverage.java to cover all currencies and print result in end
 - Replaced carriage return with newline and removed duplicate currencyParam.properties file
 - 8355393: Create a Test case to have special cases coverage for currency.getInstance()

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

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

From naoto at openjdk.org  Fri May  9 16:08:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:08:50 GMT
Subject: <i18n dev> RFR: 8354968: Replace unicode sequences in comment
 text with UTF-8 characters [v4]
In-Reply-To: <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
 <jYgZalrJrqF2-_kpxuxClN3v--h0fBc7QHn2urj-TP0=.d204338a-e538-47b8-8055-f0d840401fe2@github.com>
Message-ID: <d8w5t3NiWOgO1Yrp8hxcnKDEvaBgqBlgewshQe9qLU8=.a37e2def-3802-478d-bc4d-f66dd5519b8a@github.com>

On Fri, 9 May 2025 10:12:09 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
>> 
>> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
>> 
>> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
>> 
>> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clarify non-ASCII characters with unicode code point

LGTM. Thanks for the changes

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24727#pullrequestreview-2828887346

From naoto at openjdk.org  Fri May  9 16:20:00 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:20:00 GMT
Subject: <i18n dev> RFR: 8356450: NPE in CLDRTimeZoneNameProviderImpl
 for tzdata downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <B0rJU1nYHatPkSnGM0ZAsMYEC_JpmlN_Opc88CWhWaM=.fdac19cd-39e1-4866-a4b1-005a64746508@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25130#issuecomment-2867133483

From naoto at openjdk.org  Fri May  9 16:20:01 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 9 May 2025 16:20:01 GMT
Subject: <i18n dev> Integrated: 8356450: NPE in CLDRTimeZoneNameProviderImpl
 for tzdata downgrades after JDK-8342550
In-Reply-To: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
References: <cLBkKoLAi-5-rwmtliZFVlUcW5kaHA3Z9JMjxlg_hsE=.9a7eb7bd-0ecc-4ef9-9639-c6898095ad5f@github.com>
Message-ID: <Ir6iDLZE7TCkZgJnPy6C4ra8fTLDqTV4jm_Y3EOUCF8=.df4f3a38-cf01-45d2-a51c-0815b37848ff@github.com>

On Thu, 8 May 2025 20:50:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the NPE in CLDR time zone name provider. The NPE occurrs if the time zone data was downgraded by the TZUpdater tool in which some time zones are missing. For those missing zones, `ZoneInfo.getTimeZone()` returns null, while `TimeZone.getTimeZone()` falls back to `GMT`, which was the case prior to JDK-8342550. Changed the code in CLDR provider to assume the fixed zone in such a case.
> Manually confirmed the fix, and no test case is provided, as it requires tweaking the JDK with TZUpdater.

This pull request has now been integrated.

Changeset: 5f00c877
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f00c877e26f1716da231771b611234db5607fa7
Stats:     10 lines in 1 file changed: 7 ins; 1 del; 2 mod

8356450: NPE in CLDRTimeZoneNameProviderImpl for tzdata downgrades after JDK-8342550

Reviewed-by: bpb, jlu, joehw

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

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

From jlu at openjdk.org  Fri May  9 16:54:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 9 May 2025 16:54:56 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <PPMYhIYYJN4Tpait5mRLKCd5GUaEkGkIC3f9ixG1GJo=.2d28500e-e2a6-4502-bbc7-e9818e13e7b2@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

Hi @abhn-git, thanks for contributing the test but it's not clear to me what the purpose of this PR is. It seems to be testing the Currency overriding mechanism via the system property but that behavior is already tested. If you are attempting to test the future cut-over behavior for a standard ISO 4217 currency in `currencyData.properties`, the override mechanism does not simulate this 1-1.

For a standard ISO 4217 currency in `currencyData.properties`, a currency transition for a locale can occur at any time, (i.e. subsequent `getInstance(Locale)` calls can return different currencies). For the override mechanism, the transition is checked in the static block, and the resulting currency selected is fixed for the duration of the application's lifecycle.

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

Changes requested by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25057#pullrequestreview-2829069916

From wxiao at openjdk.org  Fri May  9 18:21:51 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Fri, 9 May 2025 18:21:51 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance()
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <Rx9As4Awi1e-G0GMq48N3dsw6NdatXeerTTAEH9OlVU=.9b3a8232-770b-4d7c-b61d-052956bde505@github.com>

On Tue, 6 May 2025 07:25:36 GMT, Abhishek N <duke at openjdk.org> wrote:

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

The root cause of the failure in https://bugs.openjdk.org/browse/JDK-8353433 was written by @coffeys in the bug. Right now It needs a test case to verify when future cut-over time is passing and the currency is going to work properly. Here is the example defined in CurrencyData.properties, "CW=ANG;2026-04-01-04-00-00;XCG".  Technically it needs to overwrite the return value of System.currentTimeMillis() and make it return with future time to trigger the test for future currency.

see this line https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/Currency.java#L423.

BTW, @justin-curtis-lu made the change in the mainline of JDK at https://bugs.openjdk.org/browse/JDK-8354344. Since it is using ClassFiie API, it can not be backported to jdk with version 23 or lower.

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2867537361

From prr at openjdk.org  Fri May  9 19:24:53 2025
From: prr at openjdk.org (Phil Race)
Date: Fri, 9 May 2025 19:24:53 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
 <qUtOWdQzhA2aCO21XPrr2pdtKwJ-n_qDvTY2UprQmJQ=.3f11dd7d-5d0c-47a8-9b1c-2cdfbf3f542b@github.com>
 <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com>
Message-ID: <tWgLVluDO0fcZ3e9N1V1GU6rmEcz-tyTVkNuJdr06Pw=.749ad3d3-b55a-486b-8d74-40091899e657@github.com>

On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> > test/jdk/java/awt/font/NumericShaper/MTTest.java
> > ```
> > * * @run main/timeout=300/othervm MTTest
> > 
> > 
> > * * @run main/timeout=1200/othervm MTTest
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds.
> > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java
> > So 300 was fine, and 1200 isn't needed.
> 
> I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough?

I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176

From duke at openjdk.org  Sun May 11 08:42:41 2025
From: duke at openjdk.org (Abhishek N)
Date: Sun, 11 May 2025 08:42:41 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
Message-ID: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>

> Create a Test case to have special cases coverage for currency.getInstance().
> 
> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
> 
> test results:
> 
> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
> Directory "JTwork" not found: creating
> Directory "JTreport" not found: creating
> Test results: passed: 1
> Report written to JTreport\html\report.html
> Results written to JTwork

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

  correcting jtreg header order, add meaningful comments for each test methods and properties file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25057/files
  - new: https://git.openjdk.org/jdk/pull/25057/files/77ae234a..7207e7c4

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

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

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

From jlu at openjdk.org  Mon May 12 20:37:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 20:37:59 GMT
Subject: <i18n dev> Integrated: 8348351: Improve lazy initialization of the
 available currencies set
In-Reply-To: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
Message-ID: <nOGOiSB3McS9N81nNkqswlEnWXmGt6WS-Y8Il2rXjhk=.3902981e-ea2d-4e66-9400-70cf172af221@github.com>

On Thu, 8 May 2025 22:55:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which stems from discussion in the PR of JDK-8347949.
> 
> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
> 
> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)

This pull request has now been integrated.

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

8348351: Improve lazy initialization of the available currencies set

Reviewed-by: liach, naoto

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

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

From jlu at openjdk.org  Mon May 12 20:37:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 20:37:58 GMT
Subject: <i18n dev> RFR: 8348351: Improve lazy initialization of the
 available currencies set [v2]
In-Reply-To: <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
References: <ak1E9qdLdyL52mHSiCQBb0A6i2dbHWf45bFho0y1WLc=.a5ba0bfa-c9bc-461d-9678-a391af3d9783@github.com>
 <5Uq21BuzB3dkeXCgnqUmuMfpTtjkbdCNi6XKu4nsCxU=.7f6c40ce-5d53-4368-8858-641427853a93@github.com>
Message-ID: <ZI_b_n-gtWiTKOCCDysrQjPzX_7l_JqnAmiaww7mwiM=.0ee52d8e-b41d-4a2b-8ad5-237422cf313f@github.com>

On Thu, 8 May 2025 23:30:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which stems from discussion in the PR of JDK-8347949.
>> 
>> The set of lazily loaded Currencies is a good fit for stable values. `available` can now be made final as it is a SV supplier.
>> 
>> (This change also includes an unrelated minor edit to comments in `Currency::getCurrencies` to make the distinction for simple vs special Currencies.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Chen's review - method name clarification

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25134#issuecomment-2873923357

From jlu at openjdk.org  Mon May 12 23:26:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 12 May 2025 23:26:55 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao  appear to be duplicates.

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2874462568

From aturbanov at openjdk.org  Tue May 13 08:15:32 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain old
 value in Toolkit.setDesktopProperty
Message-ID: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>

To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

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

Commit messages:
 - [PATCH] Avoid redundant WeakHashMap.get to obtain old value in Toolkit

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

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

From liach at openjdk.org  Tue May 13 08:15:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain
 old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <cx9-fdllNQTqXAnU42CYCDdgOY4KkHvZBbl9ORR7PHA=.ffd22938-be24-4f44-a4a4-cc336472a7b5@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

This field is protected; need evaluation about subclass tempering.

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2810085858

From aturbanov at openjdk.org  Tue May 13 08:15:32 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain
 old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <sdxIS8doTl5JPZ7WY3WORcNMWBvm91SXZoeDN9XHWFE=.15ddd454-5eaa-4937-84f7-425191ff69d3@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

It's `final`. What kind of problems can be from `protected` field?

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2810188669

From serb at openjdk.org  Tue May 13 08:15:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 13 May 2025 08:15:32 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain
 old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <vZi6OdDftFiQC9PzvPd5v0-Pb9JD9oYtM6R3fg3zHPM=.9870ddbd-4639-40a9-aeab-4e859e8e84b2@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

looks fine

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

PR Comment: https://git.openjdk.org/jdk/pull/24691#issuecomment-2874815079

From naoto at openjdk.org  Tue May 13 17:02:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 13 May 2025 17:02:54 GMT
Subject: <i18n dev> RFR: 8352755: Misconceptions about
 j.text.DecimalFormat digits during parsing [v3]
In-Reply-To: <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com>
References: <DbSlspa3gs2Bi6EzhpNX6NpcgO3kSp3SkJS39jKJXmI=.41a4afcc-f083-4332-ba05-3a2f4e2dc795@github.com>
 <3SUlt-xiFDfPWHDJwbvMeUfONvc4zm5gwUlgiQGM8xg=.ae8b7ae7-37b4-4d67-b633-bfbb3565fd22@github.com>
Message-ID: <U0ADt3Li6Zm2dDpsH7-X7ODlLKbJw7XnXYDAsmdwgMY=.775d325e-84ef-468f-b305-d25edd751bb9@github.com>

On Thu, 8 May 2025 18:07:42 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - CSR review - directed inheritDoc; make 'concrete subclass' wording normative
>  - Merge branch 'master' into JDK-8352755-limit-clarifications
>  - Merge branch 'master' into JDK-8352755-limit-clarifications
>  - Naoto's review: apiN -> implN. Rewording of maxintdig callout
>  - init

Marked as reviewed by naoto (Reviewer).

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

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

From aivanov at openjdk.org  Tue May 13 18:16:57 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 13 May 2025 18:16:57 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain
 old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <ymajNei3PsRJ2kUcpXxxeitA7oY-aG7F2XDMexa3mFs=.11a9687d-7cdd-4fa6-8e12-4bf0579749eb@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24691#pullrequestreview-2837712897

From jlu at openjdk.org  Tue May 13 20:26:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 13 May 2025 20:26:07 GMT
Subject: <i18n dev> Integrated: 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: <4MLN-99QTiXJX6PfuB3dSq2eurz9SVkYh0HBM7R8zB0=.a4eec50f-e68d-4a4f-a57f-31e536f073de@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.

This pull request has now been integrated.

Changeset: e149bd3a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e149bd3a0c387698fe7b2ff6c373944ded773b8b
Stats:     99 lines in 3 files changed: 9 ins; 20 del; 70 mod

8352755: Misconceptions about j.text.DecimalFormat digits during parsing

Reviewed-by: naoto

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

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

From serb at openjdk.org  Wed May 14 03:14:57 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 14 May 2025 03:14:57 GMT
Subject: <i18n dev> RFR: 8356843: Avoid redundant HashMap.get to obtain
 old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <pFBZeTan4bM8nooKyqc_9Pwc8sOz6TkU2mdwe2Lr2GI=.431e114b-4442-422c-bc65-192244f72ad7@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24691#pullrequestreview-2838598416

From ihse at openjdk.org  Wed May 14 06:46:57 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 06:46:57 GMT
Subject: <i18n dev> Integrated: 8354968: Replace unicode sequences in
 comment text with UTF-8 characters
In-Reply-To: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
References: <UeGV6BNWhOq9DKCbDaEaLLEMPHSViEaQPL1hqI4FaaU=.30fa6fbb-ca42-4faf-a163-3fe5b37cd6ef@github.com>
Message-ID: <sgBPptQGphRdBvFWPXl8SJm3092mzM3MjrlJs3LVL3A=.df2ae687-a101-48de-a821-4f8973c7558a@github.com>

On Thu, 17 Apr 2025 14:42:37 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> As part of the UTF-8 cleaning up done in [JDK-8301971](https://bugs.openjdk.org/browse/JDK-8301971), I looked at where and how we are using unicode sequences (`\uXXXX`). In several string literals, I think the unicode sequences still has merit, if they improve clarity or readability of the code. Some instances are more gray zone. But the places where it does not make sense at all are in comments, as part of fluid text comments. There they are just disruptive and not helpful at all. I tried to locate all such places (but I might have missed places, I did not do a proper lexical analysis to find comments) and fix them.
> 
> 99% of this fix is to turn poor `Peter von der Ah\u00e9` into `Peter von der Ah?`. ? 
> 
> I checked some random samples on when this was introduced to see if there were some particular commit that mistreated the encoding, but they have been there since the original release of the open JDK source code.
> 
> There are likely many more places where direct UTF-8 encoded characters is preferable to unicode sequences, but this seemed like a safe and trivial first start.

This pull request has now been integrated.

Changeset: a3e094e1
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3e094e1a0716adf52dad6407eb7877682beec92
Stats:     158 lines in 153 files changed: 0 ins; 2 del; 156 mod

8354968: Replace unicode sequences in comment text with UTF-8 characters

Reviewed-by: naoto

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

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

From ihse at openjdk.org  Wed May 14 14:28:10 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:28:10 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups
Message-ID: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>

I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

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

Commit messages:
 - Replace uncessary unicode characters with ASCII in instructions, and fix typo
 - Seems like typos in the comments
 - Fix unicode sequences in comments (previously missed)

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

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

From ihse at openjdk.org  Wed May 14 14:34:37 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 14:34:37 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java source
 code to UTF-8
Message-ID: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>

After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

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

Commit messages:
 - 8356978: Convert unicode sequences in Java source code to UTF-8

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

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

From ihse at openjdk.org  Wed May 14 15:16:18 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 14 May 2025 15:16:18 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
Message-ID: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>

Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.

I have checked:
* U+00A0 NO-BREAK SPACE (NBSP)
* U+202F NARROW NO-BREAK SPACE (NNBSP)
* U+2007 FIGURE SPACE
* U+2060 WORD JOINER

In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

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

Commit messages:
 - Use sequences for valid nbsp usage
 - Remove mistaken nbsp

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

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

From prr at openjdk.org  Wed May 14 17:01:55 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 14 May 2025 17:01:55 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:

> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
> 38: 
> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:

So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
But I think you know that ..  since you commented on the PR

The fix was done by @justin-curtis-lu and reviewed by
@naotoj so I think I'd like to get their opinion on this

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089371921

From jlu at openjdk.org  Wed May 14 17:21:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 14 May 2025 17:21:54 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
Message-ID: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>

On Wed, 14 May 2025 16:59:23 GMT, Phil Race <prr at openjdk.org> wrote:

>> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
>> 
>> I have checked:
>> * U+00A0 NO-BREAK SPACE (NBSP)
>> * U+202F NARROW NO-BREAK SPACE (NNBSP)
>> * U+2007 FIGURE SPACE
>> * U+2060 WORD JOINER
>> 
>> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.
>
> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
> 
>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>> 38: 
>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
> 
> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
> But I think you know that ..  since you commented on the PR
> 
> The fix was done by @justin-curtis-lu and reviewed by
> @naotoj so I think I'd like to get their opinion on this

For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089399946

From naoto at openjdk.org  Wed May 14 17:36:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 14 May 2025 17:36:51 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
Message-ID: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>

On Wed, 14 May 2025 17:18:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.desktop/share/classes/com/sun/java/swing/plaf/gtk/resources/gtk_fr.properties line 39:
>> 
>>> 37: GTKColorChooserPanel.hue.textAndMnemonic=&Teinte :
>>> 38: 
>>> 39: GTKColorChooserPanel.red.textAndMnemonic=Roug&e\u00a0:
>> 
>> So, this exactly reverses what was done in the fix for https://bugs.openjdk.org/browse/JDK-8301991
>> But I think you know that ..  since you commented on the PR
>> 
>> The fix was done by @justin-curtis-lu and reviewed by
>> @naotoj so I think I'd like to get their opinion on this
>
> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)

I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2089424644

From serb at openjdk.org  Thu May 15 02:27:50 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 15 May 2025 02:27:50 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
Message-ID: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>

On Wed, 14 May 2025 17:34:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> For the l10n files, they are synced by the translation team and we don't edit them. IMO, I think it's fine leaving those ones as is. Especially because language rules can cause different spacing and punctuation characters, so generally we don't ensure translations are equivalent to the original file's value in that regard. (So viewing them as a Unicode escape sequence vs UTF-8 literal may not bring much benefit.)
>
> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.

maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090083320

From naoto at openjdk.org  Thu May 15 03:20:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 03:20:51 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
Message-ID: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>

On Thu, 15 May 2025 02:25:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> I believe it is OK to leave these as UTF-8 native characters, as these files are l10n resource bundles. If we wanted to replace those look-alike spaces to unicode escapes, other characters may also need the same treatment, such as hyphen-minus, quotations, etc. In fact there are lot more look alikes defined in the unicode consortium (https://www.unicode.org/Public/security/latest/confusables.txt), and I don't think we would want to convert them.
>
> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090140891

From aturbanov at openjdk.org  Thu May 15 08:00:00 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 15 May 2025 08:00:00 GMT
Subject: <i18n dev> Integrated: 8356843: Avoid redundant HashMap.get to
 obtain old value in Toolkit.setDesktopProperty
In-Reply-To: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
References: <-cCKHkV-RiLXVpaxjKw6ZT6Hh6GnDvd-6HUMaVCFepg=.3b741470-0438-46af-8a4c-b13619b9e501@github.com>
Message-ID: <NHMtTO5ypUDAjqyyVCgcdoyO5nXKb4yXYQfpNXuX2nY=.6fff38e8-b2e5-447c-a11f-547e2c0415e6@github.com>

On Wed, 16 Apr 2025 14:48:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> To obtain previous value of `HashMap` we can use result of `.put` call. In this case we can avoid redundant `.get` call.

This pull request has now been integrated.

Changeset: e557b695
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e557b6956bdf9b0d89ad69427c7b4a97a65868ea
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8356843: Avoid redundant HashMap.get to obtain old value in Toolkit.setDesktopProperty

Reviewed-by: aivanov, serb

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

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

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
Message-ID: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>

On Thu, 15 May 2025 03:18:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>
> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.

> So, this exactly reverses what was done in the fix for JDK-8301991

No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.

Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090692617

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: <i18n dev> RFR: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <ExI4OcZ4H03w2Kmpe35WuEynczPvNAcXjCFY4cd6ldg=.1be29db4-e6a7-4376-93d9-94c05587c721@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

After an offline discussion, we agreed to wait a bit with this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218

From ihse at openjdk.org  Thu May 15 09:19:53 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 15 May 2025 09:19:53 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
Message-ID: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>

On Thu, 15 May 2025 09:16:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Maybe, but sometimes it is intentional. CLDR has once switched normal spaces to NBSP/NNBSP for certain locales (https://unicode-org.atlassian.net/browse/CLDR-14032). And we cannot tell if it is intentional or not.
>
>> So, this exactly reverses what was done in the fix for JDK-8301991
> 
> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.

> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?

That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2090695445

From lkorinth at openjdk.org  Thu May 15 09:20:03 2025
From: lkorinth at openjdk.org (Leo Korinth)
Date: Thu, 15 May 2025 09:20:03 GMT
Subject: <i18n dev> Withdrawn: 8356171: Increase timeout for testcases as
 preparation for change of default timeout factor
In-Reply-To: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
References: <WCuOwzU4kPjno7_Ptc1SQN6KY6MEejJlVEQKhZhqgjo=.259ff478-ab46-4d31-aa4a-c4fffb8d54a7@github.com>
Message-ID: <LrGk5ztc6aRY4EQjv-mVBVaNIVBhvjY-SQD1ZkUD5d4=.dba136cb-acc9-4d18-9112-41f62464a65f@github.com>

On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth <lkorinth at openjdk.org> wrote:

> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555).
> 
> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review.
> 
> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files).
> 
> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor.
> 
> These fixes have been created when I have plown through testcases:
> JDK-8352719: Add an equals sign to the modules statement
> JDK-8352709: Remove bad timing annotations from WhileOpTest.java
> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test
> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE
> CODETOOLS-7903961: Make default timeout configurable
> 
> Sometime in the future I will also fix:
> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1
> 
> for which I am awaiting:
> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1
> 
> *After the review I will revert the two first commits, and update the copyrights*

This pull request has been closed without being integrated.

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

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

From rgiulietti at openjdk.org  Thu May 15 12:35:51 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 15 May 2025 12:35:51 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
Message-ID: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>

On Thu, 15 May 2025 09:17:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> So, this exactly reverses what was done in the fix for JDK-8301991
>> 
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
>> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
>> 
>> Technically, it might be that some of these lines in the properties files are reversals of JDK-8301991, but that's just basically coincidence.
>
>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
> 
> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.

FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):

- U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
- U+00A0 (No-Break Space NBSP) preceding colon.

Similar conventions are used in other French speaking countries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2091068610

From duke at openjdk.org  Thu May 15 14:05:01 2025
From: duke at openjdk.org (Abhishek N)
Date: Thu, 15 May 2025 14:05:01 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
 <ajlqyimXKCirhh8qg0TP5wCaW-yoHzXpPD3zqsyvBmw=.d88ad90e-d619-422a-93f6-45c8218a50d3@github.com>
Message-ID: <mqVsj8OZBBanAsq-CwEPC1avTw4wHw70WZVuy8qTb-A=.9a71bab3-af6d-4b08-8185-adf78504c046@github.com>

On Mon, 12 May 2025 23:24:03 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correcting jtreg header order, add meaningful comments for each test methods and properties file
>
> Hi @abhn-git, I think it would be beneficial if we first addressed the concerns raised before continuing work on this PR. [JDK-8355393](https://bugs.openjdk.org/browse/JDK-8355393) assigned to you and [JDK-8355045](https://bugs.openjdk.org/browse/JDK-8355045) assigned to @weibxiao  appear to be duplicates.

Hi @justin-curtis-lu @weibxiao 

The main cause for failure in https://bugs.openjdk.org/browse/JDK-8353433  is that "currency cut-over date functionality was broken for the Currency.getInstance(String currencyCode, int defaultFractionDigits, int numericCode)" call and the currency 8u code threw illegalArguementException for new Currency after cut-over time was passed by System.

Example: 
"CW=ANG;2025-04-01-04-00-00;XCG"
-> After System time passed 1st April 2025 4:00 am, Currency.getInstance(XCG) -> throw illegalArguementException

Please note the issue could not be caught earlier and was caught only after System time passed the cut over time. 

So to prevent such miss in future, we have to write tests to check that after System time has passed cut over time the expected new currency instance is returned by both Currency.getInstance methods.

This can be achieved by two ways 
1. To mock System time to be after cut over time and see if Currency.getInstance is working as expected.
2. **To perform Currency overriding mechanism via the system property, where a modified currencies.properties file is set and it has entries for currencies whose cut over time is passed. And we write tests to verify both Currency.getInstance() methods and it has to return values as required.**

The test written in this PR does option 2

Example: In our modified currencies.properties file we have below entry

SX=ANG,532,2,2025-04-22T00:00:00

So, the test code ensures that since System time is past the cut over time the Currency.getInstance(new Locale("SX")) and Currency.getInstance("ANG") should return values as expected (expected values are in CurrencyList.txt).

And if new currencies are added in future with cut over timeconditions it should work properly once the System time passes cut over time ,provided our test in above PR is Passing.


The test written in this PR does option 2. and works fine for all the release.

@justin-curtis-lu @weibxiao please let me know if there are any issues with this test fix.

thank you

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2883930487

From naoto at openjdk.org  Thu May 15 18:32:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 18:32:53 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

test/jdk/sun/text/resources/LocaleDataTest.java line 106:

> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
> 106:  *        LocaleNames/fr_FR/US=?tats-Unis

This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2091757029

From jlu at openjdk.org  Thu May 15 18:52:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 May 2025 18:52:53 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data:
(i.e. Make country `LK` have a transition currency of `XCH` in July)


--- a/src/java.base/share/data/currency/CurrencyData.properties
+++ b/src/java.base/share/data/currency/CurrencyData.properties
@@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036
   SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\
   TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\
   UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\
-  XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
+  XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
   XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\
   ZWL932-ZWN942-ZWR935
 
@@ -502,7 +502,7 @@ GS=GBP
 # SPAIN
 ES=EUR
 # SRI LANKA
-LK=LKR
+LK=LKR;2025-07-01-04-00-00;XCH


and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`,
(Similar to 8, prior to the fix backported)


--- a/src/java.base/share/classes/java/util/Currency.java
+++ b/src/java.base/share/classes/java/util/Currency.java
@@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi
                 defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT;
                 numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT;
                 found = true;
-            } else { //special case
-                int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode);
-                if (fractionAndNumericCode != null) {
-                    defaultFractionDigits = fractionAndNumericCode[0];
-                    numericCode = fractionAndNumericCode[1];
-                    found = true;
-                }
             }


With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 transition currency after the transition date has passed. As mentioned above, the system property override does not mock a standard ISO 4217 transition currency, (they have different functionality).

Also as @weibxiao has mentioned, we already have such a test in mainline. Additional testing would be required as backports for LTS releases only.

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884773970

From naoto at openjdk.org  Thu May 15 19:36:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 19:36:02 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data tests
Message-ID: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>

Removing now-defunct COMPAT locale provider tests.

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

Commit messages:
 - initial commit

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

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

From joehw at openjdk.org  Thu May 15 20:26:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 15 May 2025 20:26:53 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <KJ0LC4zodUVloa_jyF-gsdHZFA3B5V8WLyyxBYFnd2s=.b6efe6ee-d9f1-435e-9103-455a11cb7d86@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844891980

From wxiao at openjdk.org  Thu May 15 20:32:54 2025
From: wxiao at openjdk.org (Weibing Xiao)
Date: Thu, 15 May 2025 20:32:54 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
Message-ID: <JB5V1JU7fMCb2rEeu8_X_n_BmZq4iP5zxBUdAk0xZGM=.f8a7e52f-37f3-4c94-9ace-9d5a8c887372@github.com>

On Sun, 11 May 2025 08:42:41 GMT, Abhishek N <duke at openjdk.org> wrote:

>> Create a Test case to have special cases coverage for currency.getInstance().
>> 
>> The test Validates that all currency codes and country-currency mappings in the input file are consistent with the Java Currency API.
>> 
>> test results:
>> 
>> jdk-24.0.2/bin/java -jar jtreg/lib/jtreg.jar -testjdk:jdk-24.0.2 -dir:jdk/test/jdk/ java/util/Currency/currencyEnhancedCoverage/ValidateCurrencyCoverage.java
>> Directory "JTwork" not found: creating
>> Directory "JTreport" not found: creating
>> Test results: passed: 1
>> Report written to JTreport\html\report.html
>> Results written to JTwork
>
> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correcting jtreg header order, add meaningful comments for each test methods and properties file

The test case, by using example data "CW=ANG;2099-04-01-04-00-00;XCG",  when

Currency.getInstance ("XCG) is called; instead failing, it will work by overwriting System::currentTimeMillis. This call will return any future time. This will allow the currency XG to be a valid currency. It verifies the future currency at current time.

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2884983555

From jlu at openjdk.org  Thu May 15 20:43:54 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 15 May 2025 20:43:54 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

Nice cleanup; lgtm

test/jdk/sun/text/resources/LocaleDataTest.java line 178:

> 176: public class LocaleDataTest
> 177: {
> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";

Suggestion:

    static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr";

test/jdk/sun/text/resources/LocaleDataTest.java line 179:

> 177: {
> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 179:     static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr";

Suggestion:

    static final String UTIL_RESOURCES_PACKAGE = "sun.util.resources.cldr";

test/jdk/sun/text/resources/LocaleDataTest.java line 180:

> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 179:     static final String UTIL_RESOURCES_PACKAGE ="sun.util.resources.cldr";
> 180:     static final String DEFAULT_DATAFILE ="LocaleData.cldr";

Suggestion:

    static final String DEFAULT_DATAFILE = "LocaleData.cldr";

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2844921929
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926227
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926415
PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091926586

From naoto at openjdk.org  Thu May 15 20:53:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 20:53:10 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests [v2]
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>

> Removing now-defunct COMPAT locale provider tests.

Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:

 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Update test/jdk/sun/text/resources/LocaleDataTest.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25257/files
  - new: https://git.openjdk.org/jdk/pull/25257/files/5112a966..b9cf8d18

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

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

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

From naoto at openjdk.org  Thu May 15 20:53:10 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 15 May 2025 20:53:10 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests [v2]
In-Reply-To: <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <E7eVjxlD6oxLH4PqRD9PHqi8b4noyT9PVAbH3wz1D3w=.a3a1f619-48c6-42db-a380-c0c7367ae0ad@github.com>
Message-ID: <8X53b-CEba172PLu24gc0HukUUfBc5egPMqMGiKnXmA=.8a512b9c-4684-4181-985e-e2fe178b5c09@github.com>

On Thu, 15 May 2025 20:39:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 178:
> 
>> 176: public class LocaleDataTest
>> 177: {
>> 178:     static final String TEXT_RESOURCES_PACKAGE ="sun.text.resources.cldr";
> 
> Suggestion:
> 
>     static final String TEXT_RESOURCES_PACKAGE = "sun.text.resources.cldr";

Thanks. Committed with others

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25257#discussion_r2091940230

From joehw at openjdk.org  Fri May 16 16:42:53 2025
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 16 May 2025 16:42:53 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <3tVtRDVNeYwN4Hf6OB-3gYM44GrqPAxWfWfptNQolnM=.dcf79f5b-a7c9-43bd-8af4-c542caed0a33@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847142525

From iris at openjdk.org  Fri May 16 17:28:51 2025
From: iris at openjdk.org (Iris Clark)
Date: Fri, 16 May 2025 17:28:51 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <6MMtxe9V1vRVN-dAVHwMveNro15HG5zvy7cFyYI4yJM=.68ed2245-db5f-4ddf-b8eb-d26840e2def1@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25257#pullrequestreview-2847242934

From naoto at openjdk.org  Fri May 16 18:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 May 2025 18:05:56 GMT
Subject: <i18n dev> RFR: 8357075: Remove leftover COMPAT locale data
 tests [v2]
In-Reply-To: <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
 <ybUfk4KD0jMOEn3ki-VKlALRXABRpZfCFR6mCUp1EqQ=.4a2e12dc-ab43-4fde-b9a8-9682e3fb4f66@github.com>
Message-ID: <XuVgr1XKrNJ0FfCafRqPIf_FX1IIFZQ8sNqCe9ApABc=.e8fa9635-9de9-48aa-8241-27be1c1deabb@github.com>

On Thu, 15 May 2025 20:53:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing now-defunct COMPAT locale provider tests.
>
> Naoto Sato has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Update test/jdk/sun/text/resources/LocaleDataTest.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25257#issuecomment-2887364827

From naoto at openjdk.org  Fri May 16 18:05:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 16 May 2025 18:05:56 GMT
Subject: <i18n dev> Integrated: 8357075: Remove leftover COMPAT locale data
 tests
In-Reply-To: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
References: <IYjCFn07vv8kw58ejaWyc-YHZsX82pHhCQTFRqUbA_g=.a36cde3d-22ed-436a-a9b1-68b532300234@github.com>
Message-ID: <uulY9ZHvv7E5QO78VbnGpmiD40X_s0LYPJkDXKnAwk0=.3466c929-1bdf-4018-ad4c-118089766424@github.com>

On Thu, 15 May 2025 19:31:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing now-defunct COMPAT locale provider tests.

This pull request has now been integrated.

Changeset: 3dd34517
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3dd34517000e4ce1a21619922c62c025f98aad44
Stats:     8496 lines in 2 files changed: 0 ins; 8484 del; 12 mod

8357075: Remove leftover COMPAT locale data tests

Reviewed-by: joehw, iris, jlu

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

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

From aturbanov at openjdk.org  Mon May 19 08:14:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
Message-ID: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>

Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

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

Commit messages:
 - [PATCH] Avoid redundant WeakHashMap.get in Toolkit.removeAWTEventListener

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

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

From liach at openjdk.org  Mon May 19 08:14:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <3fueyKPoeYAA-G-74gjNyqfJ8qE2HSa8g54Lq-ZSsyg=.8978ab07-e214-4c61-9ad6-0c2e19629335@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Makes sense. This map is private, and its value is always non-null (only one other put site), so I believe things are fine here.

Let another reviewer in area to confirm this change.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2773119715
PR Comment: https://git.openjdk.org/jdk/pull/24692#issuecomment-2810091497

From serb at openjdk.org  Mon May 19 08:14:29 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:

> 1743:         synchronized (this) {
> 1744:             SelectiveAWTEventListener selectiveListener =
> 1745:                 listener2SelectiveListener.remove(localL);

While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:

if (localL == null) {
    return;
}

?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2089545502

From aturbanov at openjdk.org  Mon May 19 08:14:29 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 19 May 2025 08:14:29 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
Message-ID: <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>

On Wed, 14 May 2025 18:52:55 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`
>
> src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:
> 
>> 1743:         synchronized (this) {
>> 1744:             SelectiveAWTEventListener selectiveListener =
>> 1745:                 listener2SelectiveListener.remove(localL);
> 
> While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:
> 
> if (localL == null) {
>     return;
> }
> 
> ?

Looks like yes. I think it's worth to create a separate issue to fix it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2095112071

From aivanov at openjdk.org  Mon May 19 12:28:51 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:28:51 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <dvfbVAI16V4HtAH39OX-WJLFqp-Rro6MyHOq_ll_zEg=.5e3c9628-08b7-417d-9946-89dc0fec4fb7@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2850572034

From aivanov at openjdk.org  Mon May 19 12:28:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 19 May 2025 12:28:52 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
Message-ID: <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>

On Mon, 19 May 2025 08:10:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Toolkit.java line 1745:
>> 
>>> 1743:         synchronized (this) {
>>> 1744:             SelectiveAWTEventListener selectiveListener =
>>> 1745:                 listener2SelectiveListener.remove(localL);
>> 
>> While analyzing the implementation of this method, I noticed a potential bug at the beginning. Should it instead be:
>> 
>> if (localL == null) {
>>     return;
>> }
>> 
>> ?
>
> Looks like yes. I think it's worth to create a separate issue to fix it.

It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.

However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2095589937

From jlu at openjdk.org  Mon May 19 21:02:49 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 19 May 2025 21:02:49 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed
Message-ID: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>

It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Mon May 19 23:43:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 19 May 2025 23:43:51 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>

On Mon, 19 May 2025 20:56:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

src/java.base/share/classes/java/util/Locale.java line 2792:

> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
> 2791:          + For such occurrences, the first extlang subtag is used as the language,
> 2792:          * and the primary language subtag and other extlang subtags are ignored.

Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096613695

From jlu at openjdk.org  Mon May 19 23:55:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 19 May 2025 23:55:51 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed
In-Reply-To: <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
Message-ID: <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>

On Mon, 19 May 2025 23:41:25 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> src/java.base/share/classes/java/util/Locale.java line 2792:
> 
>> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
>> 2791:          + For such occurrences, the first extlang subtag is used as the language,
>> 2792:          * and the primary language subtag and other extlang subtags are ignored.
> 
> Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.

An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,

`new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
`new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // ==> yue_CN

i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096619811

From naoto at openjdk.org  Tue May 20 00:41:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 00:41:51 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed
In-Reply-To: <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
 <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
Message-ID: <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>

On Mon, 19 May 2025 23:50:59 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 2792:
>> 
>>> 2790:          * tag). {@code languageTag} may contain up to three extlang subtags.
>>> 2791:          + For such occurrences, the first extlang subtag is used as the language,
>>> 2792:          * and the primary language subtag and other extlang subtags are ignored.
>> 
>> Should we throw an exeption here? I had an impression that the new description actually contradicts to the previous sentense, which asserts exception on ill-formed tag.
>
> An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,
> 
> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN
> 
> i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example)

OK. I would add these examples here too, which may be more helpful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2096650651

From serb at openjdk.org  Tue May 20 02:00:52 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 02:00:52 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <A4x1L9-wmenV3k7vDs_8VkQM9Px7uRWX8TTc1d5-dJE=.bfcd3b64-e2c0-4f88-80e9-239889738dea@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Marked as reviewed by serb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24692#pullrequestreview-2852324895

From jlu at openjdk.org  Tue May 20 17:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 17:19:32 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed [v2]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

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

  setLanguageTag should mention all conversions, not just extlang

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/204338ae..2d70bf79

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

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

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

From jlu at openjdk.org  Tue May 20 17:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 17:19:32 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 explicitly state extlangs are allowed [v2]
In-Reply-To: <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <QUtJwLbVsoGtCyv848P1vvnFfEgiFmZ34masOOPmJyM=.afc55604-b3ac-4cd1-b2b6-3ff2158d2992@github.com>
 <yO0NeGsCmo4vIPU3ioLORjTJ3IgK9cjutuR_H2CII7M=.2674da7f-406c-453f-bb1a-e333bebf1b5d@github.com>
 <JAXXxlfm30nkxcWaP69ToMTy-u-zT2B0UU7XsxFMZCw=.41f9f8f1-e728-4755-9b76-1a1c18f07641@github.com>
Message-ID: <BTJXyclR7mduiJ0I7HsRVqH5duEDmw7ebw2PS7wEblo=.4d8de939-0da5-46c9-b377-8c206b528e02@github.com>

On Tue, 20 May 2025 00:39:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> An exception is thrown when more than three extlang subtags are provided (ill-formed). The new wording is when an allowed amount of extlang subtags are provided (not ill-formed). For example,
>> 
>> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-czh-CN").build()` // throws
>> `new Locale.Builder().setLanguageTag("zh-yue-gan-cmn-CN").build()` // ==> yue_CN
>> 
>> i.e. if one to three extlang subtags occur, discard extras. If more than 3 occur, then it is ill-formed, and the method is already specified to throw on ill-formed tags. (Edit: Forgot to adjust the example)
>
> OK. I would add these examples here too, which may be more helpful.

Actually, `Locale.Builder.setLanguageTag` should mention all of the conversions that are made on the language tag, not just _extlang_ specifically. I'll link to the conversions section in `Locale.forLanguageTag` instead.
I also adjusted the _extlang_ example in `forLanguageTag` to indicate that the 4 _extlang_ example is "ill-formed" which should imply `Locale.Builder.setLanguageTag` throws an exception for that respective example.

Please see https://github.com/openjdk/jdk/pull/25309/commits/2d70bf799ba1285d599067c3d174dd8bd227db1f.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098491604

From serb at openjdk.org  Tue May 20 19:01:55 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 20 May 2025 19:01:55 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
 <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
Message-ID: <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>

On Mon, 19 May 2025 12:23:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Looks like yes. I think it's worth to create a separate issue to fix it.
>
> It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.
> 
> However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.

listener and proxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So this method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. so it is just a code clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2098669264

From aivanov at openjdk.org  Tue May 20 20:08:52 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 20 May 2025 20:08:52 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
 <SFCwpT-pkIwJZKnh66ZmtS1JGRHuxVueCVL12ozC2AI=.559a9c87-79e4-403a-a5d8-fe9c83f7f465@github.com>
 <OOtQjOWTck5yF6VDjBVnfE-1_aa3vTN1vxeuiIrNjKY=.747aea97-b92c-47d0-937d-ae071468d7a9@github.com>
 <95g0weiARkYC01wgCQbJNJD1iwc_RpCUS3sH1i1K_-A=.333d4836-3718-41c3-a998-4e2bccad3c1b@github.com>
 <9Lzt5tfT0nBGGv-3Bv2DEUil_hT4hV_sJZ4iXi8L5RU=.465ecb13-f771-482e-b085-bb704fa26e61@github.com>
Message-ID: <EYWOPSN7_Mot-70btErtr2PGIpZi4FyhnUziQknSHOg=.4de79c9d-bd15-4a1e-9c81-e233f81d9dc2@github.com>

On Tue, 20 May 2025 18:59:33 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> It doesn't matter, it looks? `localL` is `null` if and only if listener is `null`.
>> 
>> However, I'd put the null-check above the call to `deProxyAWTEventListener` to avoid any confusion.
>
> listener and proxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So this method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. so it is just a code clarification.

You're right!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24692#discussion_r2098766802

From naoto at openjdk.org  Tue May 20 23:05:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 20 May 2025 23:05:52 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 mention conversions made on language tag [v2]
In-Reply-To: <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
Message-ID: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>

On Tue, 20 May 2025 17:19:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   setLanguageTag should mention all conversions, not just extlang

src/java.base/share/classes/java/util/Locale.java line 1837:

> 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
> 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
> 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed

I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2098999406

From jlu at openjdk.org  Tue May 20 23:24:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 23:24:33 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 mention conversions made on language tag [v3]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <x5F0H4IXSnMdL3zwscgGx9HdOv9zDER7M6olVGy6_5k=.21446558-8e6b-4f7c-9ba7-085f423c3854@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

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

  adjust example wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/2d70bf79..62714a26

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

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

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

From jlu at openjdk.org  Tue May 20 23:24:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 20 May 2025 23:24:33 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 mention conversions made on language tag [v2]
In-Reply-To: <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <hmWGxITz4VOuIknq6n8_eTaUdQnvG-P00eAC4a2oKMI=.bf67fede-75c5-46a1-8791-ebecb4a832ba@github.com>
 <4LtNxZysNOzlXDdluBcxbXJh5LBv5bfaxJeMbRskcMs=.5ff1ed81-41b8-4223-9da0-3aacc69f1dfd@github.com>
Message-ID: <fm132ZhxaMkk2FlBq3Avc5QzGA31UJBhcixHAsBFHhw=.3ec5c23c-4c4b-48f8-954c-cba310ac205a@github.com>

On Tue, 20 May 2025 23:02:45 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   setLanguageTag should mention all conversions, not just extlang
>
> src/java.base/share/classes/java/util/Locale.java line 1837:
> 
>> 1835:      *     Locale.forLanguageTag("en-abc-def-us").toString(); // returns "abc_US"
>> 1836:      *     Locale.forLanguageTag("zh-yue-gan-cmn-czh-CN").toString();
>> 1837:      *     // returns "yue"; the rest of the tag is considered ill-formed
> 
> I'd rather not use "ill-formed" here, or change the wording, as "the rest of the tag" implies subtags other than "yue" which include "zh." If this "zh" is considered ill-formed, following "yue" should be discarded according to the prior definition.

OK, I'd like to keep "ill-formed" because it allows the example to have meaning for both `[for/set]LanguageTag`.
I updated the wording so that it is clear that "czh", (the fourth extlang) and subsequent subtags are what is considered ill-formed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25309#discussion_r2099018994

From aturbanov at openjdk.org  Wed May 21 08:43:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 May 2025 08:43:03 GMT
Subject: <i18n dev> RFR: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <InWB-eEh49TDyxcZmRRDmzLkNaqz9wkZ1XWEcdePuQc=.53a8b65e-3a98-4e55-9e84-775c54988081@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

Thank you for review.
Feel free to create a separate cleanup ticket to clarify code.

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

PR Comment: https://git.openjdk.org/jdk/pull/24692#issuecomment-2897100252

From aturbanov at openjdk.org  Wed May 21 08:43:03 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 21 May 2025 08:43:03 GMT
Subject: <i18n dev> Integrated: 8357224: Avoid redundant WeakHashMap.get in
 Toolkit.removeAWTEventListener
In-Reply-To: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
References: <dPJzMda0kJqjlO42akwLKzKGgXh6bRqqtZtOoTviQ7M=.4ea59851-4304-45b4-90f0-df6d4e89169e@github.com>
Message-ID: <bwUD8rVEHgA2eq5ubFshiB2EnGWBONIxNIJGdvOq8OQ=.b766ed29-d2ee-4f93-99a5-d6b01116479f@github.com>

On Wed, 16 Apr 2025 15:07:36 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Instead of separate `.get`+`.remove` calls we can call `.remove` and then compare result with `null`

This pull request has now been integrated.

Changeset: a0cdf36b
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a0cdf36bdfeca9cd8b669859700d63d5ee627458
Stats:     3 lines in 1 file changed: 0 ins; 1 del; 2 mod

8357224: Avoid redundant WeakHashMap.get in Toolkit.removeAWTEventListener

Reviewed-by: liach, aivanov, serb

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

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

From duke at openjdk.org  Wed May 21 18:55:53 2025
From: duke at openjdk.org (Abhishek N)
Date: Wed, 21 May 2025 18:55:53 GMT
Subject: <i18n dev> RFR: 8355393: Create a Test case to have special
 cases coverage for currency.getInstance() [v2]
In-Reply-To: <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>
References: <br4xWvKTmNu3MgmGoMkhaRmBRE1WFE4gH1I0inJ7btI=.ca211303-f414-4bc1-a71b-d855ab605ad7@github.com>
 <CsKOlV2I0UdHmTIJfnF0p6erC7pRyWFXWQF5yPBibxk=.2d983f8e-80e3-420e-9de4-2a925df345cc@github.com>
 <ONvSFsC7l-ZLsR9BBNbqiQoF2O-EFDd1JPa6jJn5Hgc=.074c130b-9585-47af-b589-b0970792ef39@github.com>
Message-ID: <mxdhF4l9bL9GXDmENHcCrTONEN5VCFP8wZb0kDLkFjA=.9deb4448-b918-482d-92f6-6bc5eef981ee@github.com>

On Thu, 15 May 2025 18:50:35 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Abhishek N has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   correcting jtreg header order, add meaningful comments for each test methods and properties file
>
> This test is not effectively testing standard ISO 4217 future transition currencies. For example, with your patch, if I supply the following changes to the ISO 4217 currency data:
> (i.e. Make country `LK` have a transition currency of `XCH` in July)
> 
> 
> --- a/src/java.base/share/data/currency/CurrencyData.properties
> +++ b/src/java.base/share/data/currency/CurrencyData.properties
> @@ -55,7 +55,7 @@ all=ADP020-AED784-AFA004-AFN971-ALL008-AMD051-ANG532-AOA973-ARS032-ATS040-AUD036
>    SRD968-SRG740-SSP728-STD678-STN930-SVC222-SYP760-SZL748-THB764-TJS972-TMM795-TMT934-TND788-TOP776-\
>    TPE626-TRL792-TRY949-TTD780-TWD901-TZS834-UAH980-UGX800-USD840-USN997-USS998-UYI940-\
>    UYU858-UZS860-VEB862-VED926-VEF937-VES928-VND704-VUV548-WST882-XAF950-XAG961-XAU959-XBA955-\
> -  XBB956-XBC957-XBD958-XCD951-XCG532-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
> +  XBB956-XBC957-XBD958-XCD951-XCG532-XCH533-XDR960-XFO000-XFU000-XOF952-XPD964-XPF953-\
>    XPT962-XSU994-XTS963-XUA965-XXX999-YER886-YUM891-ZAR710-ZMK894-ZMW967-ZWD716-ZWG924-\
>    ZWL932-ZWN942-ZWR935
>  
> @@ -502,7 +502,7 @@ GS=GBP
>  # SPAIN
>  ES=EUR
>  # SRI LANKA
> -LK=LKR
> +LK=LKR;2025-07-01-04-00-00;XCH
> 
> 
> and break some functionality related to _future/special_ currencies in `Currency.getInstance(String)`,
> (Similar to 8, prior to the fix backported)
> 
> 
> --- a/src/java.base/share/classes/java/util/Currency.java
> +++ b/src/java.base/share/classes/java/util/Currency.java
> @@ -326,13 +326,6 @@ private static Currency getInstance(String currencyCode, int defaultFractionDigi
>                  defaultFractionDigits = (tableEntry & SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_MASK) >> SIMPLE_CASE_COUNTRY_DEFAULT_DIGITS_SHIFT;
>                  numericCode = (tableEntry & NUMERIC_CODE_MASK) >> NUMERIC_CODE_SHIFT;
>                  found = true;
> -            } else { //special case
> -                int[] fractionAndNumericCode = SpecialCaseEntry.findEntry(currencyCode);
> -                if (fractionAndNumericCode != null) {
> -                    defaultFractionDigits = fractionAndNumericCode[0];
> -                    numericCode = fractionAndNumericCode[1];
> -                    found = true;
> -                }
>              }
> 
> 
> With the above changes, we would expect this test to fail, since `getInstance("XCH")` should throw an exception. However, your test still passes. What this patch is doing is selectively testing a handful of Currencies with the system property override. This is not sufficient to ensure test coverage for testing a standard ISO 4217 tran...

@justin-curtis-lu @weibxiao 

Our objective is to ensure the proper functionality of the Currency.getInstance() methods?particularly to guarantee that currencies defined with special conditions (such as future cutover dates) will work correctly once the system date passes those thresholds.

For example, in the case of the mapping:

LK=LKR;2025-07-01-04-00-00;XCH

we want to ensure that, once the system date passes 2025-07-01T04:00:00, both Currency.getInstance("XCH") and Currency.getInstance(new Locale("LK")) will work as expected and not throw an IllegalArgumentException.

To facilitate this, we use a custom currency.properties file that includes entries for currencies with such special conditions, where the cutover date has already passed. An example entry would be:


BI=BFI,108,0,2022-12-15T04:00:00

Without this customization, in earlier JDK versions (which do not include recent fixes), calling Currency.getInstance("BFI") would result in an IllegalArgumentException and issues such as JDK-8353433 would have been caught in earlier stages itself. 

Including these entries allows us to surface such issues earlier in the development or testing lifecycle.

**The test in mainline utilize the ClassFile API for mocking system time (such as System::currentTimeMillis), the ClassFile API is not supported in lower LTS JDK versions. Therefore, we rely on the custom currency properties approach to simulate post-cutover behavior for those environments.**

**Since additional currencies with similar cutover rules may be introduced in the future, our approach ensures that Currency.getInstance() continues to function reliably across all supported LTS JDK versions?even before the actual cutover date is reached?by validating currency data early using the custom CurrencyData.properties..**

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

PR Comment: https://git.openjdk.org/jdk/pull/25057#issuecomment-2898918478

From jlu at openjdk.org  Wed May 21 20:41:43 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 20:41:43 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 mention conversions made on language tag [v4]
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

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

  CSR review - clarify that 3 extlang subtags is not a JDK specific condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25309/files
  - new: https://git.openjdk.org/jdk/pull/25309/files/62714a26..1ee830e3

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

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

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

From jlu at openjdk.org  Wed May 21 21:24:11 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 21 May 2025 21:24:11 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable
Message-ID: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>

_sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Wed May 21 22:33:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 21 May 2025 22:33:55 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <Idp1VRv0w_3lkXRAmRKZBrjv2kxgD0RmoJ4bs_Buwdk=.45f64a22-40da-4285-a689-9de0092d7e98@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

The record migration is sensible: this class is purely used as a data carrier. Its object methods of hashCode and equals were unused so we can migrate safely, and the public constructor is okay too.

One comment is about the `List<String>` returning methods: currently, you are doing:

return list.isEmpty() ? list : Collections.unmodifiableList(list);

This code is error prone: if the list becomes immutable, the wrapper is redundant; if the list becomes mutable, the empty list can have new items added, and is not safe.

Since this is only accessed by trusted code (and we don't do dangerous thingss like `contains(null)`, we have much freedom in refactoring - we might just use the raw array list because users don't change them, and add alerts on record header about the mutability. Or wrap those lists with unmodifiableList upon parsing, or copy with List.copyOf, etc.

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

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2899412146

From naoto at openjdk.org  Thu May 22 01:18:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 01:18:54 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <3wbh2CRyYKYPfjMrlaJUB8fiaH9FSVFusKFnhJzLBys=.3716f5f6-c196-4887-bf39-1f526d9cf8e3@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Nice refactoring. Couple of nits follow

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 53:

> 51:     public static final String PRIVUSE_VARIANT_PREFIX = "lvariant";
> 52:     private static final String EMPTY_TAG = "";
> 53:     private static final List<String> EMPTY_TAGS = Collections.emptyList();

It would be clearer to rename "TAG(S)" to "SUBTAG(S)"

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 191:

> 189:         String region = EMPTY_TAG;
> 190:         List<String> variants = EMPTY_TAGS;
> 191:         List<String> extensions = EMPTY_TAGS;

These assignments can be moved for the case of `language.isEmpty()`

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

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2859485182
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101431166
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101426074

From swen at openjdk.org  Thu May 22 01:29:05 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 22 May 2025 01:29:05 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <QAS4cCQ1inr_O7M13lOA_aeDB2pXo7MbNy-uVmDi5LE=.018e7894-987a-41ee-8f7e-a8f7517c9d26@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 458:

> 456:                 baseLanguage = "id";
> 457:             }
> 458:             language = baseLanguage;

Suggestion:

            language = switch(baseLanguage) {
                case "iw" -> "he";
                case "ji" -> "yi";
                case "in" -> "id";
                default   -> baseLanguage;
            };

use switch expression

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2101446785

From jlu at openjdk.org  Thu May 22 16:46:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 16:46:10 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v2]
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

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

  review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25371/files
  - new: https://git.openjdk.org/jdk/pull/25371/files/ed0acc44..2d778a85

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

  Stats: 63 lines in 1 file changed: 12 ins; 16 del; 35 mod
  Patch: https://git.openjdk.org/jdk/pull/25371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371

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

From jlu at openjdk.org  Thu May 22 16:46:10 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 16:46:10 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <lwC-d3WZ1heW8dejDp5buSQVlMKPB7lZ4MJI-OfXJDA=.8e1b22df-d61d-4eee-b329-44f83602fa8b@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

Comments addressed in https://github.com/openjdk/jdk/pull/25371/commits/2d778a85ebff14e5080a15556083c3e16986edf4. Chen, that's a good point, those getters are fragile. I opted to maintain the unmodifiable quality of the list fields, this code isn't perf sensitive and is more predictable this way. I wrapped the lists during parsing so we can drop overriding the getters altogether.

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

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2901903043

From liach at openjdk.org  Thu May 22 17:17:59 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 17:17:59 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v2]
In-Reply-To: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
Message-ID: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>

On Thu, 22 May 2025 16:46:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

Everything else looks good.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249:

> 247:             return EMPTY_SUBTAGS;
> 248:         }
> 249:         List<String> extLangs = null;

Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`.

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

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862000028
PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103042373

From srl at openjdk.org  Thu May 22 17:32:53 2025
From: srl at openjdk.org (Steven Loomis)
Date: Thu, 22 May 2025 17:32:53 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v2]
In-Reply-To: <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
Message-ID: <p9avSUjfdP6Vdci9R4xHZVrxc1jEAucBbv1O07bAE1A=.c916ccac-dcf5-4ce1-8e88-99ac2e62b5cb@github.com>

On Thu, 22 May 2025 16:46:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors

@yumaoka

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

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2902033974

From jlu at openjdk.org  Thu May 22 17:51:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 17:51:32 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v3]
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

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

 - extLangs -> extlangs
 - Merge branch 'master' into JDK-8357281-LanguageTag
 - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25371/files
  - new: https://git.openjdk.org/jdk/pull/25371/files/2d778a85..a5429599

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

  Stats: 43668 lines in 640 files changed: 29920 ins; 10197 del; 3551 mod
  Patch: https://git.openjdk.org/jdk/pull/25371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25371/head:pull/25371

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

From jlu at openjdk.org  Thu May 22 17:51:33 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 22 May 2025 17:51:33 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v2]
In-Reply-To: <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <zpJcyPtB6YksaXYN1Y1EZiQYQmeNvumnJzMXngZwGqg=.a8ea90c9-ecef-42a6-aa7a-37d204d6bf09@github.com>
 <1dNugq-Zi17b8zchOopMRON42nzKEVet4gA01oavGhQ=.88290316-0aa7-422d-a492-a70aed44fc12@github.com>
Message-ID: <sYY5p7EATxiP-xioMQgUO3VU7WCjGm8SObQsOIGkDgQ=.db27bc9a-d3c1-4b51-b518-e24f7ba3d8b9@github.com>

On Thu, 22 May 2025 17:14:03 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 249:
> 
>> 247:             return EMPTY_SUBTAGS;
>> 248:         }
>> 249:         List<String> extLangs = null;
> 
> Do we want to name this `extLangs` or `extlangs`? The parsing method and the record uses `extlangs`.

Changed to `extlangs`, more consistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25371#discussion_r2103105426

From liach at openjdk.org  Thu May 22 18:07:52 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 22 May 2025 18:07:52 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <_QUPLEkt0lQLzNp1Z7X1UO0LGGyRH1OIJzuRnlagEbU=.361cab70-0229-45f2-add7-54599c907a77@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

This version looks much better. You might want the original author Yoshito or another I18N reviewer to check too.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862145268

From naoto at openjdk.org  Thu May 22 18:24:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 22 May 2025 18:24:58 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <_FIijEYTfFnkCAHDC8UFFYSUV4IBey5-im_qVyeqwtc=.2fe202af-bad4-46a9-8717-2d2f647bc91a@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25371#pullrequestreview-2862197819

From prr at openjdk.org  Thu May 22 21:28:53 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:28:53 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
Message-ID: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>

On Thu, 15 May 2025 12:33:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> maybe this is just a translation error and a simple space can be used instead, like in all the other properties in these files?
>> 
>> That seems unlikely. The pattern is used consistently in the French translations, where `Foo:` in the original is replaced with `Foo :` with a non-breaking space. I guess it is a French orthographic rule to have a space before the colon, and I understand why it really must be non-breaking in that case.
>
> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
> 
> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
> - U+00A0 (No-Break Space NBSP) preceding colon.
> 
> Similar conventions are used in other French speaking countries.

> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.

> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.


I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed

the Java unicode escape to UTF-8 for the localised message string.

You propose restoring it to Java escape.


I wouldn't be surprised if the next message drop reverses what you reversed.

I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes

since that is very much a Java thing. So you are probably making the translation job harder.


So I am suggesting you leave all of the translation files as is.
Which might mean withdrawing this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2103421828

From prr at openjdk.org  Thu May 22 21:34:50 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:34:50 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <zS5WZR4Cen8tmwZk_Y4kSHU3wpLpMysoCv5WfF4yRUM=.4c035191-6fb5-46f2-ab11-f35701183529@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Just speaking for the one client demo.
Someone else will need to review the other 98% of this PR

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2862613813

From prr at openjdk.org  Thu May 22 21:45:52 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 22 May 2025 21:45:52 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>

On Wed, 14 May 2025 14:23:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:

> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
> 48:  * <p>
> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>

This is javadoc inJava SE specification. As is the Action case below.
I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:

> 61: 
> 62:     private static final String INSTRUCTIONS =
> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "

I really don't like these tests being changed. It isn't part of the JDK build.
People compile these in all sorts of locales.
Please revert all the changes in the client tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103439338
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2103431874

From jlu at openjdk.org  Fri May 23 17:46:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 May 2025 17:46:58 GMT
Subject: <i18n dev> RFR: 8357281: sun.util.Locale.LanguageTag should be
 immutable [v3]
In-Reply-To: <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
 <GYKBz2_hwn2fMhvNG_AJkhj7YoD1KdEzZ_DhdAFC44Y=.8974fb06-613f-4aa4-9235-a8cd5f2b2d03@github.com>
Message-ID: <DXpZ88KKd-aG2ARyXq_A9iHgghI_Csqg6Qku_TxoEmI=.219c80b5-c77b-44ee-a48e-1d54c5ef03a4@github.com>

On Thu, 22 May 2025 17:51:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - extLangs -> extlangs
>  - Merge branch 'master' into JDK-8357281-LanguageTag
>  - review: subtag -> subtags, switch on baseLang, improve fragility of list field accessors
>  - init

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25371#issuecomment-2905306305

From jlu at openjdk.org  Fri May 23 17:46:59 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 23 May 2025 17:46:59 GMT
Subject: <i18n dev> Integrated: 8357281: sun.util.Locale.LanguageTag should
 be immutable
In-Reply-To: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
References: <WvdazL6TwjksLA-IJOvwFbpPot0aysUnw4V0GwbDK38=.d79a77d7-dc03-4877-ba91-4bbe7c380553@github.com>
Message-ID: <vpc1qR0QFNm-o9A8gDj7SUibUY5xSuf7MgRD_RBswh4=.ffd3a29d-96d9-48e1-b9f4-bb390b81a44e@github.com>

On Wed, 21 May 2025 21:19:36 GMT, Justin Lu <jlu at openjdk.org> wrote:

> _sun.util.Locale.LanguageTag_ is essentially a BCP47 language tag data carrier for Locale. The class, once created is not modified; the class should be made immutable. Converting the class to a record accomplishes this and also simplifies some of the existing code.

This pull request has now been integrated.

Changeset: 2f530f89
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2f530f89e0ee5ed5253125d0e9319b07103173f0
Stats:     191 lines in 3 files changed: 22 ins; 80 del; 89 mod

8357281: sun.util.Locale.LanguageTag should be immutable

Reviewed-by: naoto, liach

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

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

From liach at openjdk.org  Sun May 25 00:08:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:

> 1193:             result.append("  @Stable static final ");
> 1194:         result.append(atype);
> 1195:         result.append(" ").append(name).append("[");

While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106007546

From swen at openjdk.org  Sun May 25 00:08:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
Message-ID: <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>

On Sat, 24 May 2025 23:04:50 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:
> 
>> 1193:             result.append("  @Stable static final ");
>> 1194:         result.append(atype);
>> 1195:         result.append(" ").append(name).append("[");
> 
> While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?

This will require more changes, and has no benefits other than better coding style.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106030868

From swen at openjdk.org  Sun May 25 00:08:32 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
Message-ID: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>

Classes such as java.lang.CharacterDataXXX have multiple static final arrays, which will not be modified. We should add @Stable to provide information to the optimizer.

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

Commit messages:
 - sealed & final
 - add @Stable
 - stable

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

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

From liach at openjdk.org  Sun May 25 00:08:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 25 May 2025 00:08:32 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <SkefXOgWvwBGHB9E7xwMVCCnTMjrFN1-f_mOuhdWr6E=.e4372b37-df4f-4162-aeac-adee53693d95@github.com>
 <IyYM42Kj1ai1jpEKA0gjAKKbQ8L35PLr0W37aflOAnI=.250ed4b3-ad4f-43df-9827-8fb077edf1d2@github.com>
Message-ID: <CeCOd9mfG2XAQ8LLZFPRBlNwrcU7TZtFIbEh0u8RMvM=.7886f86c-7acc-4ebc-b245-8a623391fa7a@github.com>

On Sat, 24 May 2025 23:40:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java line 1195:
>> 
>>> 1193:             result.append("  @Stable static final ");
>>> 1194:         result.append(atype);
>>> 1195:         result.append(" ").append(name).append("[");
>> 
>> While you are at it - when Csyntax == false, can we make it print `atype[] name` instead of `atype name[]`?
>
> This will require more changes, and has no benefits other than better coding style.

Reasonable. These generated classes have a lot of code improvement opportunities that do not affect program semantics. We should handle those in a dedicated RFE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2106038820

From serb at openjdk.org  Sun May 25 07:55:38 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 07:55:38 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy
Message-ID: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>

The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502

AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.

One of the test is updated just to touch that codepath.

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

Commit messages:
 - Merge branch 'openjdk:master' into JDK-8357598
 - Update AWTEventListenerProxyTest.java
 - Update AWTEventListenerProxyTest.java
 - 8357598:  Toolkit.removeAWTEventListener should handle null listener in AWTEventListenerProxy

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

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

From serb at openjdk.org  Sun May 25 07:55:39 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sun, 25 May 2025 07:55:39 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <jwhwGriP0VdxUuGYrZDVUCUt-PfL5GvqG2kozdKiHs4=.26602fee-b25c-4f74-a531-d5828b9fbef8@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 41:

> 39:         EventQueue.invokeAndWait(() -> {
> 40:             Toolkit tk = Toolkit.getDefaultToolkit();
> 41: 

I do not know why it was disabled on XToolkit, seems to work fine.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2106117597

From ihse at openjdk.org  Mon May 26 07:47:02 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 07:47:02 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups
In-Reply-To: <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
Message-ID: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>

On Thu, 15 May 2025 18:30:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
> 
>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
> 
> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.

ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 

However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160

From ihse at openjdk.org  Mon May 26 08:20:19 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:19 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
Message-ID: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>

> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Restore MenuShortcut.java
 - Restore LocaleDataTest.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25228/files
  - new: https://git.openjdk.org/jdk/pull/25228/files/9c904992..7184e685

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

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

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

From ihse at openjdk.org  Mon May 26 08:20:46 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:20:46 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
Message-ID: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>

On Thu, 22 May 2025 21:43:20 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> src/java.desktop/share/classes/java/awt/MenuShortcut.java line 49:
> 
>> 47:  * For example, a menu shortcut for "Ctrl+cyrillic ef" is created by
>> 48:  * <p>
>> 49:  * <code>MenuShortcut ms = new MenuShortcut(KeyEvent.getExtendedKeyCodeForChar('?'), false);</code>
> 
> This is javadoc inJava SE specification. As is the Action case below.
> I can't think of any actual harm from this change, so OK,  but I am not seeing why it is needed.

The resulting Javadoc html files will contain the same character before and after this fix, so there is no specification change. 

I did this since I thought it increased readability of the source code, but I can just as well revert it.

> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
> 
>> 61: 
>> 62:     private static final String INSTRUCTIONS =
>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
> 
> I really don't like these tests being changed. It isn't part of the JDK build.
> People compile these in all sorts of locales.
> Please revert all the changes in the client tests.

Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.

The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?

Let me know if you still want me to revert it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106769659
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106791184

From ihse at openjdk.org  Mon May 26 08:21:16 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:21:16 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>

On Mon, 26 May 2025 08:10:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:

> 88:                 printKey(e);
> 89:                 int keychar = e.getKeyChar();
> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b

@prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:

> 186:                     +          "\"After\" lists.\n"
> 187:                     + "              Added printers are highlighted with "
> 188:                     +               "green color, removed ones \u2014 with "

@prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.

Do you still want me to revert it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106774492
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2106778974

From ihse at openjdk.org  Mon May 26 08:24:36 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:36 GMT
Subject: <i18n dev> RFR: 8356980: Better handling of non-breaking space
In-Reply-To: <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
 <Be_UrVUnG8PE3dcqUkycv2dusI4iNZcKfY64Y3s7uyQ=.07f1594b-f093-46af-8e5b-5696752f2bfc@github.com>
 <9SKadVNS-siQPAG2VPshPmaKn0t4KbWMBEz6uUCJrg8=.3c10d375-1a0c-4b9d-adec-da5dc590931b@github.com>
 <PlePdDFsUHbVnpD6H0zKUnoaEc-kB5GSGWg_Ecqd_Tw=.354edab5-2740-4a56-93b2-d45bed87347d@github.com>
 <XHA8bAgqrwhxiuI3wxC_jjuIigiF6oVMDpOloqJQckA=.7a369876-017f-4434-b778-9a771f99f326@github.com>
 <VT3fk16eM5dkMqFkCFV-tmDR8xQ5ZYKUsKSHRrTt_qk=.040f9c30-f433-4985-91e9-6f037e10008d@github.com>
 <aeKwfx6AdeiYXfLC1FOcLSTDxR_j0qG1jNwL2RrQVxU=.66276465-bbc6-4d7b-b622-996c31678501@github.com>
 <bffWy8H4d6xnje0Gz_jIyv5jPBMuqp7S-iBFZTioTng=.7ee33246-76c2-470f-b608-894b5ba93988@github.com>
 <1Z5g-LlFwSPrcqtTBmrDetQQL7_hF0j73n-37JRCpug=.3a763994-156c-44fb-8945-f02b1994e620@github.com>
 <2QcYZvy5pjx8J6Fi6j59uiHSfnqkp1yUHakx2qsxzKw=.d5720f94-adb8-4f86-aeed-e403c8e43066@github.com>
Message-ID: <C8kpgkckLXbObd9FCCt4nkuI9QAc7A9qZHWZsj0Oaz4=.505c65b6-1685-47ef-a4d6-cc48982f6329@github.com>

On Thu, 22 May 2025 21:26:08 GMT, Phil Race <prr at openjdk.org> wrote:

>> FYI, the style guide for France [recommends](https://fr.wikipedia.org/wiki/Espace_ins%C3%A9cable#En_France):
>> 
>> - U+202F (Narrow No-Break Space NNBSP) preceding semicolon, question mark, and exclamation mark.
>> - U+00A0 (No-Break Space NBSP) preceding colon.
>> 
>> Similar conventions are used in other French speaking countries.
>
>> No, it doesn't. I still agree with that fix -- the overwhelming majority of characters should indeed be UTF-8 instead of unicode sequences.
> 
>> This is about a very specific character, that is impossible to visually tell the difference on screen from ordinary space.
> 
> 
> I didn't say it reversed that entire changeset. I am saying that the previous changeset for L10N changed
> 
> the Java unicode escape to UTF-8 for the localised message string.
> 
> You propose restoring it to Java escape.
> 
> 
> I wouldn't be surprised if the next message drop reverses what you reversed.
> 
> I don't know what tools the L10N team use but there's a chance it doesn't handle Java escapes
> 
> since that is very much a Java thing. So you are probably making the translation job harder.
> 
> 
> So I am suggesting you leave all of the translation files as is.
> Which might mean withdrawing this PR.

Fair enough. This was meant to be an improvement in readability, not a hindrance for working efficiently. I'll withdraw this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25234#discussion_r2106804794

From ihse at openjdk.org  Mon May 26 08:24:38 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:24:38 GMT
Subject: <i18n dev> Withdrawn: 8356980: Better handling of non-breaking space
In-Reply-To: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
References: <DPKzlPVZUCB3LCvD9rJ_wtphFJ9JuomN7TuHzasBYtc=.4b6becfa-77e2-4ef1-98cc-4cb03d7d41fb@github.com>
Message-ID: <e4LLN-RARXr9ONGJ35PikxdOZFdsem63EHsN5ZlOr3I=.cd96d653-af8b-4868-b0e0-5c869835d66c@github.com>

On Wed, 14 May 2025 15:11:24 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Non-breaking space characters are problematic. They look identical to the normal space character, but is not. For that reason, it should never be typed as an UTF-8 literal, but only by using unicode sequences.
> 
> I have checked:
> * U+00A0 NO-BREAK SPACE (NBSP)
> * U+202F NARROW NO-BREAK SPACE (NNBSP)
> * U+2007 FIGURE SPACE
> * U+2060 WORD JOINER
> 
> In some places, these character were used when an ordinary space should have been used. I replaced those with normal space. In other places, they were correct, but as literals instead of unicode sequences. I replaced those instances with sequences.

This pull request has been closed without being integrated.

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

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

From ihse at openjdk.org  Mon May 26 08:25:07 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:25:07 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <-HdnkBjrOxo3jUA8jSYhmElKM55oIcSRYYgu70KPR8M=.24dfddf4-6890-4a61-9cef-85f1a2c1238a@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@JoeWang-Java @naotoj Can you help review this PR?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908936863

From ihse at openjdk.org  Mon May 26 08:27:45 2025
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 26 May 2025 08:27:45 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

@justin-curtis-lu Are these files handled by the translation team?

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2908942083

From pminborg at openjdk.org  Mon May 26 11:26:52 2025
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 26 May 2025 11:26:52 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <_DQFSQ_9pkAj4Rf9E-ONh4DavkQTg85zEEPSXS6ok7A=.183704c5-165e-4210-95fe-444fcea4da9e@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

We could add '@Stable` to `static final char[][][] charMap` as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/25430#issuecomment-2909388887

From swen at openjdk.org  Mon May 26 13:19:08 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 26 May 2025 13:19:08 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

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

  add '@stabletostatic final char[][][] charMap`, from @minborg

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25430/files
  - new: https://git.openjdk.org/jdk/pull/25430/files/d5936dd5..d9f0e5e7

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

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

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

From liach at openjdk.org  Mon May 26 22:28:50 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 26 May 2025 22:28:50 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <huMphrE4OYzhSsAlqDG3T1vqophIUzLET8gduuCeQ5k=.e72c5faf-43df-4d21-b808-6c9b2f41bcd8@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

This is a formatting-related class. Calling i18n devs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2910708066

From duke at openjdk.org  Tue May 27 15:38:15 2025
From: duke at openjdk.org (Edoardo Luppi)
Date: Tue, 27 May 2025 15:38:15 GMT
Subject: <i18n dev> RFR: 8266013: Unexpected replacement character
 handling on stateful CharsetEncoder [v2]
In-Reply-To: <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
References: <SoeZ13f8UIKlpsttywQzetNsNB6YjXdKNWOzPsnxDNA=.36e520b1-97a6-40aa-9f93-69265f54d553@github.com>
 <8MYxd4bq0m2zaz9_M8ty4OcFqCkzDGTcXcRLFbzKdoU=.58825ee2-dd9f-4690-8bdc-8d5955bb7d51@github.com>
Message-ID: <NwSIpRvx4tOynwQgJfO7LrFPL90NOcvcnIdXqROhrE4=.1f37bd6d-8b34-40ee-a30d-35df33f081c6@github.com>

On Fri, 30 Apr 2021 16:11:30 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> When an invalid character is converted by getBytes() method, the character is converted to replacement byte data.
>> Shift code (SO/SI) may not be added into right place by EBCDIC Mix charset.
>> EBCDIC Mix charset encoder is stateful encoder.
>> Shift code should be added by switching character set.
>> On x-IBM1364, "\u3000\uD800" should be converted to "\x0E\x40\x40\x0F\x6F", but "\x0E\x40\x40\x6F\x0F"
>> SI is not in right place.
>> 
>> Also ISO2022 related charsets use escape sequence to switch character set.
>> But same kind of issue is there.
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8266013: Unexpected replacement character handling on stateful CharsetEncoder

Hey! Any way this PR could be picked up again? It could be split into two parts, one for EBCDIC, and one for ISO.  
The EBCDIC part should be straightforward as it should not impact template files.

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

PR Comment: https://git.openjdk.org/jdk/pull/3719#issuecomment-2913031847

From joehw at openjdk.org  Tue May 27 16:27:56 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 27 May 2025 16:27:56 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <L9gE2vcTtRmCj8sVb2Mf80vASRun10hEhdF8OJDXDQs=.f32fe500-e46b-4bab-b73c-b78f80723449@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

java.xml changes look good to me. But as you already asked, the translation team owns most of these files.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25229#pullrequestreview-2871771071

From jlu at openjdk.org  Tue May 27 16:34:52 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 16:34:52 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
 <rtLeXcGYPjdVH16A5db5VvNl3AFbcqwVQYzbrrYZrZo=.5bdee26b-cc5f-4834-9cf3-f710cb34c0a0@github.com>
Message-ID: <oD07jz4sbaXmrAQXxWt9B31R7oYM1rYfg30hH9d0-Kc=.f3b6cd24-8e2e-4e77-b9dd-4ea4511b64c5@github.com>

On Mon, 26 May 2025 08:25:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.
>
> @justin-curtis-lu Are these files handled by the translation team?

@magicus The ones under java.xml and jdk.jdi are updated by the translation team, I think it'd be best to remove those files from this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913234396

From naoto at openjdk.org  Tue May 27 16:37:56 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:37:56 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <5oMrogxJyi1_OsPAGntbPTiR5aCIFOTuDSUTKOv7wyo=.b715c9d2-0cdd-4585-a262-bdbe5a72a5fa@github.com>
 <lt8vg3M1QU-xbe_E0l4n1j9V9sM_0VsM8kOt11Mk1L0=.d6e6845c-ff78-45f2-8f8e-6a40b9e12ba1@github.com>
Message-ID: <rUvIFs4xs4inLQJ40ELv5mF0_MjWmQMrZ5VTSmltBnk=.80b73a56-2930-4ce3-ace5-c25766698954@github.com>

On Mon, 26 May 2025 07:44:30 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/sun/text/resources/LocaleDataTest.java line 106:
>> 
>>> 104:  *        FormatData/fr_FR/MonthNames/0=janvier
>>> 105:  *        FormatData/fr_FR/MonthNames/1=f?vrier
>>> 106:  *        LocaleNames/fr_FR/US=?tats-Unis
>> 
>> This test data (LocaleData.cldr) is explicitly encoded in ISO-8859-1 with unicode escapes for characters outside of it. So only changing these ones in comment does not seem correct.
>
> ISO-8859-1 does not sound good, and got me worried. But in fact it seems like the file is pure ASCII, and that is fine. 
> 
> However, if the file should ever be changed to include actual ISO-8859-1 encoding, this might break if tools assume it is UTF-8-encoding, since not all ISO-8859-1 encodings are valid UTF-8.

Thanks. Filed an issue to change the encoding in the test to UTF-8: https://bugs.openjdk.org/browse/JDK-8357882

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2109668481

From naoto at openjdk.org  Tue May 27 16:52:55 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 16:52:55 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
Message-ID: <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>

On Mon, 26 May 2025 13:19:08 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add '@stabletostatic final char[][][] charMap`, from @minborg

Nice refactoring. 
As to C-style array rewrite, I am not so keen on that as they only appear in the generated source files, without any actual benefit.

src/java.base/share/classes/java/lang/CharacterData01.java.template line 30:

> 28: import jdk.internal.vm.annotation.Stable;
> 29: 
> 30: /** The CharacterData class encapsulates the large tables once found in

Taking this opportunity, I'd rectify the comment here (and in other templates too): `CharacterData` -> `CharacterData01`

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

PR Review: https://git.openjdk.org/jdk/pull/25430#pullrequestreview-2871829996
PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2109689029

From jlu at openjdk.org  Tue May 27 17:00:50 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 27 May 2025 17:00:50 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <SlVuKVaKBTltXCUo-8hmXtBrzws2qhp3nZpnU-gi_p0=.7c3ced55-044b-4650-b63d-e88794e72821@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

Change looks good to me, since the previous code causes conflicts where `getStringBuilder` is called during debugging. Did not see any usages of `DigitList.toString()` by us as well.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25288#pullrequestreview-2871861188

From naoto at openjdk.org  Tue May 27 17:03:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:03:53 GMT
Subject: <i18n dev> RFR: 8356978: Convert unicode sequences in Java
 source code to UTF-8
In-Reply-To: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
References: <ZOYNOpyNkt-QN3GrEF2co7L9l0O9QQ5ljldAnQtmcWo=.dab0bf8f-c326-4ee3-a3ce-15bfcd5c5218@github.com>
Message-ID: <b0f0ldjIu6qI6gHCIZj-QuqZdUZ87_2s2znpk2gkmwY=.8d297170-8ec9-4710-9cea-be3b3fe9db03@github.com>

On Wed, 14 May 2025 14:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> After we converted the source base to be fully UTF-8, we do not need to use unicode sequences (like \u0123) in string literals. Sometimes, that might still make sense, as for control characters, non-breaking space, etc. But for strings that is supposed to be a coherent text in a language that needs non-ASCII parts of Unicode, this is not so. Instead, having the sequences makes the text just harder to read and edit. We have already removed several such sequences before, but some remains.

Those TimeZoneNames* resource bundles are in fact leftovers from COMPAT locale provider removal. I am going to remove those files later so you can exclude them.

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

PR Comment: https://git.openjdk.org/jdk/pull/25229#issuecomment-2913310841

From duke at openjdk.org  Tue May 27 17:13:52 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Tue, 27 May 2025 17:13:52 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

src/java.base/share/classes/java/text/DigitList.java line 787:

> 785:         }
> 786: 
> 787:         return "0." + new String(digits, 0, count) + "x10^" + decimalAt;

what about

        return new StringBuilder()
                .append("0.")
                .append(digits, 0, count)
                .append("x10^")
                .append(decimalAt)
                .toString();

to avoid the temporary string created by `new String(digits, 0, count)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25288#discussion_r2109740606

From aivanov at openjdk.org  Tue May 27 17:19:07 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 27 May 2025 17:19:07 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <_jvr0WzcP-UyJuR_N75_POTFnJNkKaV8gk1r1oI3PkE=.d35f882a-dc77-47a9-b4ec-e8bbd3983f33@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

Looks good.

I'll submit a test job.

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 171:

> 169:             System.out.println("[Simple test failed!!]");
> 170:             throw new RuntimeException(
> 171:                     "Test failed didn't return " + expected + "-sized array");

Suggestion:

                    "Test didn't return " + expected + "-sized array");

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2871915591
PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2109746291

From naoto at openjdk.org  Tue May 27 17:20:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 May 2025 17:20:51 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <bWkjUEQ7-oxryAzUfwMV49fQuVyilKtkpI1H8WNfO5M=.f76ec910-093b-49f4-a44e-324d5bc21126@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25288#pullrequestreview-2871923961

From serb at openjdk.org  Tue May 27 17:38:32 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 27 May 2025 17:38:32 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

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

  Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25401/files
  - new: https://git.openjdk.org/jdk/pull/25401/files/36560145..afb10b6d

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

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

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

From swen at openjdk.org  Tue May 27 19:26:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:26:51 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v2]
In-Reply-To: <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <QfFJJ4dvvF4On-SP4TG837AIKICxgaQ1t_Nr8qTmPA8=.4b039e7a-4ff2-4254-87c9-7cd048c77304@github.com>
 <RtSz5dpekriWi1a1aXKjsINDyfLslrfnSXoBJ2OGtRY=.c3949ca4-2457-441d-beb9-443d1ac69873@github.com>
Message-ID: <h7xeH1Wq3RCo5p23gdh2391XTwiYE6y3OTjp8BDIM1Y=.7d03c6c1-d092-4a54-b763-ba04f73ab63c@github.com>

On Tue, 27 May 2025 16:50:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Nice refactoring. As to C-style array rewrite, I am not so keen on that as they only appear in the generated source files, without any actual benefit.

You and @cl4es both mentioned this, and I agree, but it should be another PR to remove it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25430#issuecomment-2913749558

From swen at openjdk.org  Tue May 27 19:32:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:32:33 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

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

  fix comments, from @natoj

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25430/files
  - new: https://git.openjdk.org/jdk/pull/25430/files/d9f0e5e7..46b79333

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

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

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

From vyazici at openjdk.org  Tue May 27 19:33:55 2025
From: vyazici at openjdk.org (Volkan Yazici)
Date: Tue, 27 May 2025 19:33:55 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

_Nit:_ Would it be an overkill to add a test (verifying `toString` doesn't spoil the content) to avoid falling on the same slippery slope (i.e., _"Let me optimize this by reusing the `SB`!"_) again?

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

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913768494

From swen at openjdk.org  Tue May 27 19:38:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:38:51 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <JLz-9Ki-8Rlw33Dj9qQ4OY43ezpxt-EvxGg01nFhkMA=.7137277f-3316-485a-9602-d22eb6a45d2b@github.com>
Message-ID: <5SvVx2xvFNZoxu4t0vVrwH2E09vwFe5ZZteeEh7cvlw=.84c38873-8623-4a99-93ba-c0dd4c24419a@github.com>

On Tue, 27 May 2025 17:11:41 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.
>
> src/java.base/share/classes/java/text/DigitList.java line 787:
> 
>> 785:         }
>> 786: 
>> 787:         return "0." + new String(digits, 0, count) + "x10^" + decimalAt;
> 
> what about
> 
>         return new StringBuilder()
>                 .append("0.")
>                 .append(digits, 0, count)
>                 .append("x10^")
>                 .append(decimalAt)
>                 .toString();
> 
> to avoid the temporary string created by `new String(digits, 0, count)`

Using the String concatenation operator looks cleaner.

In the core library, they are effectively the same, and JEP 280 Indify String Concatenation is not available in the core library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25288#discussion_r2110047144

From swen at openjdk.org  Tue May 27 19:47:54 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 27 May 2025 19:47:54 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
Message-ID: <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>

On Tue, 27 May 2025 19:31:44 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

> _Nit:_ Would it be an overkill to add a test (verifying `toString` doesn't spoil the content) to avoid falling on the same slippery slope (i.e., _"Let me optimize this by reusing the `SB`!"_) again?

The original code that calls getStringBuilder() is this code:

    private StringBuilder tempBuilder;

    private StringBuilder getStringBuilder() {
        if (tempBuilder == null) {
            tempBuilder = new StringBuilder(MAX_COUNT);
        } else {
            tempBuilder.setLength(0);
        }
        return tempBuilder;
    }


This is a concurrency problem, which is triggered during the DEBUG process.

To test this concurrency problem, we need to build a concurrent competition test, which is not a simple task, so I did not add it.

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

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913802759

From rriggs at openjdk.org  Tue May 27 20:01:52 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 20:01:52 GMT
Subject: <i18n dev> RFR: 8334742: Change java.time month/day field types
 to 'byte' [v2]
In-Reply-To: <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
 <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
Message-ID: <63G95td2niDaQ-BWdk-DIJ6T6NJVapvrbmUD_Lp6Yys=.f966f91f-0d00-46d4-b48f-b67de8cd6090@github.com>

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

Looks good

Passed CI tier 1-3.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24975#pullrequestreview-2872433491
PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2913852479

From rriggs at openjdk.org  Tue May 27 20:10:51 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 27 May 2025 20:10:51 GMT
Subject: <i18n dev> RFR: 8357681: Fixed the DigitList::toString method
 causing incorrect results during debugging
In-Reply-To: <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
 <GvXiOCW-GHsVGQp2cgvlXhKC6fbIfbVd9rsWsvINvPg=.36d618a3-5734-485c-afe7-496397fb2de3@github.com>
 <VpMiH0nUcC3wi8YJqV1sXxEVNyu4gZj6RkYYAHIYK7g=.8cd8089c-99ec-4a30-bee0-77adbbe1079b@github.com>
Message-ID: <tn8O7WQtmagXZcCSCyGpzPboPQU4kQknSikSY7pE9tk=.569a4270-4757-42fc-8836-b94c1346ff87@github.com>

On Tue, 27 May 2025 19:44:55 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> To test this concurrency problem, we need to build a concurrent competition test, which is not a simple task, so I did not add it.

The label `noreg-hard` would be appropriate to indicate a test was not created due to difficulty.
That label though conflicts with the current label `noreg-trivial` implying there is an existing test and the change is not significant. It will look odd, but both labels make sense.
[OpenJDK Developers guide](https://openjdk.org/guide/#jbs-label-dictionary)

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

PR Comment: https://git.openjdk.org/jdk/pull/25288#issuecomment-2913885924

From duke at openjdk.org  Wed May 28 15:26:59 2025
From: duke at openjdk.org (duke)
Date: Wed, 28 May 2025 15:26:59 GMT
Subject: <i18n dev> RFR: 8334742: Change java.time month/day field types
 to 'byte' [v2]
In-Reply-To: <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
 <AUY5jIW8j9Su5dADRCUul9pql3xc1DtiNdrDPtCywC4=.7c91f6fd-db4b-4d87-8d89-3a022549330a@github.com>
Message-ID: <s7wJOMR-ScTN0jARROPecVvmZBcvQyorY0AfO8-AEwg=.ba32b193-eaa6-4087-a183-cc178b563fde@github.com>

On Wed, 30 Apr 2025 20:38:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

>> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
>> 
>> java.time.YearMonth
>> java.time.MonthDay
>> java.time.LocalDate
>> java.time.chono.HijrahDate
>> 
>> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.
>
> Gautham Krishnan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright header

@gauthamkrishnanibm 
Your change (at version 148c3834c7e80d23d4d61be2829a2648bae1f121) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24975#issuecomment-2916751427

From duke at openjdk.org  Wed May 28 15:40:57 2025
From: duke at openjdk.org (Gautham Krishnan)
Date: Wed, 28 May 2025 15:40:57 GMT
Subject: <i18n dev> Integrated: 8334742: Change java.time month/day field
 types to 'byte'
In-Reply-To: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
References: <AZ0_rhZGLcX4I7NuxtGcP1pVzGAr7KXu8FObV6kMxZ8=.2b7d3dc8-1cf8-40d9-bef2-8164282e02e8@github.com>
Message-ID: <17YnNT2fOIDp7izaRgC1YcksZ_NYp7CwT6dhNbuwnZY=.a5ed189c-f7ef-43c3-ad5c-1241b516088d@github.com>

On Wed, 30 Apr 2025 20:30:59 GMT, Gautham Krishnan <duke at openjdk.org> wrote:

> In the following classes, month and day values are stored in fields of type 'int' or 'short'. The range of allowed values is small enough that the type can be 'byte' instead.
> 
> java.time.YearMonth
> java.time.MonthDay
> java.time.LocalDate
> java.time.chono.HijrahDate
> 
> Refactoring the type will give the JVM a little more layout flexibility, and will be especially useful when these classes become value classes.

This pull request has now been integrated.

Changeset: 4ced4e73
Author:    gauthamkrishnanibm <gautham.k at ibm.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4ced4e73fc0a517df826860839681004bb67e624
Stats:     17 lines in 4 files changed: 0 ins; 0 del; 17 mod

8334742: Change java.time month/day field types to 'byte'

Reviewed-by: rriggs

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

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

From jlu at openjdk.org  Wed May 28 17:04:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 28 May 2025 17:04:07 GMT
Subject: <i18n dev> RFR: 8348328: Update IANA Language Subtag Registry to
 Version 2025-05-15
Message-ID: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>

Please review this PR which updates the language subtag registry to Version 2025-05-15.

LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

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

Commit messages:
 - init

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

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

From iris at openjdk.org  Wed May 28 17:47:50 2025
From: iris at openjdk.org (Iris Clark)
Date: Wed, 28 May 2025 17:47:50 GMT
Subject: <i18n dev> RFR: 8348328: Update IANA Language Subtag Registry
 to Version 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <5GIrP4HoAjltFSJe49hO6N8AWpcK-S6aobf4DT9GtBc=.1ad6fa80-5d14-4d89-981a-4261799fc575@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

Confirmed changes in lsrdata and test files correspond to those found in IANA Language Subtag Registry file dated 2025-05-15 as expected.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25503#pullrequestreview-2875936643

From naoto at openjdk.org  Wed May 28 18:57:53 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 18:57:53 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
Message-ID: <OKanBhuFL1Bblty6O8jfKbNBQrWTeCq7kgXSmXOh_dM=.3dd8659d-ff9f-427f-86ac-277fbe74e8fd@github.com>

On Tue, 27 May 2025 19:32:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments, from @natoj

LGTM. Thanks for the changes.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25430#pullrequestreview-2876123518

From duke at openjdk.org  Wed May 28 19:24:52 2025
From: duke at openjdk.org (ExE Boss)
Date: Wed, 28 May 2025 19:24:52 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
Message-ID: <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>

On Tue, 27 May 2025 19:32:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix comments, from @natoj

src/java.base/share/classes/java/lang/CharacterData00.java.template line 36:

> 34: 
> 35: final class CharacterData00 extends CharacterData {
> 36:     /* The character properties are currently encoded into 32 bits in the following manner:

Maybe?also add?the?table `B`?comment from?`GenerateCharacter` to?these?comments:
https://github.com/openjdk/jdk/blob/28f509317d477c5f4076658f9ae9995aa6c53631/make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java#L158-L171

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2112589819

From naoto at openjdk.org  Wed May 28 20:17:51 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 20:17:51 GMT
Subject: <i18n dev> RFR: 8348328: Update IANA Language Subtag Registry
 to Version 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <PbaL47p0z6b2-BDkrkoMQQjxDZYYurDR8QB7oqZtzDg=.370ea60e-da54-4bf2-9fa4-873318fcc1f7@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25503#pullrequestreview-2876307424

From swen at openjdk.org  Wed May 28 20:39:59 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 28 May 2025 20:39:59 GMT
Subject: <i18n dev> Integrated: 8357681: Fixed the DigitList::toString
 method causing incorrect results during debugging
In-Reply-To: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
References: <hFQy-bYGvo1R01p1BF1jwPPIzd38U3OTAbHexHK7MlA=.dc588df9-910f-4e11-b2c5-19cace7d7a93@github.com>
Message-ID: <MGZLJgfgPderAxpg81pC8ITmx_H8PtFEsCZQZVcdVFk=.db2454e9-f1dd-4543-860f-6eea597cd0f1@github.com>

On Sun, 18 May 2025 11:11:32 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> When debugging getLong/getDouble/getDecimal of DigitList, the debugger will call the DigitList::toString method. At this time, DigitList::toString will modify tempBuilder, which will cause incorrect results.

This pull request has now been integrated.

Changeset: b7f0f480
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7f0f480cefb7295bbd5f8830458b69baf2eaff6
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8357681: Fixed the DigitList::toString method causing incorrect results during debugging

Reviewed-by: jlu, naoto

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

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

From naoto at openjdk.org  Wed May 28 20:55:03 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: <i18n dev> RFR: 8357275: Locale.Builder.setLanguageTag should
 mention conversions made on language tag [v4]
In-Reply-To: <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
 <LH9qT9TNFE_IvRsRhE7az6ilAj_RC4j5SPbmZk-jnRI=.18c87588-a90e-4a75-b9c7-ac29df858fbe@github.com>
Message-ID: <hQ8P2AMEt9FEqBUPtyDyLGkZlGuBEykqL3w7JKKTyU0=.45c367d6-d0fc-4c99-93d4-b05ba19a2f84@github.com>

On Wed, 21 May 2025 20:41:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review - clarify that 3 extlang subtags is not a JDK specific condition

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25309#pullrequestreview-2876400699

From prr at openjdk.org  Wed May 28 20:55:03 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:03 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
 <_lcOdATdXG3Y_jW5Tl0xJkrVZ-hoWs-2U7Cp3NvQtqk=.eea31f34-72c6-4acd-bce9-38ab18c41509@github.com>
Message-ID: <Dq8Agr8pnvykN7oNGPzTQnNO77rhD_M8j1caxF-mY4M=.867b19b6-ce18-4656-b52b-4fd5ec84d834@github.com>

On Mon, 26 May 2025 07:55:52 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Restore MenuShortcut.java
>>  - Restore LocaleDataTest.java
>
> test/jdk/java/awt/event/KeyEvent/KeyTyped/EscapeKeyTyped.java line 90:
> 
>> 88:                 printKey(e);
>> 89:                 int keychar = e.getKeyChar();
>> 90:                 if (keychar == 27) { // Escape character is 27 or \u001b
> 
> @prrace I think this is an actual bug. `\u0021` codes to `!`, and I don't think that is what was meant. Do you still want me to revert it?

You are right, that's a typo. Keep your change.
And I don't know why the code uses literal 27 instead of KeyEvent.VK_ESCAPE .. but that's not your problem.

https://docs.oracle.com/en/java/javase/21/docs/api/constant-values.html#java.awt.event.KeyEvent.VK_ESCAPE

> test/jdk/java/awt/print/RemotePrinterStatusRefresh/RemotePrinterStatusRefresh.java line 188:
> 
>> 186:                     +          "\"After\" lists.\n"
>> 187:                     + "              Added printers are highlighted with "
>> 188:                     +               "green color, removed ones \u2014 with "
> 
> @prrace This too seems like a bug, or rather a typo. The text currently reads `Added printers are highlighted with green color, removed ones ? with red color.`. The Em dash does not make any sense to me, and seems to be a copy paste error.
> 
> Do you still want me to revert it?

I agree. Keep your change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112722311
PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112731040

From prr at openjdk.org  Wed May 28 20:55:04 2025
From: prr at openjdk.org (Phil Race)
Date: Wed, 28 May 2025 20:55:04 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <jO8_Rg8XVb6CjtA56LiKdFLPBpcVW4pYYeI-u6jQxVc=.6110d5d2-c1c9-4aa5-8cdf-244d54eab5fd@github.com>
 <7ThvxIdX5OQ98gW8wZwPjX00teKmjP1qm1DT8olo-30=.64a982f0-92fc-46da-af79-8c3696e99258@github.com>
Message-ID: <BW-jmv0CMo_qRngDZcLpY3s8yH_WYkD_YyhGiDyDeVU=.5292f832-a0ab-4a8f-9792-6c8005697e45@github.com>

On Mon, 26 May 2025 08:07:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> test/jdk/java/awt/font/TextLayout/RotFontBoundsTest.java line 63:
>> 
>>> 61: 
>>> 62:     private static final String INSTRUCTIONS =
>>> 63:             "A string \u201C" + TEXT + "\u201D is drawn at eight different "
>> 
>> I really don't like these tests being changed. It isn't part of the JDK build.
>> People compile these in all sorts of locales.
>> Please revert all the changes in the client tests.
>
> Just a clarification. What I did was convert curly quotes and an em dash to normal ASCII quotes and an ASCII hyphen, just as it is in all other `INSTRUCTIONS` in the tests. This is similar to what was done in JDK-8354273 and JDK-8354213, and should have been made as part of those PRs if I only had noticed this place by then.
> 
> The user's locale should not really matter. When have stringent locale requirements for building, and automatically setup the correct locale while building. I don't think the locale will matter at runtime either, but it n the rare case that it should matter, then pure ASCII would be prefer, wouldn't it?
> 
> Let me know if you still want me to revert it.

I'd like this reverted.
People *build* these tests in their local repos using javac and whatever their locale is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25228#discussion_r2112728971

From swen at openjdk.org  Thu May 29 01:00:52 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 May 2025 01:00:52 GMT
Subject: <i18n dev> RFR: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes [v3]
In-Reply-To: <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
 <6Fsxo4CXaVfTdKQ_DsbdIn3uQ0170SX98zdjbs5HL7o=.e296b38e-3390-40d2-937c-595ca509e884@github.com>
 <QiIvCIqFDm8VveR2XA4pugfUfmkf5L_qjlHMedtIWb8=.a55ebde8-71ff-474e-b646-1e2d8f844389@github.com>
Message-ID: <KWq-_5aInoF_pvsx-9tzfLPjp-kroxbM8I885MyLASA=.9262f283-4361-4177-939b-69bdb9368305@github.com>

On Wed, 28 May 2025 19:20:08 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix comments, from @natoj
>
> src/java.base/share/classes/java/lang/CharacterData00.java.template line 36:
> 
>> 34: 
>> 35: final class CharacterData00 extends CharacterData {
>> 36:     /* The character properties are currently encoded into 32 bits in the following manner:
> 
> Maybe?also add?the?table `B`?comment from?`GenerateCharacter` to?these?comments: <https://github.com/openjdk/jdk/blob/28f509317d477c5f4076658f9ae9995aa6c53631/make/jdk/src/classes/build/tools/generatecharacter/GenerateCharacter.java#L158-L171>

That's right, but it should be a separate PR

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25430#discussion_r2112986499

From naoto at openjdk.org  Thu May 29 16:58:30 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 16:58:30 GMT
Subject: <i18n dev> RFR: 8357886: Remove TimeZoneNames_* of the COMPAT
 locale data provider
Message-ID: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>

These resource files are remnants from the removal of the COMPAT locale provider. Since the COMPAT provider has been removed, these localizations should also be cleaned up.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Thu May 29 17:03:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:03:57 GMT
Subject: <i18n dev> RFR: 8348328: Update IANA Language Subtag Registry
 to Version 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <5TsTuCq4JDRI1NCn965lkEVG0i8UApEq23_yJur1550=.2dfc6eae-b637-4a80-bd06-68587fd36d88@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/25503#issuecomment-2920015564

From jlu at openjdk.org  Thu May 29 17:03:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:03:58 GMT
Subject: <i18n dev> Integrated: 8348328: Update IANA Language Subtag
 Registry to Version 2025-05-15
In-Reply-To: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
References: <XynO7KHq4Y9jX8OzOfhzUUyArLxLPDUJ4jZxrSW61GI=.485105d6-3fce-4cd2-9311-687409fd87b5@github.com>
Message-ID: <WzLg3fwM_bpPMWrzzCxE6MHw3lPWoAgwXrFAdZYtykY=.f47f1553-7897-4594-b770-7f8b069ce490@github.com>

On Wed, 28 May 2025 17:00:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the language subtag registry to Version 2025-05-15.
> 
> LanguageSubtagRegistryTest.java was updated with the preferred-values: `hnm`, `eko`, `luh`,`sjc`, `sqm`. A small change was also made to the test to improve the output as well.

This pull request has now been integrated.

Changeset: f3188682
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f318868268f32934a2f0c4e26a6c75360d8e74b1
Stats:     143 lines in 2 files changed: 135 ins; 1 del; 7 mod

8348328: Update IANA Language Subtag Registry to Version 2025-05-15

Reviewed-by: iris, naoto

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

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

From naoto at openjdk.org  Thu May 29 17:24:25 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 17:24:25 GMT
Subject: <i18n dev> RFR: 8357882: Use UTF-8 encoded data in LocaleDataTest
Message-ID: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>

Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

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

Commit messages:
 - initial commit

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

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

From jlu at openjdk.org  Thu May 29 17:38:53 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:38:53 GMT
Subject: <i18n dev> RFR: 8357882: Use UTF-8 encoded data in
 LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <zQWfRYBmu0ASScYOeo3qVB-qNV648vh6Bgkjs16TDpc=.797454f6-050b-48de-b50c-087f7e4e3002@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Test change looks good. Skimmed the data change, which also looks to be converted correctly.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25524#pullrequestreview-2879093984

From jlu at openjdk.org  Thu May 29 17:41:56 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 17:41:56 GMT
Subject: <i18n dev> Integrated: 8357275: Locale.Builder.setLanguageTag
 should mention conversions made on language tag
In-Reply-To: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
References: <AdSvfmGupueu-3hb-HNQK4TFFkTgJqD2PfUTpMDa5JY=.d8fe28fe-d97b-434e-902b-7a8adbf37ceb@github.com>
Message-ID: <wyyIY4-PeDbEW7jda_3G8lBkA5KZHKbEe55N5ujXK3U=.35c05f11-7874-46da-97b0-39b1102660f7@github.com>

On Mon, 19 May 2025 20:56:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> It is not clear that `Locale.Builder.setLanguageTag(String)` accepts _extlang_ subtags in the input as well as what behavior occurs. Additionally, both this method and `Locale.forLanguageTag(String)` should mention their behavior when more than three _extlang_ subtags are provided. This PR clarifies the lack of context in the specification.

This pull request has now been integrated.

Changeset: e509997f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e509997fe87a09513b8f79d303cc69392d2cb7b0
Stats:     13 lines in 1 file changed: 9 ins; 0 del; 4 mod

8357275: Locale.Builder.setLanguageTag should mention conversions made on language tag

Reviewed-by: naoto

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

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

From joehw at openjdk.org  Thu May 29 18:37:51 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 29 May 2025 18:37:51 GMT
Subject: <i18n dev> RFR: 8357882: Use UTF-8 encoded data in
 LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <e6Y46iDdjto8PBSh_c_oUa8Vh0iVasJ8YzazPM8E7z8=.30300c2d-8fd2-415b-8f01-d65f0ee6a3e9@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25524#pullrequestreview-2879251465

From jlu at openjdk.org  Thu May 29 19:06:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 19:06:01 GMT
Subject: <i18n dev> RFR: 8358089: GenerateKeyList.java COMPAT removal update
Message-ID: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>

Please review this PR which updates the test tool `GenerateKeyList.java` after the COMPAT locale data removal.

`LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool; the latter requires similar bundle name changes that were made to the former in https://bugs.openjdk.org/browse/JDK-8357075.

Additionally, the CollationData bundle name needs to be adjusted to properly retrieve its contents. This was not previously exposed because `LocaleData.cldr` does not contain any CollationData entries.

We may also want to consider moving `GenerateKeyList.java` into the same space as `LocaleDataTest.java`.

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

Commit messages:
 - init

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

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

From joehw at openjdk.org  Thu May 29 19:07:52 2025
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 29 May 2025 19:07:52 GMT
Subject: <i18n dev> RFR: 8357886: Remove TimeZoneNames_* of the COMPAT
 locale data provider
In-Reply-To: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
References: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
Message-ID: <bmvJ96JN2QaHUidyGpwKLc4ZhS4Yv8mWIfMUi-83_V4=.75803083-830d-4402-b7ff-b2c48d714623@github.com>

On Thu, 29 May 2025 16:54:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> These resource files are remnants from the removal of the COMPAT locale provider. Since the COMPAT provider has been removed, these localizations should also be cleaned up.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25523#pullrequestreview-2879325975

From prr at openjdk.org  Thu May 29 19:08:54 2025
From: prr at openjdk.org (Phil Race)
Date: Thu, 29 May 2025 19:08:54 GMT
Subject: <i18n dev> RFR: 8356977: UTF-8 cleanups [v2]
In-Reply-To: <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
References: <s4znWc8WCK3liY8YOhRldnBN7yPJr8m-doBeEArSHd0=.0632ae03-da95-4bd5-865f-e8276544bed5@github.com>
 <QDrGzqvDzyZaQMSG3oplXlRSGMmGAMsQPeNnu8G4msU=.5f385862-0ca1-4b20-a31d-0c9e142728b7@github.com>
Message-ID: <dVw-4Yl3AI2y1kYAwY1rgjjRrqCSiIVv2UN-UHuJtB0=.81a20509-7795-4ad7-b7c9-f42970d65318@github.com>

On Mon, 26 May 2025 08:20:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> I found a few other places in the code that can be cleaned up after the conversion to UTF-8.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Restore MenuShortcut.java
>  - Restore LocaleDataTest.java

Approving client changes

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

Marked as reviewed by prr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25228#pullrequestreview-2879326497

From swen at openjdk.org  Thu May 29 20:12:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 29 May 2025 20:12:58 GMT
Subject: <i18n dev> Integrated: 8357690: Add @Stable and final to
 java.lang.CharacterDataLatin1 and other CharacterData classes
In-Reply-To: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
References: <teOlauV1JnaNUwl5Wise8lvBhCTfl5yekfHZAICGtws=.df31e0ea-9ff1-4464-84fb-f0c86431bceb@github.com>
Message-ID: <7onUACDyYrLjYSMiewPjLvMtTiID2M4ADzDal-6AiXY=.24cfeec5-1a33-428d-a752-cbbd9a57d738@github.com>

On Sat, 24 May 2025 10:00:56 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Classes such as java.lang.CharacterDataXXX have multiple static final arrays, these are immutable, We should add `@Stable` and final to provide information to the optimizer.

This pull request has now been integrated.

Changeset: 727412d1
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/727412d1b5f0764363ebd2ff600d4b7f0c99bb9b
Stats:     39 lines in 10 files changed: 15 ins; 0 del; 24 mod

8357690: Add @Stable and final to java.lang.CharacterDataLatin1 and other CharacterData classes

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Thu May 29 21:19:31 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 21:19:31 GMT
Subject: <i18n dev> RFR: 8358089: Remove the GenerateKeyList.java test
 tool [v2]
In-Reply-To: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
Message-ID: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>

> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
> 
> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.

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

  reflect some corrections

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25527/files
  - new: https://git.openjdk.org/jdk/pull/25527/files/f4313c47..807486d2

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

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

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

From jlu at openjdk.org  Thu May 29 21:19:32 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 21:19:32 GMT
Subject: <i18n dev> RFR: 8358089: Remove the GenerateKeyList.java test
 tool [v2]
In-Reply-To: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
 <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
Message-ID: <sk_f1pftfLq8F2QSugSn2KeD-BwufHs0Ppav3Wx1d6k=.1149574f-7e84-4bba-8d88-be630bb98391@github.com>

On Thu, 29 May 2025 21:15:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
>> 
>> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect some corrections

test/jdk/sun/text/resources/LocaleDataTest.java line 333:

> 331:                     || rbName.equals("TimeZoneNames")) {
> 332:                 fullName = UTIL_RESOURCES_PACKAGE + "." + rbName;
> 333:             } else if (rbName.equals("CollationData")) {

CLDR does not define CollationData, so this type of check actually needs to be removed, since we should not be including any CLDR data in the LocaleData.cldr file in the first place.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25527#discussion_r2114760076

From jlu at openjdk.org  Thu May 29 21:25:51 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 21:25:51 GMT
Subject: <i18n dev> RFR: 8357886: Remove TimeZoneNames_* of the COMPAT
 locale data provider
In-Reply-To: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
References: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
Message-ID: <urFAt2KeWYYfwlqxNxEK88miahQ-nnFbVhNDsuprE7I=.cfbc3467-2a14-40a5-8f31-865642223eac@github.com>

On Thu, 29 May 2025 16:54:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> These resource files are remnants from the removal of the COMPAT locale provider. Since the COMPAT provider has been removed, these localizations should also be cleaned up.

Looks good.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25523#pullrequestreview-2879647280

From naoto at openjdk.org  Thu May 29 21:38:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 21:38:50 GMT
Subject: <i18n dev> RFR: 8358089: Remove the GenerateKeyList.java test
 tool [v2]
In-Reply-To: <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
 <ZaMD7yGGqrfuB0pNrC9lbb2A0ciAE9X7wnp5l8vi800=.17f42c84-207d-4801-a5b5-3f82ecef784b@github.com>
Message-ID: <qHJ_yazI9DwpKFoizz1PU3Ybb1cZY3V2spi0xm67oao=.e8b53805-37fc-4883-9deb-9f4708818339@github.com>

On Thu, 29 May 2025 21:19:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
>> 
>> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect some corrections

LGTM. The manual tool hasn't been used and it does not cope with CLDR. Removing the tool would be appropriate.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25527#pullrequestreview-2879670600

From jlu at openjdk.org  Thu May 29 22:04:03 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 29 May 2025 22:04:03 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR
Message-ID: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>

Please review this PR which cleans up some i18n tests.

There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 

As this change is trivial cleanup, bug IDs are not updated in this change.

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

Commit messages:
 - init

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

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

From bpb at openjdk.org  Thu May 29 22:14:53 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 May 2025 22:14:53 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <3JZoZQCj83-RwLWCtteqEOha_MKEuMAzLAlAuoTVm-k=.957d4703-17f5-4da4-ad56-dad50b694e26@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2879728852

From naoto at openjdk.org  Thu May 29 22:49:50 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 29 May 2025 22:49:50 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>

On Thu, 29 May 2025 21:59:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

Probably we can remove `/othervm` from those `@run` directives?

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

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2920752452

From jlu at openjdk.org  Fri May 30 00:20:26 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 00:20:26 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v2]
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

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

  reflect review: strip othervm mode + cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25532/files
  - new: https://git.openjdk.org/jdk/pull/25532/files/23cb3a2d..2eb1edd5

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

  Stats: 71 lines in 20 files changed: 0 ins; 51 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/25532.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25532/head:pull/25532

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

From bpb at openjdk.org  Fri May 30 00:20:26 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 00:20:26 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v2]
In-Reply-To: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
Message-ID: <pwtZUjrj85GoB0-hEeRdqMlqNnuupA8wklaq7GW3MWA=.c4884409-8cf2-405f-97df-131de7b8b317@github.com>

On Fri, 30 May 2025 00:17:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review: strip othervm mode + cleanup

Cleanup looks good.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2879883888

From jlu at openjdk.org  Fri May 30 00:20:27 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 00:20:27 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR
In-Reply-To: <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <H833y1iYUJmwjy2iCAya5NJ_PeA7HQ0AoWVjWCP8Qx0=.69d825a3-6926-458d-9c94-96291d8fa7d4@github.com>
Message-ID: <uZE39hZcCwJPaopzUj6jTkVoYPnNdxLCo695xNUpYoQ=.d30f39cf-7eb9-479a-a9d5-81d3c824addc@github.com>

On Thu, 29 May 2025 22:47:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Probably we can remove `/othervm` from those `@run` directives?

@naotoj Right, no more reason to run these tests in a separate JVM. Fixed in [2eb1edd](https://github.com/openjdk/jdk/pull/25532/commits/2eb1edd560b51d7fae92f5f859629d7fb5b5df23); that commit also includes some other minor cleanup.

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

PR Comment: https://git.openjdk.org/jdk/pull/25532#issuecomment-2920863235

From dnguyen at openjdk.org  Fri May 30 00:42:50 2025
From: dnguyen at openjdk.org (Damon Nguyen)
Date: Fri, 30 May 2025 00:42:50 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <GxHA201G-kbm38cbr9ykIDyEpvMpTEkXZGp6F08ip74=.25f6b111-fe0e-46c4-b715-bbfdde9ff38a@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

LGTM. Ran a test job myself and everything looks good.

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

Marked as reviewed by dnguyen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2879913986

From naoto at openjdk.org  Fri May 30 00:43:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 00:43:52 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v2]
In-Reply-To: <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
Message-ID: <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>

On Fri, 30 May 2025 00:20:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review: strip othervm mode + cleanup

test/jdk/java/util/TimeZone/Bug8167143.java line 102:

> 100:             case "testCompat":
> 101:                 testImplicitCompatLocales();
> 102:                 break;

The method name is deceiving, but the test still has value because it tests the internal `FALLBACK` provider. In fact, functions for `BreakIterator` and `Collator` should be fully functional from that provider, as `CLDR` provider does not provide those. Maybe renaming `Compat` to `Fallback` would be appropriate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25532#discussion_r2114948613

From tr at openjdk.org  Fri May 30 09:45:52 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 09:45:52 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <qaUTWc7UC985atmIfiHl4nX6uFZBIimKvOfpsjidtnc=.28046a83-2ea1-4942-a860-0b7b39829320@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 169:

> 167:         AWTEventListener[] array = tk.getAWTEventListeners();
> 168:         if (array == null || array.length != expected) {
> 169:             System.out.println("[Simple test failed!!]");

I don't think this print statement is required?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115522289

From tr at openjdk.org  Fri May 30 09:55:54 2025
From: tr at openjdk.org (Tejesh R)
Date: Fri, 30 May 2025 09:55:54 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 24:

> 22:  */
> 23: 
> 24: /*

Suggestion:

/*
 * @test
 * @bug 4290704 8357598
 * @summary Test use of AWTEventListenerProxyTest class
 */


Most of the test follow this pattern for jtreg tags. It would be good if you use it too for code consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115549915

From aivanov at openjdk.org  Fri May 30 10:52:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 May 2025 10:52:53 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
Message-ID: <MH3MYvzzowTGAKd8ppJgG9jFH0-sloz8my7lDVTxbsI=.983dc5b5-031d-4472-bda8-0669789bc230@github.com>

On Tue, 27 May 2025 17:38:32 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

>> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
>> 
>> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
>> 
>> One of the test is updated just to touch that codepath.
>
> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25401#pullrequestreview-2880953280

From aivanov at openjdk.org  Fri May 30 10:52:55 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 30 May 2025 10:52:55 GMT
Subject: <i18n dev> RFR: 8357598: Toolkit.removeAWTEventListener should
 handle null listener in AWTEventListenerProxy [v2]
In-Reply-To: <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
 <-z-iY3P6QORAHKgWiQJRAVGxrxf46AOPlLYcQi_liOg=.55c0e62b-239f-4d23-92ac-6b53c3e8e1f7@github.com>
 <5esyds_XiOkkKu-Az09lY9sXEBJ-v-2U-7M0xFbYIS8=.b3713dbe-4844-49dc-8c89-2057cb2d447b@github.com>
Message-ID: <HGqaE1hT-w_Tsp-KI3Q-Cd06-94CtnQVToYQzYGe4As=.c5208fc5-9a8a-4016-a181-5853a6da3e4d@github.com>

On Fri, 30 May 2025 09:52:21 GMT, Tejesh R <tr at openjdk.org> wrote:

>> Sergey Bylokhov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 24:
> 
>> 22:  */
>> 23: 
>> 24: /*
> 
> Suggestion:
> 
> /*
>  * @test
>  * @bug 4290704 8357598
>  * @summary Test use of AWTEventListenerProxyTest class
>  */
> 
> 
> Most of the test follow this pattern for jtreg tags. It would be good if you use it too for code consistency.

Not required, but can be updated?

> test/jdk/java/awt/Toolkit/AWTEventListenerProxyTest/AWTEventListenerProxyTest.java line 169:
> 
>> 167:         AWTEventListener[] array = tk.getAWTEventListeners();
>> 168:         if (array == null || array.length != expected) {
>> 169:             System.out.println("[Simple test failed!!]");
> 
> I don't think this print statement is required?

Probably not, but it follows the common pattern in the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115659639
PR Review Comment: https://git.openjdk.org/jdk/pull/25401#discussion_r2115660853

From jlu at openjdk.org  Fri May 30 17:02:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:02:12 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v3]
In-Reply-To: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
Message-ID: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>

> Please review this PR which cleans up some i18n tests.
> 
> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
> 
> As this change is trivial cleanup, bug IDs are not updated in this change.

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

  re-add testCompat to Bug8167143.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/25532/files
  - new: https://git.openjdk.org/jdk/pull/25532/files/2eb1edd5..d8da7744

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

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

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

From jlu at openjdk.org  Fri May 30 17:02:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:02:12 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v3]
In-Reply-To: <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <7iPhlactV6aDx8v6qI2AckiFZ-Iy2xae2_LkqUo_xWA=.b2d2c937-e78d-433e-99fb-c0c9817c47f9@github.com>
 <Sz9onzoO82lM0V_GtJlZX5J9301FawxSP_EzKg_MOTA=.d76c3339-c504-4c08-875a-7f55db86ff1c@github.com>
Message-ID: <IkJAmSbqaUBaBs-Y3a2kp8EQNShZSzeVruZshs-fMTI=.a1a17e8d-5f8d-4f3e-b584-780acd055ba0@github.com>

On Fri, 30 May 2025 00:41:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   re-add testCompat to Bug8167143.java
>
> test/jdk/java/util/TimeZone/Bug8167143.java line 102:
> 
>> 100:             case "testCompat":
>> 101:                 testImplicitCompatLocales();
>> 102:                 break;
> 
> The method name is deceiving, but the test still has value because it tests the internal `FALLBACK` provider. In fact, functions for `BreakIterator` and `Collator` should be fully functional from that provider, as `CLDR` provider does not provide those. Maybe renaming `Compat` to `Fallback` would be appropriate.

The run invocation for `testCompat` was removed from the Jtreg header in [JDK-8174269](https://bugs.openjdk.org/browse/JDK-8174269). So since then, that test was not run, which was why I removed it. I tried re-adding this test as part of the run directives, and it fails. (I presume that's why it was removed after COMPAT removal.)

It is testing the JRE provider, we can repurpose the test to check the FALLBACK provider, but we would only expect the implicit locales for BreakIteratorProvider and CollatorProvider (as you said). I filed [JDK-8358170](https://bugs.openjdk.org/browse/JDK-8358170) because I think this change would be out of scope for this issue. I simply reverted the removal in the https://github.com/openjdk/jdk/pull/25532/commits/d8da77440d6ed63dee6444dda549279cc15ae918.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25532#discussion_r2116268074

From jlu at openjdk.org  Fri May 30 17:15:55 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 30 May 2025 17:15:55 GMT
Subject: <i18n dev> Integrated: 8358089: Remove the GenerateKeyList.java
 test tool
In-Reply-To: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
References: <FHqDrBv0LPDDAtIbhtieILpmn2aVEfq8XtJ5Afnbc6s=.13cbef12-e19c-4ea5-8254-dbc9f4a56b97@github.com>
Message-ID: <vzxvhxByNasEYCn-Wh94USAwKo_ZIe8us-JnNtTRIFw=.cc6e7218-e906-4b0b-a667-c5fd23fe9bc1@github.com>

On Thu, 29 May 2025 19:01:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the test tool `GenerateKeyList.java` after the COMPAT locale data removal.
> 
> `LocaleDataTest.java` may optionally use the `GenerateKeyList.java` tool. However, this tool is manually used and was primarily used for COMPAT data. There is no longer any point to keep it, and it can always be retrieved via the VCS if needed.

This pull request has now been integrated.

Changeset: 81464cd1
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81464cd1141ebdf0cdde22e7388b97224d810f4a
Stats:     90 lines in 1 file changed: 0 ins; 90 del; 0 mod

8358089: Remove the GenerateKeyList.java test tool

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Fri May 30 17:25:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:25:57 GMT
Subject: <i18n dev> RFR: 8357886: Remove TimeZoneNames_* of the COMPAT
 locale data provider
In-Reply-To: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
References: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
Message-ID: <Ol0urXbb3FvKWoYFWNBQ6D2qpSvc_SXisE8Q69oCpQ4=.562ff192-a15b-4bad-a2dc-6e940a039a23@github.com>

On Thu, 29 May 2025 16:54:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> These resource files are remnants from the removal of the COMPAT locale provider. Since the COMPAT provider has been removed, these localizations should also be cleaned up.

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25523#issuecomment-2922944850

From naoto at openjdk.org  Fri May 30 17:25:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:25:57 GMT
Subject: <i18n dev> Integrated: 8357886: Remove TimeZoneNames_* of the
 COMPAT locale data provider
In-Reply-To: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
References: <3vTbzX5gIRAQ68OOoqMuIZj3rd-4tMZ3S_cd7AevL5Q=.c677d53c-4047-4075-af1f-83f8dfeb97da@github.com>
Message-ID: <xOjDB7nmXivBNyaivsRfFqfshkoMzS3uXpXZzdFwjsQ=.230cca02-a07a-42f1-97a3-16c26d45925b@github.com>

On Thu, 29 May 2025 16:54:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> These resource files are remnants from the removal of the COMPAT locale provider. Since the COMPAT provider has been removed, these localizations should also be cleaned up.

This pull request has now been integrated.

Changeset: eaf7815e
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/eaf7815ea6854de603a1b5c179799a9ef5d37f42
Stats:     10729 lines in 15 files changed: 0 ins; 10729 del; 0 mod

8357886: Remove TimeZoneNames_* of the COMPAT locale data provider

Reviewed-by: joehw, jlu

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

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

From naoto at openjdk.org  Fri May 30 17:26:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:26:57 GMT
Subject: <i18n dev> RFR: 8357882: Use UTF-8 encoded data in
 LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <-bMo8IZCQV09yozAd6myBZFxrv7Ccov5peGrg2wFNcM=.5a0a63ce-1fe7-4986-b991-3d146c98e319@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/25524#issuecomment-2922945653

From naoto at openjdk.org  Fri May 30 17:26:57 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:26:57 GMT
Subject: <i18n dev> Integrated: 8357882: Use UTF-8 encoded data in
 LocaleDataTest
In-Reply-To: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
References: <breAKc-4kVIzqP0Wqot44_Zqu9YXAfl7BP0bdAqInr0=.42b9f8b6-83a2-4a6f-a60d-d525004cd6f7@github.com>
Message-ID: <_Eu-yQoXURBs4_MKCMyp6uQ10vGZ1jHoBk2Nfn3A000=.af1bf3e9-b25b-489a-b2ed-ce6ac3e8c46b@github.com>

On Thu, 29 May 2025 17:20:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Test refactoring stemmed from the discussion at https://git.openjdk.org/jdk/pull/25228#discussion_r2106755160. The test is now based on UTF-8 instead of ISO-8859-1

This pull request has now been integrated.

Changeset: 4fa4f151
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fa4f15122213afea5cb25166c3b36a1c395b06c
Stats:     4205 lines in 2 files changed: 0 ins; 101 del; 4104 mod

8357882: Use UTF-8 encoded data in LocaleDataTest

Reviewed-by: jlu, joehw

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

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

From naoto at openjdk.org  Fri May 30 17:41:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 30 May 2025 17:41:52 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <CdZ_XhCpu2KbDxdYArjtxVQWDk3X2lfb2A8HvDAntBA=.eb4dfece-f90f-47a2-9bd5-a620a026e7bc@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

LGTM. Thanks for taking care of the testCompat with another issue.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2882000850

From bpb at openjdk.org  Fri May 30 18:01:52 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 30 May 2025 18:01:52 GMT
Subject: <i18n dev> RFR: 8358095: Cleanup tests with explicit locale
 provider set to only CLDR [v3]
In-Reply-To: <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
References: <8IpYzTaCEccZdcnLUG_cjIOqococwqqSV_i8edrbZjY=.8cb08fba-21e5-49bb-a79c-9029a9b8325f@github.com>
 <5cqPWaioFUDsw2wn7U5eCC-YlWAoVx0R7zhSJHzNETY=.8b6e93da-1b95-402c-84dc-c5ba15269160@github.com>
Message-ID: <W44J_ijq5-l-iwIYPgbU1d-vSowvt10Klj_jMU5H89Q=.031ddf6c-86ee-4851-a269-cdef68c8f508@github.com>

On Fri, 30 May 2025 17:02:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which cleans up some i18n tests.
>> 
>> There are some i18n related tests that set the locale provider to CLDR (and only CLDR). Since JDK9, this is redundant and equivalent to the default. Thus, occurrences of "-Djava.locale.providers=CLDR" are just extra noise for these tests. 
>> 
>> As this change is trivial cleanup, bug IDs are not updated in this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   re-add testCompat to Bug8167143.java

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25532#pullrequestreview-2882040739

From serb at openjdk.org  Sat May 31 07:09:03 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 31 May 2025 07:09:03 GMT
Subject: <i18n dev> Integrated: 8357598: Toolkit.removeAWTEventListener
 should handle null listener in AWTEventListenerProxy
In-Reply-To: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
References: <mFvYHbgAhMQU4OfBjS8q3evyqa4uUK8epLx7XR9XBEY=.796c8ade-bc71-416b-94e4-a840e75083ca@github.com>
Message-ID: <P1T325_3_07C_FmtKH2sRkMoft2zKw7Gho7827hhpsA=.163ad63b-230c-4720-b2bb-d1338a4c3828@github.com>

On Thu, 22 May 2025 21:21:30 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The issue was found here: https://github.com/openjdk/jdk/pull/24692#discussion_r2089545502
> 
> AWTEventListener and AWTEventListenerProxy are public classes and there's no assertion that EventListenerProxy.getListener() will always return a non-null value. So removeAWTEventListener method should fetch the listener from the proxy and check it for null similar to how it is implemented in addAWTEventListener. Currently, it works fine because we never insert null values into the map. So it is just a code clarification.
> 
> One of the test is updated just to touch that codepath.

This pull request has now been integrated.

Changeset: 3a3ea7e1
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3a3ea7e17fff100e368c956350bb9aaa2261b8a9
Stats:     48 lines in 2 files changed: 28 ins; 15 del; 5 mod

8357598: Toolkit.removeAWTEventListener should handle null listener in AWTEventListenerProxy

Reviewed-by: aivanov, dnguyen

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

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