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