From swen at openjdk.org  Mon Dec  1 00:17:11 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 1 Dec 2025 00:17:11 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v3]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <NsXDN8te7y_wnfYcO4jemeXrpirvTe60IKuaRj2ypU8=.1854432c-5940-40a2-80ca-3b35538f33ed@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/7137d9ec..9a0ad61a

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

  Stats: 49 lines in 2 files changed: 20 ins; 18 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/28471.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471

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

From swen at openjdk.org  Mon Dec  1 02:33:33 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 1 Dec 2025 02:33:33 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  bug fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/9a0ad61a..073e2b8d

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

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

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

From rriggs at openjdk.org  Mon Dec  1 14:15:00 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Dec 2025 14:15:00 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
Message-ID: <KRRKO31fCmUm8klGLmNPJ_z1Tgw24KO7V0TKWv8iJF4=.d00ff5c4-ee40-4c93-8eb1-ca107e9ac0b6@github.com>

On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

Spreading out and duplicating the state across multiple classes isn't very satisfactory.
Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed.
Always create the initial EnumMap and refactor the `fieldValues.put()` calls to a private utility method to catch the ClassCatchException and upgrade the map to a HashMap.
That should retain the performance improvements without any extra overhead or non-local code changes for all of the normal cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3596762057

From naoto at openjdk.org  Mon Dec  1 17:24:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Dec 2025 17:24:34 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <KRRKO31fCmUm8klGLmNPJ_z1Tgw24KO7V0TKWv8iJF4=.d00ff5c4-ee40-4c93-8eb1-ca107e9ac0b6@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
 <KRRKO31fCmUm8klGLmNPJ_z1Tgw24KO7V0TKWv8iJF4=.d00ff5c4-ee40-4c93-8eb1-ca107e9ac0b6@github.com>
Message-ID: <3QD5vRu2p1ZGb8VZtCa8RBVe1EWFLI3m77eV71g4fNY=.33964df0-b049-452b-95f5-e6e3d4439ef5@github.com>

On Mon, 1 Dec 2025 14:12:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed.

+1. Never seen non-ChronoField in the wild

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

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3597853861

From jlu at openjdk.org  Mon Dec  1 18:20:13 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 Dec 2025 18:20:13 GMT
Subject: <i18n dev> RFR: 8372609: Bug4944439 does not enforce locale
 correctly
In-Reply-To: <yyONkLjis2_LeLcXF7OgwPjhJV4gdo46lWsySE76qGQ=.cbf5aff4-1a6c-440a-9584-6f0b44c1c67d@github.com>
References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
 <yyONkLjis2_LeLcXF7OgwPjhJV4gdo46lWsySE76qGQ=.cbf5aff4-1a6c-440a-9584-6f0b44c1c67d@github.com>
Message-ID: <-T8j-eEfRF-m62nZvr_cEgyBElcrxAypGREhVu_zHcY=.f3ff8846-8b68-4891-970f-dbefaf570753@github.com>

On Thu, 27 Nov 2025 02:04:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.
>> 
>> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.
>> 
>> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).
>
> Hello Justin, the change looks reasonable to me. I'm guessing the call to `NumberFormat.getInstance(...)` would still return and exercise a `DecimalFormat` instance, and thus the original intent of the test for JDK-4944439 would be preserved?

@jaikiran Yes, `NumberFormat.getInstance` returns a plain `DecimalFormat` instance, so the original intent should remain the same.

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

PR Comment: https://git.openjdk.org/jdk/pull/28514#issuecomment-3598140797

From jlu at openjdk.org  Mon Dec  1 18:20:14 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 Dec 2025 18:20:14 GMT
Subject: <i18n dev> RFR: 8372609: Bug4944439 does not enforce locale
 correctly
In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
Message-ID: <1j3MHRwT8pnGGEaJ-AwqVpwnjGYiIn6HZNYr8eNXmzw=.01884aac-c0eb-4f57-810e-db181d11c03a@github.com>

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.
> 
> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.
> 
> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28514#issuecomment-3598141354

From jlu at openjdk.org  Mon Dec  1 18:20:15 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 Dec 2025 18:20:15 GMT
Subject: <i18n dev> Integrated: 8372609: Bug4944439 does not enforce locale
 correctly
In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>
Message-ID: <S5AA6l84-nFJFIu8B57jnQgO3Nvmp_CFFS-Pbz1SsRo=.0aef7e6f-98cf-4505-b84c-6499a35c3199@github.com>

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one.
> 
> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method.
> 
> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer).

This pull request has now been integrated.

Changeset: 45c0600d
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/45c0600d3abfa4bcd0338840523c0df69283afe2
Stats:     21 lines in 1 file changed: 0 ins; 17 del; 4 mod

8372609: Bug4944439 does not enforce locale correctly

Reviewed-by: liach, jpai

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

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

From naoto at openjdk.org  Mon Dec  1 23:09:54 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Dec 2025 23:09:54 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
Message-ID: <gF8bhKQ6s0a0h6u81c42vGqPsK2wLsa-d4vr6cYkZow=.9f836d93-c8e5-4425-be6f-95c26fc73766@github.com>

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor doc formatting update

make/jdk/src/classes/build/tools/generatecharacter/GenerateCaseFolding.java line 79:

> 77:         // hack, hack, hack! the logic does not pick 0131. just add manually to support 'I's.
> 78:         // 0049; T; 0131; # LATIN CAPITAL LETTER I
> 79:         final String T_0x0131_0x49 = String.format("        entry(0x%04x, 0x%04x),\n", 0x0131, 0x49);

The 'T' status reads (in CaseFolding.txt):

# T: special case for uppercase I and dotted uppercase I
#    - For non-Turkic languages, this mapping is normally not used.
#    - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters.
#      Note that the Turkic mappings do not maintain canonical equivalence without additional processing.

Since this casefold feature is locale independent, should this `T` status be ignored? It might be helpful if we mention in the spec if we do this `T` case folding.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2579019726

From naoto at openjdk.org  Mon Dec  1 23:47:49 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Dec 2025 23:47:49 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
Message-ID: <fQ26frbGl40Zzkut_4cp5RM1QArvKB9bj6Su3LnUsEg=.ee278244-180b-45e1-863f-d93744ee0f8a@github.com>

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor doc formatting update

src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69:

> 67:     *  | 1:2 mapping |  0002  |   0000  |  xxxx  |  xxxx  |  FB02 => 0066 006C
> 68:     *  +---+---------+--------+---------+--------+--------+
> 69:     *  | 1:3 mapping |  0003  |   xxxx  |  xxxx  |  xxxx  |  FB03 => 0066 0066 0069

What if 1:2/3 mappings included non-BMP case folded forms?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2579098131

From jlu at openjdk.org  Mon Dec  1 23:57:01 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 Dec 2025 23:57:01 GMT
Subject: <i18n dev> RFR: 8372844: Improve usage of
 test/jdk/java/text/testlib/TestUtils.java locale methods
Message-ID: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>

This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test.

The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g.

> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0]

As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.)

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/28590/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28590&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372844
  Stats: 223 lines in 12 files changed: 45 ins; 90 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/28590.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28590/head:pull/28590

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

From swen at openjdk.org  Tue Dec  2 01:53:46 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 2 Dec 2025 01:53:46 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <KRRKO31fCmUm8klGLmNPJ_z1Tgw24KO7V0TKWv8iJF4=.d00ff5c4-ee40-4c93-8eb1-ca107e9ac0b6@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
 <KRRKO31fCmUm8klGLmNPJ_z1Tgw24KO7V0TKWv8iJF4=.d00ff5c4-ee40-4c93-8eb1-ca107e9ac0b6@github.com>
Message-ID: <IzDxG8pSzB7M2zGVCAnaty8wi33yZolMuMzJKO5YJrQ=.a7bf11ea-daaa-448b-a45b-1f7e1c360842@github.com>

On Mon, 1 Dec 2025 14:12:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Spreading out and duplicating the state across multiple classes isn't very satisfactory. Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed. Always create the initial EnumMap and refactor the `fieldValues.put()` calls to a private utility method to catch the ClassCatchException and upgrade the map to a HashMap. That should retain the performance improvements without any extra overhead or non-local code changes for all of the normal cases.

I also plan to upgrade EnumMap to a custom ChronoFieldMap, like this: https://github.com/wenshao/jdk/commit/b1cbc6295aa339a666996e910f46ab351e44726a Keeping the current implementation would be easier.

<img width="2666" height="548" alt="image" src="https://github.com/user-attachments/assets/30ede42c-1df7-4599-8541-5a1d3ce03f73" />

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

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3599787338

From swen at openjdk.org  Tue Dec  2 02:19:51 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 2 Dec 2025 02:19:51 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
Message-ID: <-LT8YIM5AXrKFxx0ZdIwmZFdS4Sx3SsJ5ooYsUJctT8=.4fcf6ddb-e4dc-473a-a730-c0b16369b09c@github.com>

On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

We should place more processing logic in the pattern parsing stage, rather than the text parsing stage.

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

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3599870510

From sherman at openjdk.org  Tue Dec  2 18:05:52 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 2 Dec 2025 18:05:52 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <gF8bhKQ6s0a0h6u81c42vGqPsK2wLsa-d4vr6cYkZow=.9f836d93-c8e5-4425-be6f-95c26fc73766@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
 <gF8bhKQ6s0a0h6u81c42vGqPsK2wLsa-d4vr6cYkZow=.9f836d93-c8e5-4425-be6f-95c26fc73766@github.com>
Message-ID: <VmX656wkYu_zWm4AslhmT8KAoizsew52D85M-t1Qw2k=.e23d6981-4850-4562-9c3e-34595d587033@github.com>

On Mon, 1 Dec 2025 23:03:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor doc formatting update
>
> make/jdk/src/classes/build/tools/generatecharacter/GenerateCaseFolding.java line 79:
> 
>> 77:         // hack, hack, hack! the logic does not pick 0131. just add manually to support 'I's.
>> 78:         // 0049; T; 0131; # LATIN CAPITAL LETTER I
>> 79:         final String T_0x0131_0x49 = String.format("        entry(0x%04x, 0x%04x),\n", 0x0131, 0x49);
> 
> The 'T' status reads (in CaseFolding.txt):
> 
> # T: special case for uppercase I and dotted uppercase I
> #    - For non-Turkic languages, this mapping is normally not used.
> #    - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters.
> #      Note that the Turkic mappings do not maintain canonical equivalence without additional processing.
> 
> Since this casefold feature is locale independent, should this `T` status be ignored? It might be helpful if we mention in the spec if we do this `T` case folding.

T_0x0131_0x49 is for the table Expanded_Case_Map_Entries, which is used for the regex only.  See: https://openjdk.github.io/cr/?repo=jdk&pr=26285&range=05#new-1-make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java
The casefolding mapping for regex uses CTS,  to match the existing behavior.  We may want to do something later to "consolidate" the spec and implementation ,  but it's not within the scope of this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582279595

From jlu at openjdk.org  Tue Dec  2 18:25:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 Dec 2025 18:25:09 GMT
Subject: <i18n dev> RFR: 8362428: Update IANA Language Subtag Registry to
 Version 2025-08-25
Message-ID: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>

Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

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

Commit messages:
 - init

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

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

From lancea at openjdk.org  Tue Dec  2 18:33:58 2025
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Dec 2025 18:33:58 GMT
Subject: <i18n dev> RFR: 8362428: Update IANA Language Subtag Registry
 to Version 2025-08-25
In-Reply-To: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
References: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
Message-ID: <7cE1BZn58zX8WuRsqseB_9lV6_sfS2Ag1hjiZM2a2cA=.3aa0204a-3e20-427b-a487-e6eab77951bb@github.com>

On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

Changes look reasonable

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3531593095

From sherman at openjdk.org  Tue Dec  2 18:38:29 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 2 Dec 2025 18:38:29 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <fQ26frbGl40Zzkut_4cp5RM1QArvKB9bj6Su3LnUsEg=.ee278244-180b-45e1-863f-d93744ee0f8a@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
 <fQ26frbGl40Zzkut_4cp5RM1QArvKB9bj6Su3LnUsEg=.ee278244-180b-45e1-863f-d93744ee0f8a@github.com>
Message-ID: <yZmjYzcgKE6mdqw4R9oXb5yzxnXY3KaNLj7yDMchkKI=.887ff69d-0c16-487d-be28-c65da8466313@github.com>

On Mon, 1 Dec 2025 23:44:52 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   minor doc formatting update
>
> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69:
> 
>> 67:     *  | 1:2 mapping |  0002  |   0000  |  xxxx  |  xxxx  |  FB02 => 0066 006C
>> 68:     *  +---+---------+--------+---------+--------+--------+
>> 69:     *  | 1:3 mapping |  0003  |   xxxx  |  xxxx  |  xxxx  |  FB03 => 0066 0066 0069
> 
> What if 1:2/3 mappings included non-BMP case folded forms?

1:2 should be fine, we still have enough bits available. 1:3 will be more challenging,  but in theory 21-bit x 3 = 63. we still have the msb to indicate it's 3 non-bmp.  That said, I assume we might simply fallback to the char/int[] mode when the 'flag' byte indicates 0004 for 1:2 non-bmp or 0006 for 1:3 non-bmp, for example.  I don't think we need to worry much about the performance for those 'special' cases, if the standard does add such mappings.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582390889

From naoto at openjdk.org  Tue Dec  2 18:44:31 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Dec 2025 18:44:31 GMT
Subject: <i18n dev> RFR: 8362428: Update IANA Language Subtag Registry
 to Version 2025-08-25
In-Reply-To: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
References: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
Message-ID: <S1wyElpus6x__GvERT1loPlOE5sRtXfBH3U-LHwqAxM=.37900b54-4161-45a8-be0a-80a7856a43b0@github.com>

On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3531645229

From naoto at openjdk.org  Tue Dec  2 18:49:42 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Dec 2025 18:49:42 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
Message-ID: <IIUojV6eJxUcManCmZX3qcMj_6vUHrdlkeW0_ci3k-4=.8b6a4b34-e260-414a-b2ed-068e883c16b7@github.com>

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> ### Summary
>> 
>> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
>> 
>> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
>> 
>> **String.equalsIgnoreCase(String)**
>> 
>> - Unicode-aware, locale-independent.
>> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
>> - Limited: does not support 1:M mapping defined in Unicode case folding.
>> 
>> **Character.toLowerCase(int) / Character.toUpperCase(int)**
>> 
>> - Locale-independent, single code point only.
>> - No support for 1:M mappings.
>> 
>> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
>> 
>> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
>> - Intended primarily for presentation/display, not structural case-insensitive matching.
>> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
>> 
>> **1:M mapping example, U+00DF (?)**
>> 
>> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
>> - Case folding produces "ss", matching Unicode caseless comparison rules.
>> 
>> 
>> jshell> "\u00df".equalsIgnoreCase("ss")
>> $22 ==> false
>> 
>> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
>> $24 ==> true
>> 
>> 
>> ### Motivation & Direction
>> 
>> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
>> 
>> - Unicode-compliant **full** case folding.
>> - Simpler, stable and more efficient case-less matching without workarounds.
>> - Brings Java's string comparison handling in line with other programming languages/libraries.
>> 
>> This PR proposes to introduce the following comparison methods in `String` class
>> 
>> - boolean equalsFoldCase(String anotherString)
>> - int compareToFoldCase(String anotherString)
>> - Comparator<String> UNICODE_CASEFOLD_ORDER
>> 
>> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
>> 
>> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
>> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass...
>
> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   minor doc formatting update

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3531664719

From naoto at openjdk.org  Tue Dec  2 18:49:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Dec 2025 18:49:44 GMT
Subject: <i18n dev> RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <yZmjYzcgKE6mdqw4R9oXb5yzxnXY3KaNLj7yDMchkKI=.887ff69d-0c16-487d-be28-c65da8466313@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
 <W0BdPW0of0FWyQXKZiRZrPO3p56piFtG1T8r7MxL-rA=.a574daa9-4b2d-4b32-bc4b-53e89a74da73@github.com>
 <fQ26frbGl40Zzkut_4cp5RM1QArvKB9bj6Su3LnUsEg=.ee278244-180b-45e1-863f-d93744ee0f8a@github.com>
 <yZmjYzcgKE6mdqw4R9oXb5yzxnXY3KaNLj7yDMchkKI=.887ff69d-0c16-487d-be28-c65da8466313@github.com>
Message-ID: <eecD1xAX_-yw-fSmXBFYyGkUMwirLhmxpFS8cNWhE40=.d4e36228-807b-4842-9889-db90fc7866e9@github.com>

On Tue, 2 Dec 2025 18:35:40 GMT, Xueming Shen <sherman at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69:
>> 
>>> 67:     *  | 1:2 mapping |  0002  |   0000  |  xxxx  |  xxxx  |  FB02 => 0066 006C
>>> 68:     *  +---+---------+--------+---------+--------+--------+
>>> 69:     *  | 1:3 mapping |  0003  |   xxxx  |  xxxx  |  xxxx  |  FB03 => 0066 0066 0069
>> 
>> What if 1:2/3 mappings included non-BMP case folded forms?
>
> 1:2 should be fine, we still have enough bits available. 1:3 will be more challenging,  but in theory 21-bit x 3 = 63. we still have the msb to indicate it's 3 non-bmp.  That said, I assume we might simply fallback to the char/int[] mode when the 'flag' byte indicates 0004 for 1:2 non-bmp or 0006 for 1:3 non-bmp, for example.  I don't think we need to worry much about the performance for those 'special' cases, if the standard does add such mappings.

Yeah, it is non-existent as of now, so the performance would not be an issue even if those cases were introduced in the future.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582428584

From naoto at openjdk.org  Tue Dec  2 18:55:45 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Dec 2025 18:55:45 GMT
Subject: <i18n dev> RFR: 8372844: Improve usage of
 test/jdk/java/text/testlib/TestUtils.java locale methods
In-Reply-To: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
References: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
Message-ID: <sDnev0J0luFXOhkJ0tTQ-IzHQDY0uJkuLzDy4j3xd1w=.55f49a0a-c8fc-4708-89e3-de23802076dd@github.com>

On Mon, 1 Dec 2025 23:51:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test.
> 
> The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g.
> 
>> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0]
> 
> As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.)

Looks good. A couple of comments follow

test/jdk/java/text/Format/DateFormat/Bug4845901.java line 31:

> 29:  * time.
> 30:  * @library /java/text/testlib
> 31:  * @run junit Bug4845901

Specifying `othervm` is safer, as the test sets the default time zone

test/jdk/java/text/Format/DateFormat/Bug6530336.java line 88:

> 86:                     date.contains("\u07dc\u07ed\u07d5\u07d6") || // N?Ko
> 87:                     date.contains("\ua2e7\ua0c5\ua395\ua3e6\ua12e\ua209") || // Sichuan Yi, Nuosu
> 88:                     date.contains("\u06af\u0631\u06cc\u0646\u06cc\u0686")) { // Central Kurdish

Could use non-escaped strings

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

PR Review: https://git.openjdk.org/jdk/pull/28590#pullrequestreview-3531463420
PR Review Comment: https://git.openjdk.org/jdk/pull/28590#discussion_r2582270468
PR Review Comment: https://git.openjdk.org/jdk/pull/28590#discussion_r2582443358

From jlu at openjdk.org  Tue Dec  2 19:14:02 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 Dec 2025 19:14:02 GMT
Subject: <i18n dev> RFR: 8372844: Improve usage of
 test/jdk/java/text/testlib/TestUtils.java locale methods [v2]
In-Reply-To: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
References: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
Message-ID: <BqyL2kE0IxZLZ4QMSWed-bGCFgtZIf_v-nMj6uo7U3Y=.85391153-986d-4541-b7c1-fd23bce280a8@github.com>

> This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test.
> 
> The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g.
> 
>> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0]
> 
> As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.)

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

  Reflect Naoto's comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28590/files
  - new: https://git.openjdk.org/jdk/pull/28590/files/6de6b7fa..ed9f1ba7

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

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

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

From sherman at openjdk.org  Tue Dec  2 19:50:49 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 2 Dec 2025 19:50:49 GMT
Subject: <i18n dev> Integrated: 8365675: Add String Unicode Case-Folding
 Support
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: <fnT6GL2saF8TJmDkljbcDSITSvPPaqVoQOURXrhLNJI=.0d4975c1-838b-426d-bac7-15f1d75fc4f1@github.com>

On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> ### Summary
> 
> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.
> 
> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:
> 
> **String.equalsIgnoreCase(String)**
> 
> - Unicode-aware, locale-independent.
> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
> - Limited: does not support 1:M mapping defined in Unicode case folding.
> 
> **Character.toLowerCase(int) / Character.toUpperCase(int)**
> 
> - Locale-independent, single code point only.
> - No support for 1:M mappings.
> 
> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**
> 
> - Based on Unicode SpecialCasing.txt, supports 1:M mappings.
> - Intended primarily for presentation/display, not structural case-insensitive matching.
> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching.
> 
> **1:M mapping example, U+00DF (?)**
> 
> - String.toUpperCase(Locale.ROOT, "?") ? "SS"
> - Case folding produces "ss", matching Unicode caseless comparison rules.
> 
> 
> jshell> "\u00df".equalsIgnoreCase("ss")
> $22 ==> false
> 
> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
> $24 ==> true
> 
> 
> ### Motivation & Direction
> 
> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.
> 
> - Unicode-compliant **full** case folding.
> - Simpler, stable and more efficient case-less matching without workarounds.
> - Brings Java's string comparison handling in line with other programming languages/libraries.
> 
> This PR proposes to introduce the following comparison methods in `String` class
> 
> - boolean equalsFoldCase(String anotherString)
> - int compareToFoldCase(String anotherString)
> - Comparator<String> UNICODE_CASEFOLD_ORDER
> 
> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.
> 
> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.
> 
> ### The New API
> 
> See CSR https://bugs.openjd...

This pull request has now been integrated.

Changeset: b97ed667
Author:    Xueming Shen <sherman at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b97ed667db0bd527461b2b385af3001f53d71c19
Stats:     1452 lines in 13 files changed: 1240 ins; 207 del; 5 mod

8365675: Add String Unicode Case-Folding Support

Reviewed-by: rriggs, naoto, ihse

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

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

From iris at openjdk.org  Tue Dec  2 21:23:57 2025
From: iris at openjdk.org (Iris Clark)
Date: Tue, 2 Dec 2025 21:23:57 GMT
Subject: <i18n dev> RFR: 8362428: Update IANA Language Subtag Registry
 to Version 2025-08-25
In-Reply-To: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
References: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
Message-ID: <lDIOjcrGmyINg5V2b0yihyQtJ2DxAWpfXF1H3WRWeEI=.a8edd859-b298-4531-b753-b67f7456ed7d@github.com>

On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3532155522

From liach at openjdk.org  Wed Dec  3 00:21:21 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 3 Dec 2025 00:21:21 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v4]
In-Reply-To: <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <R9i5wuw8sHNVSMElwTBiloWLa2i17Lz0Ex8GT1HVwgA=.229859ef-5f1f-4aff-a911-bb46e65b3bc2@github.com>
Message-ID: <-t_SUbWpXqrXN4PhmG16FJrYc3s5hyMckypBpiClOew=.098c95ff-e17d-4e8a-b94d-f3f791b10f39@github.com>

On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   bug fix

I think from your experiments, maintaining onlyChronoField is indeed way too painful. So I support updating the map in Parsed to use a custom implemented map. This should be not as risky as that map is never exposed to the public users.

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1825:

> 1823:             return this;
> 1824:         }
> 1825:         return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, fields, chrono, zone, onlyChronoField);

Same check comment

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1874:

> 1872:             resolverFields = Collections.unmodifiableSet(new HashSet<>(resolverFields));
> 1873:         }
> 1874:         return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, resolverFields, chrono, zone, onlyChronoField);

Need to check if `resolverFields` has non-ChronoField

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3532627956
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2583190506
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2583190245

From swen at openjdk.org  Wed Dec  3 01:44:42 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 3 Dec 2025 01:44:42 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v5]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <hg-oKYYR8b4VHXrQWCF8kbU-zF9mJL3wCvCyaWg7kiQ=.acc4656f-0b40-4d3b-b5d0-652d9063e0e0@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  resolverFields, from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/073e2b8d..b2b19e13

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

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

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

From naoto at openjdk.org  Wed Dec  3 17:07:22 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Dec 2025 17:07:22 GMT
Subject: <i18n dev> RFR: 8372844: Improve usage of
 test/jdk/java/text/testlib/TestUtils.java locale methods [v2]
In-Reply-To: <BqyL2kE0IxZLZ4QMSWed-bGCFgtZIf_v-nMj6uo7U3Y=.85391153-986d-4541-b7c1-fd23bce280a8@github.com>
References: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
 <BqyL2kE0IxZLZ4QMSWed-bGCFgtZIf_v-nMj6uo7U3Y=.85391153-986d-4541-b7c1-fd23bce280a8@github.com>
Message-ID: <g8RNMdg0KqnYuKJ67V_i6f4gmbBmy1mT7ztxhPI9PXU=.cb852d76-11d3-4d1a-8591-800065f8b9a8@github.com>

On Tue, 2 Dec 2025 19:14:02 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test.
>> 
>> The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g.
>> 
>>> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0]
>> 
>> As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.)
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect Naoto's comments

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28590#pullrequestreview-3536085126

From jlu at openjdk.org  Wed Dec  3 17:28:24 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 Dec 2025 17:28:24 GMT
Subject: <i18n dev> RFR: 8362428: Update IANA Language Subtag Registry
 to Version 2025-08-25
In-Reply-To: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
References: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
Message-ID: <NRh2cbkp18aPZ6H_PRJC2zoaNGjU7cyVQm3BmyePGFI=.713b3962-e661-41ab-a74a-e55a01c745a7@github.com>

On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

Thank you for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28612#issuecomment-3607960489

From naoto.sato at oracle.com  Wed Dec  3 17:29:21 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 3 Dec 2025 09:29:21 -0800
Subject: <i18n dev> CFV: Withdraw sponsorship of Locale Enhancement Project
Message-ID: <2b82e5c1-4eb6-4018-a2c0-1729f0ec2698@oracle.com>

I hereby propose that the Internationalization group withdraw 
sponsorship of the Locale Enhancement Project [1]. This project has been 
inactive after the enhancement work was complete in JDK 7 [2].

This project has only one group sponsor. A consequence of withdrawing 
sponsorship is that this project will be dissolved [3]. Votes are due by 
December 18, 2025, 23.59 UTC. Only current Internationalization group 
members [4] are eligible to vote on this motion. Votes must be cast in 
the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Naoto

[1] https://openjdk.org/projects/locale-enhancement
[2] https://bugs.openjdk.org/browse/JDK-6875847
[3] https://openjdk.org/bylaws#sponsor
[4] https://openjdk.org/census#i18n
[5] https://openjdk.org/bylaws#lazy-consensus

From jlu at openjdk.org  Wed Dec  3 17:28:25 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 Dec 2025 17:28:25 GMT
Subject: <i18n dev> Integrated: 8362428: Update IANA Language Subtag
 Registry to Version 2025-08-25
In-Reply-To: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
References: <DVrjbasv-ol5GlXH_qHyS4aDwx769QYw99KnRA9kKFw=.1ca7f262-f0bb-4477-a317-db0ddb4a51c7@github.com>
Message-ID: <sR5P9UXWDHSerThXml53Hy0vjy4RQWYANpXlVgDii4o=.819a3252-2200-48d4-9be4-54e634ce4bd4@github.com>

On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25.

This pull request has now been integrated.

Changeset: fa6ca0bb
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fa6ca0bbd14436cd3778a7a3383183cd73688123
Stats:     59 lines in 2 files changed: 53 ins; 0 del; 6 mod

8362428: Update IANA Language Subtag Registry to Version 2025-08-25

Reviewed-by: lancea, naoto, iris

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

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

From naoto.sato at oracle.com  Wed Dec  3 17:30:35 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 3 Dec 2025 09:30:35 -0800
Subject: <i18n dev> CFV: Withdraw sponsorship of Locale Enhancement
 Project
In-Reply-To: <2b82e5c1-4eb6-4018-a2c0-1729f0ec2698@oracle.com>
References: <2b82e5c1-4eb6-4018-a2c0-1729f0ec2698@oracle.com>
Message-ID: <1c852884-3f32-4351-bf2e-29270d8d7ac5@oracle.com>

Vote: yes

Naoto

On 12/3/25 9:29 AM, Naoto Sato wrote:
> I hereby propose that the Internationalization group withdraw 
> sponsorship of the Locale Enhancement Project [1]. This project has been 
> inactive after the enhancement work was complete in JDK 7 [2].
> 
> This project has only one group sponsor. A consequence of withdrawing 
> sponsorship is that this project will be dissolved [3]. Votes are due by 
> December 18, 2025, 23.59 UTC. Only current Internationalization group 
> members [4] are eligible to vote on this motion. Votes must be cast in 
> the open by replying to this mailing list.
> 
> For Lazy Consensus voting instructions, see [5].
> 
> Naoto
> 
> [1] https://openjdk.org/projects/locale-enhancement
> [2] https://bugs.openjdk.org/browse/JDK-6875847
> [3] https://openjdk.org/bylaws#sponsor
> [4] https://openjdk.org/census#i18n
> [5] https://openjdk.org/bylaws#lazy-consensus


From justin.lu at oracle.com  Wed Dec  3 17:42:42 2025
From: justin.lu at oracle.com (Justin Lu)
Date: Wed, 3 Dec 2025 17:42:42 +0000
Subject: <i18n dev> CFV: Withdraw sponsorship of Locale Enhancement
 Project
In-Reply-To: <mailman.11343.1764782960.117.i18n-dev@openjdk.org>
References: <mailman.11343.1764782960.117.i18n-dev@openjdk.org>
Message-ID: <BLAPR10MB48977475A0DE85895CBD73428BD9A@BLAPR10MB4897.namprd10.prod.outlook.com>

Vote: yes



I hereby propose that the Internationalization group withdraw
sponsorship of the Locale Enhancement Project [1]. This project has been
inactive after the enhancement work was complete in JDK 7 [2].

This project has only one group sponsor. A consequence of withdrawing
sponsorship is that this project will be dissolved [3]. Votes are due by
December 18, 2025, 23.59 UTC. Only current Internationalization group
members [4] are eligible to vote on this motion. Votes must be cast in
the open by replying to this mailing list.

For Lazy Consensus voting instructions, see [5].

Naoto

[1] https://openjdk.org/projects/locale-enhancement
[2] https://bugs.openjdk.org/browse/JDK-6875847
[3] https://openjdk.org/bylaws#sponsor
[4] https://openjdk.org/census#i18n
[5] https://openjdk.org/bylaws#lazy-consensus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20251203/973f2587/attachment-0001.htm>

From jlu at openjdk.org  Thu Dec  4 18:38:57 2025
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 4 Dec 2025 18:38:57 GMT
Subject: <i18n dev> Integrated: 8372844: Improve usage of
 test/jdk/java/text/testlib/TestUtils.java locale methods
In-Reply-To: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
References: <GVyj54kC1Pytlszu-XMDbAMjLT3XP_qM5R2ui3o_B10=.b4b66859-ae79-4e2e-b693-d3408d4040e7@github.com>
Message-ID: <KEEXxPmO1-eFrIpdFRSXP5S0iI9-dg7KsYF4RvPa6g8=.3b43b55e-23e3-4dd2-9174-c9bc055b252d@github.com>

On Mon, 1 Dec 2025 23:51:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test.
> 
> The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g.
> 
>> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0]
> 
> As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.)

This pull request has now been integrated.

Changeset: c7aa1033
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c7aa10339aa40d37dc52e6dcec102f8dca114634
Stats:     223 lines in 12 files changed: 45 ins; 90 del; 88 mod

8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods

Reviewed-by: naoto

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

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

From duke at openjdk.org  Sun Dec  7 02:36:05 2025
From: duke at openjdk.org (Tatsunori Uchino)
Date: Sun, 7 Dec 2025 02:36:05 GMT
Subject: <i18n dev> RFR: 8364007: Add no-argument codePointCount method
 to CharSequence and String [v3]
In-Reply-To: <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <yXytI-4YecOG5cmyj97odjcDzuvDi5bpvgntMngLLBM=.8680d382-bab3-4fa5-bc21-5c4aecf3ca42@github.com>
Message-ID: <TK5CIKw2dgafZZcvU8TA_-Sm2YnL4LL-5vdfhwCIxTQ=.0eac1f0e-c2aa-47a9-9875-e4299c752c8e@github.com>

On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino <duke at openjdk.org> wrote:

>> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
>> 
>> 
>> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>>     throw new Exception("exceeding length");
>> }
>> 
>> 
>> Is a CSR required to this change?
>
> Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Update `@bug` in correct file
>  - Add default implementation on codePointCount in CharSequence
>  - Update `@bug` entries in test class doc comments
>  - Discard changes on code whose form is not `str.codePointCount(0, str.length())`

Other tasks have higher priorities.

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

PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3621301718

From jlu at openjdk.org  Mon Dec  8 18:11:21 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 8 Dec 2025 18:11:21 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v4]
In-Reply-To: <hi8DT6X0BNMx5wNJSeBE036ZqFstwEvRhG_-JyilOkA=.e7ac62fc-40fe-4c1d-a0a0-dfa63e50de37@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <hi8DT6X0BNMx5wNJSeBE036ZqFstwEvRhG_-JyilOkA=.e7ac62fc-40fe-4c1d-a0a0-dfa63e50de37@github.com>
Message-ID: <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com>

On Wed, 23 Jul 2025 17:39:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further wording refinement

Now that PR is open again, did another take and looks good as before. Minor test comments.

test/jdk/java/util/Locale/LocaleTest.java line 712:

> 710:         Locale indonesianNew = Locale.of("id");
> 711: 
> 712:         if (!hebrewOld.getLanguage().equals("he")) {

Since we are using JUnit, these assertions would be cleaner as `assertEquals`.

test/jdk/java/util/Locale/LocaleTest.java line 714:

> 712:         if (!hebrewOld.getLanguage().equals("he")) {
> 713:             fail("Got back wrong language code for old Hebrew: expected \"he\", got \""
> 714:                     + hebrewNew.getLanguage() + "\"");

Here and below, I think these errors should be including the old language in the fail message, not the new language. i.e. `hebrewOld.getLanguage` instead of `hebrewNew.getLanguage`.

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

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3553326987
PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599560414
PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599581669

From naoto at openjdk.org  Mon Dec  8 19:08:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Dec 2025 19:08:46 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v5]
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <IzEm-qmKrxSXO-JMqkcKyiowQ-Z3otnZaDZfXR85nOY=.67248e10-0ea3-429e-838b-e52d61a5bd28@github.com>

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

Naoto Sato 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 six additional commits since the last revision:

 - Reflects review comments
 - Merge branch 'master' into JDK-8355522-Remove-useOldISOCodes
 - Further wording refinement
 - Obsolete comment correction
 - Reflects review comments
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26419/files
  - new: https://git.openjdk.org/jdk/pull/26419/files/c68a63be..965830aa

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

  Stats: 664985 lines in 7465 files changed: 452015 ins; 138570 del; 74400 mod
  Patch: https://git.openjdk.org/jdk/pull/26419.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419

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

From naoto at openjdk.org  Mon Dec  8 19:13:02 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Dec 2025 19:13:02 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v4]
In-Reply-To: <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <hi8DT6X0BNMx5wNJSeBE036ZqFstwEvRhG_-JyilOkA=.e7ac62fc-40fe-4c1d-a0a0-dfa63e50de37@github.com>
 <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com>
Message-ID: <YXCgYm1ovoX24xhctAicHMVrDpR5O8aqgxyBFb3kN3c=.5eccfe46-e25b-472c-ad3e-a961c9a7725d@github.com>

On Mon, 8 Dec 2025 17:51:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Further wording refinement
>
> test/jdk/java/util/Locale/LocaleTest.java line 712:
> 
>> 710:         Locale indonesianNew = Locale.of("id");
>> 711: 
>> 712:         if (!hebrewOld.getLanguage().equals("he")) {
> 
> Since we are using JUnit, these assertions would be cleaner as `assertEquals`.

In this test file, there are other locations that use `fail`. Although it would be preferred to replace them with `assertEquals`, probably  better be cleaned up with a separate issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599806334

From aturbanov at openjdk.org  Mon Dec  8 20:21:04 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 8 Dec 2025 20:21:04 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v5]
In-Reply-To: <IzEm-qmKrxSXO-JMqkcKyiowQ-Z3otnZaDZfXR85nOY=.67248e10-0ea3-429e-838b-e52d61a5bd28@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <IzEm-qmKrxSXO-JMqkcKyiowQ-Z3otnZaDZfXR85nOY=.67248e10-0ea3-429e-838b-e52d61a5bd28@github.com>
Message-ID: <IiDtFm4Uk0e2HM-Wf0lypewx2GMxljFVlFYJ4vFtdGY=.8748cef5-810b-45f3-95f9-be34c02a7707@github.com>

On Mon, 8 Dec 2025 19:08:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato 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 six additional commits since the last revision:
> 
>  - Reflects review comments
>  - Merge branch 'master' into JDK-8355522-Remove-useOldISOCodes
>  - Further wording refinement
>  - Obsolete comment correction
>  - Reflects review comments
>  - initial commit

src/java.base/share/classes/sun/util/locale/BaseLocale.java line 116:

> 114:      */
> 115:     static {
> 116:         if (!System.getProperty("java.locale.useOldISOCodes", "").isEmpty()) {

Hm. Why don't we compare result with null? Do we want to allow empty values `-Djava.locale.useOldISOCodes=` ?

Suggestion:

        if (System.getProperty("java.locale.useOldISOCodes") != null) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2600000217

From naoto at openjdk.org  Mon Dec  8 20:54:34 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 8 Dec 2025 20:54:34 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v6]
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

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

  Apply suggestions from code review
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26419/files
  - new: https://git.openjdk.org/jdk/pull/26419/files/965830aa..c427e188

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

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

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

From jlu at openjdk.org  Mon Dec  8 22:05:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 8 Dec 2025 22:05:58 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v6]
In-Reply-To: <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
Message-ID: <zA3PEcgOxd5fMFULk9aUbGwLLlIKASnfGobqNzblNSw=.222ef2a4-a651-4db7-911c-62f56b50c029@github.com>

On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by jlu (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3554248730

From joehw at openjdk.org  Tue Dec  9 04:53:58 2025
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 9 Dec 2025 04:53:58 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v6]
In-Reply-To: <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
Message-ID: <tf41RS8Uxp3TTCW3E2in9N9XjwXwmga0YklXYH2YC34=.3c381972-f91d-4c2d-b1a6-34f6ed4320ed@github.com>

On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3555443566

From swen at openjdk.org  Tue Dec  9 06:15:41 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 9 Dec 2025 06:15:41 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v6]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <jtstmQfzL-ipJQ0WuRf3nlb84QTpyQ4Niq1YLnHUEAM=.8f372ddd-f5fc-4f4b-89bf-3d74dcc21075@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Revert "resolverFields, from @liach"
  
  This reverts commit b2b19e1368ef9b295876e6b79f8bfb163f3b3f1c.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/b2b19e13..90dca377

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

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

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

From swen at openjdk.org  Tue Dec  9 10:02:36 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 9 Dec 2025 10:02:36 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
Message-ID: <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>

> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
> 
> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
> 
> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
> 
> Parsing scenarios show improvements from 12% to 95%

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove redundant checkField

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28471/files
  - new: https://git.openjdk.org/jdk/pull/28471/files/90dca377..9a13e51e

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

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

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

From swen at openjdk.org  Tue Dec  9 13:35:00 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 9 Dec 2025 13:35:00 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
Message-ID: <wSP94aAjOFpHs1XqB0i4ffa5wq9d43a3xhbXMHdcWtU=.31934e67-5ddd-4fec-8750-fa1f3f1fb415@github.com>

On Tue, 9 Dec 2025 10:02:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant checkField

<img width="1920" height="1298" alt="image" src="https://github.com/user-attachments/assets/8c2793b8-70d9-4b39-814d-f16d52100d7a" />

As shown in the image above, the `DateTimeFormatterBuilder#appendValue` method does not need to call `checkField`; it only needs to be called within `appendInternal`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3632289875

From naoto at openjdk.org  Tue Dec  9 18:24:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Dec 2025 18:24:44 GMT
Subject: <i18n dev> RFR: 8355522: Remove the
 `java.locale.useOldISOCodes` system property [v6]
In-Reply-To: <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
 <RqOUTumnEGyGRNcYpHUlI9G4teppYQKzkS9KCLfHvtU=.d2735642-f1d0-4ced-9acf-a46352166115@github.com>
Message-ID: <muIYK8K5jrvdGcQwaW3C9eEvlkRjkGQEDeHjVcHpSRk=.61c7d7db-379a-4e3f-a8a3-244550815a28@github.com>

On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Apply suggestions from code review
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/26419#issuecomment-3633629881

From naoto at openjdk.org  Tue Dec  9 18:24:46 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Dec 2025 18:24:46 GMT
Subject: <i18n dev> Integrated: 8355522: Remove the
 `java.locale.useOldISOCodes` system property
In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com>
Message-ID: <9lj9uqEfY1OCrmtV5GPDGQYFdJZEadvzidDCxoHLcJQ=.78ceb2cc-e229-4aac-84de-8e61cdc2394c@github.com>

On Mon, 21 Jul 2025 22:56:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well

This pull request has now been integrated.

Changeset: b2daf9de
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b2daf9de3097de4d3b3c7d565e29a48b4aae19ee
Stats:     106 lines in 6 files changed: 2 ins; 68 del; 36 mod

8355522: Remove the `java.locale.useOldISOCodes` system property

Reviewed-by: jlu, joehw

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

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

From iklam at openjdk.org  Wed Dec 10 09:39:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 09:39:58 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
Message-ID: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>

In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"

https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171

Examples of subgraphs:

- `java.lang.Integer$IntegerCache::cache`
- `jdk.internal.module.ArchivedBootLayer::bootLayer`

The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.

To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.

Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

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

Commit messages:
 - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

Changes: https://git.openjdk.org/jdk/pull/28736/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373392
  Stats: 602 lines in 29 files changed: 368 ins; 186 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

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

From liach at openjdk.org  Wed Dec 10 15:27:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 15:27:56 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

src/java.base/share/classes/java/util/ImmutableCollections.java line 80:

> 78:     @AOTRuntimeSetup
> 79:     private static void runtimeSetup() {
> 80:          // to generate a reasonably random and well-mixed SALT, use an arbitrary

Suggestion:

        // to generate a reasonably random and well-mixed SALT, use an arbitrary

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

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563043067
PR Review Comment: https://git.openjdk.org/jdk/pull/28736#discussion_r2607052565

From iklam at openjdk.org  Wed Dec 10 17:32:38 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 10 Dec 2025 17:32:38 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <T2dpMbwbHVIMHigIEI971AnIIFeB7xpWmveNWxHn0w4=.b6e46ea4-a1a6-47b7-8bf4-0c0c81c1d912@github.com>
Message-ID: <BDaPZ6gkZ_1Bgj73wiO8ZwatxNyt5nxSzu_yXeEYHWk=.40e6594a-018e-4778-8a7b-4b2a50d806f1@github.com>

On Wed, 10 Dec 2025 15:25:29 GMT, Chen Liang <liach at openjdk.org> wrote:

> Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive?

I think so. The cache size for all other Number types are fixed and cannot be modified by the command-line.

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

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3638192576

From liach at openjdk.org  Wed Dec 10 17:39:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 10 Dec 2025 17:39:46 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <SnsvxbACMDrUxVQHu5xUkSSGQPVJae2pOYtCCIykhfU=.ab0888de-9108-453c-b552-f94bc04bc8d9@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

The Java code changes look reasonable.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563746741

From duke at openjdk.org  Thu Dec 11 12:26:26 2025
From: duke at openjdk.org (duke)
Date: Thu, 11 Dec 2025 12:26:26 GMT
Subject: <i18n dev> Withdrawn: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced
In-Reply-To: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
Message-ID: <esyrCORRgWKPJP9Usp6vGCCX52zqorQ__4oFX_oCydo=.b803f17f-7b9d-439a-8862-9f7a8365e1e0@github.com>

On Wed, 15 Oct 2025 18:02:59 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Doc only change.

This pull request has been closed without being integrated.

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

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

From naoto at openjdk.org  Thu Dec 11 19:18:27 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 Dec 2025 19:18:27 GMT
Subject: <i18n dev> RFR: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced [v2]
In-Reply-To: <R46Qyk7BJU4mZJD2nKTS0MQJDclvllv5lDqb5jeDG6E=.71578d4b-4295-495b-a00b-aafe912c7bd9@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
 <R46Qyk7BJU4mZJD2nKTS0MQJDclvllv5lDqb5jeDG6E=.71578d4b-4295-495b-a00b-aafe912c7bd9@github.com>
Message-ID: <QGQB3uGXek8o4AkRH9xhWWVfhtiSU9VZh5OXZzBSZbs=.5c89c687-7c40-4f5c-8746-01b250b5d908@github.com>

On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the 'c' conversion as well.

Could the sentence be more assertive than "might"? Probably "IllegalFormatConversionException is thrown if the TemporalAccesor do not have time zone" or something along the lines?

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

PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3643409843

From rgiulietti at openjdk.org  Fri Dec 12 10:20:26 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 12 Dec 2025 10:20:26 GMT
Subject: <i18n dev> RFR: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced [v3]
In-Reply-To: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
Message-ID: <O9j4xDORtoxgrak5LKZmzGC0BVZFhaaQWVQOkgv_Wko=.9850cd1f-e40f-4aee-8665-d46bcd3ffa18@github.com>

> Doc only change.

Raffaello Giulietti 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:

 - Use a more assertive wording.
 - Merge branch 'master' into 8341914
 - Add the 'c' conversion as well.
 - 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27830/files
  - new: https://git.openjdk.org/jdk/pull/27830/files/c51f19f6..f48bf4d9

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

  Stats: 385531 lines in 3924 files changed: 249386 ins; 86793 del; 49352 mod
  Patch: https://git.openjdk.org/jdk/pull/27830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27830/head:pull/27830

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

From rgiulietti at openjdk.org  Fri Dec 12 10:46:43 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 12 Dec 2025 10:46:43 GMT
Subject: <i18n dev> RFR: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced [v4]
In-Reply-To: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
Message-ID: <K4RXR2NQwGUIew0ouBMrhH1sJ_2J8WyTf8ECk3Kz9Cc=.8e9fae6f-4b78-4264-970c-412ea065228b@github.com>

> Doc only change.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused import.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27830/files
  - new: https://git.openjdk.org/jdk/pull/27830/files/f48bf4d9..b2864964

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

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

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

From rriggs at openjdk.org  Fri Dec 12 17:37:54 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 12 Dec 2025 17:37:54 GMT
Subject: <i18n dev> RFR: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced [v4]
In-Reply-To: <K4RXR2NQwGUIew0ouBMrhH1sJ_2J8WyTf8ECk3Kz9Cc=.8e9fae6f-4b78-4264-970c-412ea065228b@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
 <K4RXR2NQwGUIew0ouBMrhH1sJ_2J8WyTf8ECk3Kz9Cc=.8e9fae6f-4b78-4264-970c-412ea065228b@github.com>
Message-ID: <Wo2m1N9gJ2_jeVsbNeYyPAsNClJdj4V1FuXgh5LA4SY=.7a7a7d1d-32aa-4552-bdca-d6ff2ef2bbf4@github.com>

On Fri, 12 Dec 2025 10:46:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Doc only change.
>
> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused import.

src/java.base/share/classes/java/util/Formatter.java line 442:

> 440:  *     Not all subtypes of {@link TemporalAccessor} carry a time zone, though,
> 441:  *     so in such cases this conversion throws an {@link IllegalFormatConversionException}.
> 442:  *

A more complete description would helpful before the table at line 388 and also
just after the mention of TemporalAccessor at line 1627, I'd suggest a sentence or paragraph with something like: 

The `java.time` types such as `LocalDateTime `or `MonthDay` are TemporalAccessors. 
Each of the formatting character uses fields from the TemporalAccessor but not all accessors have all of the field. For example, the timezone is not available from LocalDateTime.  If a field is not available an IllegalFormatConversionException is thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27830#discussion_r2615056459

From rgiulietti at openjdk.org  Fri Dec 12 18:57:54 2025
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 12 Dec 2025 18:57:54 GMT
Subject: <i18n dev> RFR: 8341914: The j.u.Formatter doc for
 TemporalAccessor should be enhanced [v4]
In-Reply-To: <Wo2m1N9gJ2_jeVsbNeYyPAsNClJdj4V1FuXgh5LA4SY=.7a7a7d1d-32aa-4552-bdca-d6ff2ef2bbf4@github.com>
References: <KtdGBGp5vXRIsQJsoMP9iqj0ofvC-nLytaRoSxWBG9E=.b784ce2f-d566-4681-abc3-97e24e1aeee1@github.com>
 <K4RXR2NQwGUIew0ouBMrhH1sJ_2J8WyTf8ECk3Kz9Cc=.8e9fae6f-4b78-4264-970c-412ea065228b@github.com>
 <Wo2m1N9gJ2_jeVsbNeYyPAsNClJdj4V1FuXgh5LA4SY=.7a7a7d1d-32aa-4552-bdca-d6ff2ef2bbf4@github.com>
Message-ID: <U84aTgkPo-82taON_aVJXXHCSj8bS2bLeFjjR5jeXQc=.f524c1f9-b84e-4722-bf61-04c501b5dbe4@github.com>

On Fri, 12 Dec 2025 17:35:40 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unused import.
>
> src/java.base/share/classes/java/util/Formatter.java line 442:
> 
>> 440:  *     Not all subtypes of {@link TemporalAccessor} carry a time zone, though,
>> 441:  *     so in such cases this conversion throws an {@link IllegalFormatConversionException}.
>> 442:  *
> 
> A more complete description would helpful before the table at line 388 and also
> just after the mention of TemporalAccessor at line 1627, I'd suggest a sentence or paragraph with something like: 
> 
> The `java.time` types such as `LocalDateTime `or `MonthDay` are TemporalAccessors. 
> Each of the formatting character uses fields from the TemporalAccessor but not all accessors have all of the field. For example, the timezone is not available from LocalDateTime.  If a field is not available an IllegalFormatConversionException is thrown.

After a deeper look, it seems to me that what happens with `long` and `Long` used in date/time conversions is not detailed at all ?.
So expect more thorough patch for date/time related conversions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27830#discussion_r2615255683

From jlu at openjdk.org  Fri Dec 12 22:07:06 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Dec 2025 22:07:06 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns
Message-ID: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>

This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.

M1 Mac - Perf (before):


MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms


M1 Mac - Perf (after):


Benchmark                                   Mode  Cnt     Score    Error   Units
MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

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

Commit messages:
 - perf
 - impl

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

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

From jlu at openjdk.org  Fri Dec 12 22:24:07 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Dec 2025 22:24:07 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v2]
In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
Message-ID: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com>

> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
> 
> M1 Mac - Perf (before):
> 
> 
> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
> 
> 
> M1 Mac - Perf (after):
> 
> 
> Benchmark                                   Mode  Cnt     Score    Error   Units
> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

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

  pull values() into a var

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28806/files
  - new: https://git.openjdk.org/jdk/pull/28806/files/702b35f9..8eea336f

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

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

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

From naoto at openjdk.org  Fri Dec 12 22:33:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Dec 2025 22:33:52 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v2]
In-Reply-To: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com>
Message-ID: <AyoaS6SZ9-rT4KFn8rc8xyO0OJpROC3PvL-WWDOVjZk=.1c4c7e84-fd52-431c-8ab4-a23ba0bac1a9@github.com>

On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pull values() into a var

Looks good. Glad we fixed the performance regression, and kudos to the bug submitter

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

> 1991: 
> 1992:         // Returns a FormatStyle corresponding to the input text
> 1993:         // DEFAULT is the empty String, the pre-defined styles are 1-1 with their

The comment could mention that pre-defined ones are lower case ones of the enum names, but compared with the input styles ignoring cases for historical reasons

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

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3573794462
PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615745186

From liach at openjdk.org  Fri Dec 12 22:41:51 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 12 Dec 2025 22:41:51 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v2]
In-Reply-To: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com>
Message-ID: <aGGrnyLEt1Pj1aUxV94h16AwdWPYDogcQcL48yKn7ig=.63fbbae4-0348-43c4-8835-bd8d4084ac33@github.com>

On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   pull values() into a var

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

> 2003:                 var fStyle = styles[i];
> 2004:                 // case-insensitive comp for compatibility
> 2005:                 if (style.compareToIgnoreCase(fStyle.toString()) == 0) {

Suggestion:

                if (style.compareToIgnoreCase(fStyle.name()) == 0) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615761963

From jlu at openjdk.org  Fri Dec 12 22:57:14 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Dec 2025 22:57:14 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v3]
In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
Message-ID: <kCAMX-WYUKsax8R17ds0nM6nE8YdBDKdYrboa01O9zA=.09b44548-912b-45b7-951d-5f0f1e0eb3ff@github.com>

> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
> 
> M1 Mac - Perf (before):
> 
> 
> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
> 
> 
> M1 Mac - Perf (after):
> 
> 
> Benchmark                                   Mode  Cnt     Score    Error   Units
> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

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

  Reflect suggestions from Naoto & Chen

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28806/files
  - new: https://git.openjdk.org/jdk/pull/28806/files/8eea336f..e56ffa12

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

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

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

From naoto at openjdk.org  Fri Dec 12 23:18:52 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 Dec 2025 23:18:52 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v3]
In-Reply-To: <kCAMX-WYUKsax8R17ds0nM6nE8YdBDKdYrboa01O9zA=.09b44548-912b-45b7-951d-5f0f1e0eb3ff@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <kCAMX-WYUKsax8R17ds0nM6nE8YdBDKdYrboa01O9zA=.09b44548-912b-45b7-951d-5f0f1e0eb3ff@github.com>
Message-ID: <sIzsi9HqSNiAsRu9qE34eo7q9YWMux99dPRawWq9_74=.86c02af3-f915-4b39-a629-06601af960ba@github.com>

On Fri, 12 Dec 2025 22:57:14 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflect suggestions from Naoto & Chen

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

> 2002:             var styles = values();
> 2003:             // Match starting at the pre-defined styles -> [SHORT:]
> 2004:             for (int i = 2; i < styles.length; i ++) {

nit: SHORT.ordinal() can be used

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615821178

From jlu at openjdk.org  Fri Dec 12 23:28:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 Dec 2025 23:28:08 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v4]
In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
Message-ID: <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>

> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
> 
> M1 Mac - Perf (before):
> 
> 
> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
> 
> 
> M1 Mac - Perf (after):
> 
> 
> Benchmark                                   Mode  Cnt     Score    Error   Units
> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

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

  use SHORT.ordinal()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28806/files
  - new: https://git.openjdk.org/jdk/pull/28806/files/e56ffa12..8c80ce3e

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

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

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

From naoto at openjdk.org  Mon Dec 15 18:15:44 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 Dec 2025 18:15:44 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v4]
In-Reply-To: <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
Message-ID: <0HGVn99AGEgpbFtSDpr-hinuAjKRuLKd1MBTpwirBpE=.5fd6a2f5-24a8-4f02-867b-2871e8c4aad1@github.com>

On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use SHORT.ordinal()

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3579535320

From liach at openjdk.org  Mon Dec 15 18:29:08 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 18:29:08 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v4]
In-Reply-To: <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
Message-ID: <2fT9Wn3Bf-0oq_2U989AifJ3125-JTmriX5JeHYKNa4=.51351e46-6edf-49c9-abed-0e0c14b9e4ea@github.com>

On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use SHORT.ordinal()

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3579582217

From aturbanov at openjdk.org  Mon Dec 15 20:44:39 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Dec 2025 20:44:39 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v4]
In-Reply-To: <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <fca5-HMUgX2516mHkRPc1dbWZS5n77CzHW_FgaIN_8o=.82cdc561-19e7-4ad4-b118-d6b9080e442c@github.com>
Message-ID: <K4faONfdmYBpojfs2BbLIcP-RRCrHdfZ69Kcdd5mmrI=.9acd989c-155a-4f09-8fd6-f23eff5e70b6@github.com>

On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use SHORT.ordinal()

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

> 2002:             var styles = values();
> 2003:             // Match starting at the pre-defined styles -> [SHORT:]
> 2004:             for (int i = SHORT.ordinal(); i < styles.length; i ++) {

Suggestion:

            for (int i = SHORT.ordinal(); i < styles.length; i++) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2620785423

From jlu at openjdk.org  Mon Dec 15 21:20:29 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 Dec 2025 21:20:29 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v5]
In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
Message-ID: <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>

> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
> 
> M1 Mac - Perf (before):
> 
> 
> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
> 
> 
> M1 Mac - Perf (after):
> 
> 
> Benchmark                                   Mode  Cnt     Score    Error   Units
> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

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

  spacing of increment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28806/files
  - new: https://git.openjdk.org/jdk/pull/28806/files/8c80ce3e..2fe77590

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

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

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

From liach at openjdk.org  Mon Dec 15 21:50:32 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 15 Dec 2025 21:50:32 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v5]
In-Reply-To: <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
Message-ID: <sUqfO5jxbTQhoxNGa10mMWyeks1NprY9cu0hclMvkI4=.721e7cf1-8db0-44b8-9703-652bc091672e@github.com>

On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spacing of increment

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3580310763

From jlu at openjdk.org  Mon Dec 15 22:57:08 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 Dec 2025 22:57:08 GMT
Subject: <i18n dev> RFR: 8373716: Refactor further java/util tests from
 TestNG to JUnit
Message-ID: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>

This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically,
-  _java/util/Calendar_
-  _java/util/TimeZone_
-  _java/util/Properties_
-  _java/util/ResourceBundle_

 
This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same,

**Calendar**
`791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit`

**TimeZone**
`84 = 39 TestNG + 45 JUnit ->  0 TestNG + 84 JUnit`

**Properties**
`28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit`

**ResourceBundle**
`45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit`

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/28836/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28836&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373716
  Stats: 184 lines in 14 files changed: 44 ins; 23 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/28836.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28836/head:pull/28836

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

From liach at openjdk.org  Tue Dec 16 01:59:55 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 16 Dec 2025 01:59:55 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
Message-ID: <SCqM9aFb0NTtWDUlgmJmtJ7fgSJ3M29QSWOeC3jxNiw=.7d6ab334-8d9e-464b-89dc-2c8ef6b946f3@github.com>

On Tue, 9 Dec 2025 10:02:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant checkField

This looks reasonable in principle. However, we need to verify we indeed won't run into putting non-chronofield into an enum map by accident, and this is a bit hard...

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3580903973

From rriggs at openjdk.org  Tue Dec 16 04:29:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 16 Dec 2025 04:29:59 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v5]
In-Reply-To: <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
Message-ID: <gbNCDqMkjb4d7gn6kBL9sROt0HTRJIwazLAgVgygQYs=.c4d6b9c7-55c6-4b55-b09c-fdb7029b57f3@github.com>

On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spacing of increment

Looks good

Marked as reviewed by rriggs (Reviewer).

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3581214624
PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3581218040

From jlu at openjdk.org  Tue Dec 16 18:14:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Dec 2025 18:14:34 GMT
Subject: <i18n dev> RFR: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns [v5]
In-Reply-To: <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
 <QWDEirQgOhC18pdxMK2o6gKcQMiVWW7SM_p3peUzjiE=.abda5cd5-8d4f-46c6-a29e-f236bf6a094d@github.com>
Message-ID: <W2c1-yZu3GXq9WRjMesAjwVg2kTF0nm0TfN-83HcuEQ=.e316670d-c68c-482e-b97f-88b2601433f1@github.com>

On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
>> 
>> M1 Mac - Perf (before):
>> 
>> 
>> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
>> 
>> 
>> M1 Mac - Perf (after):
>> 
>> 
>> Benchmark                                   Mode  Cnt     Score    Error   Units
>> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
>> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   spacing of increment

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/28806#issuecomment-3661794583

From jlu at openjdk.org  Tue Dec 16 18:14:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Dec 2025 18:14:36 GMT
Subject: <i18n dev> Integrated: 8373566: Performance regression with
 java.text.MessageFormat subformat patterns
In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com>
Message-ID: <R6zEQUkeYi2UQ5KBHXibS1-b3bhirexwG8MVHycG52M=.24056a5a-efeb-4efb-ad7e-d99f6de3b51d@github.com>

On Fri, 12 Dec 2025 21:59:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation.
> 
> M1 Mac - Perf (before):
> 
> 
> MessageFormatterBench.testSubformatChoice  thrpt   15   865.430 ?  6.766  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  1021.808 ? 11.413  ops/ms
> 
> 
> M1 Mac - Perf (after):
> 
> 
> Benchmark                                   Mode  Cnt     Score    Error   Units
> MessageFormatterBench.testSubformatChoice  thrpt   15  1671.033 ? 55.012  ops/ms
> MessageFormatterBench.testSubformatNumber  thrpt   15  3275.727 ? 47.370  ops/ms

This pull request has now been integrated.

Changeset: 81e37576
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81e375768837e1ae6c34c1d0a8eff06b4e1d2889
Stats:     58 lines in 2 files changed: 21 ins; 9 del; 28 mod

8373566: Performance regression with java.text.MessageFormat subformat patterns

Reviewed-by: liach, rriggs, naoto

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

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

From naoto at openjdk.org  Tue Dec 16 19:17:09 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Dec 2025 19:17:09 GMT
Subject: <i18n dev> RFR: 8373716: Refactor further java/util tests from
 TestNG to JUnit
In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
Message-ID: <dr_33EEOE833f8JBU0B99Glz7Ib7t4NMvrb5ozMbenk=.04ed1edf-43a7-4329-ac3e-f91d76d0925c@github.com>

On Mon, 15 Dec 2025 22:50:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically,
> -  _java/util/Calendar_
> -  _java/util/TimeZone_
> -  _java/util/Properties_
> -  _java/util/ResourceBundle_
> 
>  
> This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same,
> 
> **Calendar**
> `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit`
> 
> **TimeZone**
> `84 = 39 TestNG + 45 JUnit ->  0 TestNG + 84 JUnit`
> 
> **Properties**
> `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit`
> 
> **ResourceBundle**
> `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit`

LGTM. One suggestion not related to testng->junit effort.

test/jdk/java/util/Calendar/JapaneseLenientEraTest.java line 45:

> 43: public class JapaneseLenientEraTest {
> 44: 
> 45:     Object[][] names() {

Probably blame is on me, but it would make more sense to rename this method to `lenientEra`.

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

PR Review: https://git.openjdk.org/jdk/pull/28836#pullrequestreview-3584588629
PR Review Comment: https://git.openjdk.org/jdk/pull/28836#discussion_r2624439179

From jlu at openjdk.org  Tue Dec 16 19:25:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 Dec 2025 19:25:34 GMT
Subject: <i18n dev> RFR: 8373716: Refactor further java/util tests from
 TestNG to JUnit [v2]
In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
Message-ID: <vcYgoovJXAhyW675T2qeYm1KOGH7wKuAaiffMaDWmsw=.b2934231-9819-466c-b4dd-a785bfc2d846@github.com>

> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically,
> -  _java/util/Calendar_
> -  _java/util/TimeZone_
> -  _java/util/Properties_
> -  _java/util/ResourceBundle_
> 
>  
> This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same,
> 
> **Calendar**
> `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit`
> 
> **TimeZone**
> `84 = 39 TestNG + 45 JUnit ->  0 TestNG + 84 JUnit`
> 
> **Properties**
> `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit`
> 
> **ResourceBundle**
> `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit`

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

  names -> lenientEra

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28836/files
  - new: https://git.openjdk.org/jdk/pull/28836/files/a65a4930..8a8b31b4

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

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

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

From naoto at openjdk.org  Tue Dec 16 19:48:24 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 Dec 2025 19:48:24 GMT
Subject: <i18n dev> RFR: 8373716: Refactor further java/util tests from
 TestNG to JUnit [v2]
In-Reply-To: <vcYgoovJXAhyW675T2qeYm1KOGH7wKuAaiffMaDWmsw=.b2934231-9819-466c-b4dd-a785bfc2d846@github.com>
References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
 <vcYgoovJXAhyW675T2qeYm1KOGH7wKuAaiffMaDWmsw=.b2934231-9819-466c-b4dd-a785bfc2d846@github.com>
Message-ID: <0P2ruBkQeL5uDxeNyaesYtrrnsBQnVuNFYakIOTr-SA=.4a04a60a-9456-4275-b131-74e30a6227b3@github.com>

On Tue, 16 Dec 2025 19:25:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically,
>> -  _java/util/Calendar_
>> -  _java/util/TimeZone_
>> -  _java/util/Properties_
>> -  _java/util/ResourceBundle_
>> 
>>  
>> This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same,
>> 
>> **Calendar**
>> `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit`
>> 
>> **TimeZone**
>> `84 = 39 TestNG + 45 JUnit ->  0 TestNG + 84 JUnit`
>> 
>> **Properties**
>> `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit`
>> 
>> **ResourceBundle**
>> `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit`
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   names -> lenientEra

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28836#pullrequestreview-3584694256

From hannesw at openjdk.org  Wed Dec 17 08:52:41 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 17 Dec 2025 08:52:41 GMT
Subject: <i18n dev> RFR: 8309748: Improve host selection in `External
 Specifications` page
Message-ID: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>

Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 

 - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
 - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion

I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.

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

Commit messages:
 - 8309748: Improve host selection in `External Specifications` page

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

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

From duke at openjdk.org  Wed Dec 17 09:04:06 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 17 Dec 2025 09:04:06 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
Message-ID: <zPkawnY3vT48jEQD32D6rAzz32T6U5Iy33I_7JEOusM=.5dbd6fea-6b8b-4a20-9a6d-ac32c5456f2c@github.com>

On Tue, 9 Dec 2025 10:02:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant checkField

src/java.base/share/classes/java/time/format/Parsed.java line 175:

> 173:      */
> 174:     @SuppressWarnings("unchecked")
> 175:     Parsed(boolean onlyChronoField) {

If you know that only ChronoFields are used then imho the loop over the entries of `fieldValues` in method `resolveFields`  can be skipped (line 290ff).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2626170333

From duke at openjdk.org  Wed Dec 17 12:13:34 2025
From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=)
Date: Wed, 17 Dec 2025 12:13:34 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
References: <tHf_Gk5I03nJes_7hXFmYFP1UpN21nir_bIU_2rxa_8=.4c0b0036-4098-44a7-b346-685a6ccd47cf@github.com>
 <VMann_XCTAMspP9Qmhz1JCWLQLIDlpJnjCzRBAtfTlA=.6074e73a-5d5b-4926-9e0a-b523890d6558@github.com>
Message-ID: <r9BWz89yocKktk50StqOdJMypA--deUq0fEfigeRBis=.9520597c-e2e1-4a90-af41-8211d3010615@github.com>

On Tue, 9 Dec 2025 10:02:36 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values.
>> 
>> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations.
>> 
>> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure.
>> 
>> Parsing scenarios show improvements from 12% to 95%
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove redundant checkField

src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 551:

> 549:      * This is used to optimize the storage of parsed field values in the Parsed class.
> 550:      */
> 551:     final boolean onlyChronoField;

If you add to DateTimePrinterParser the method:

public default boolean onlyChronoFields() {
    return true;
} 

and override in CompositePrinterParser, NumberPrinterParser, TextPrinterParser, DefaultValueParser with obvious implementations you should be able to get rid of this field, same in DateTimeFormatterBuilder. (Or keep the field, but initialize in the constructor from printerParser).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2626818693

From hannesw at openjdk.org  Wed Dec 17 12:24:22 2025
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Wed, 17 Dec 2025 12:24:22 GMT
Subject: <i18n dev> RFR: 8309748: Improve host selection in `External
 Specifications` page [v2]
In-Reply-To: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
References: <VRQeGKu9h86k5u3kjRt83_F3Ig42hAjgx8Es7rQDrR4=.12c9ad24-a8d1-4ce9-9e49-3dcb701007b7@github.com>
Message-ID: <FfFVf-qGUWALc-YIUgLGqMYhYw9WkkiHAhn7KPFccPc=.a7fb3f67-9066-4dd1-9857-e5a812b25200@github.com>

> Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. 
> 
>  - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html)
>  - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion
> 
> I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a  `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired.

Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision:

  Remove pointless parentheses

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28863/files
  - new: https://git.openjdk.org/jdk/pull/28863/files/4587271c..fe88df58

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

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

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

From heidinga at openjdk.org  Wed Dec 17 14:29:10 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Wed, 17 Dec 2025 14:29:10 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <vg9pS9ukU_J_ogGf-tX36gZME8MV6KyXCab-IeJecjQ=.4f170715-ccfd-4486-8449-68442d361533@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Marked as reviewed by heidinga (no project role).

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

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3588008090

From iklam at openjdk.org  Wed Dec 17 18:16:23 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 18:16:23 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v2]
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <y7hJSyxC6Co9pbu_Zovdo4Orxlom23jJ5IOetBVqLIs=.e33daeb4-a1ed-4f28-b667-981de2058a29@github.com>

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Ioi Lam 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:

 - @liach comment: Fixed identation
 - Merge branch 'master' into 8373392-replace-cds-object-subgraphs-with-aot-safe-class-initializer
 - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28736/files
  - new: https://git.openjdk.org/jdk/pull/28736/files/562d15a9..5497502f

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

  Stats: 15093 lines in 587 files changed: 9847 ins; 1687 del; 3559 mod
  Patch: https://git.openjdk.org/jdk/pull/28736.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736

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

From jlu at openjdk.org  Wed Dec 17 18:20:12 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 17 Dec 2025 18:20:12 GMT
Subject: <i18n dev> Integrated: 8373716: Refactor further java/util tests
 from TestNG to JUnit
In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com>
Message-ID: <ltK-1_jxWLzAc0htE5hFUDCrV2WcV4Q_Cd_pwV6y-OM=.49f314bb-f5c6-438f-9c6d-0fd5c842e3ac@github.com>

On Mon, 15 Dec 2025 22:50:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically,
> -  _java/util/Calendar_
> -  _java/util/TimeZone_
> -  _java/util/Properties_
> -  _java/util/ResourceBundle_
> 
>  
> This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same,
> 
> **Calendar**
> `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit`
> 
> **TimeZone**
> `84 = 39 TestNG + 45 JUnit ->  0 TestNG + 84 JUnit`
> 
> **Properties**
> `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit`
> 
> **ResourceBundle**
> `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit`

This pull request has now been integrated.

Changeset: 4e05748f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e05748f0899cabb235c71ecdf4256d4ad137a0d
Stats:     185 lines in 14 files changed: 44 ins; 23 del; 118 mod

8373716: Refactor further java/util tests from TestNG to JUnit

Reviewed-by: naoto

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

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

From iklam at openjdk.org  Wed Dec 17 20:04:48 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 20:04:48 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28736/files
  - new: https://git.openjdk.org/jdk/pull/28736/files/5497502f..306d9167

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

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

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

From iklam at openjdk.org  Wed Dec 17 20:08:28 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 20:08:28 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
Message-ID: <6Ime-D9wgZGM9Qz-u4IhkQ00fnRPUQOwmX-O70Lz41s=.5c6627aa-9239-4805-987b-aa8c79241f72@github.com>

On Wed, 17 Dec 2025 20:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
>> 
>> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
>> 
>> Examples of subgraphs:
>> 
>> - `java.lang.Integer$IntegerCache::cache`
>> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
>> 
>> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
>> 
>> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
>> 
>> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

I have to fix the SharedSymbolTableBucketSize.java test. With this PR and testing with `-vmoptions:-XX:+AOTClassLinking -vmoptions:-XX:+UseZGC`, the first block of "table stats" has a single entry.

I fixed the test case to look for "Shared symbol table stats", which is the info that the test case intends to check.


[...]
[0.591s][info][cds]     type array classes =     9
[0.591s][info][cds]                symbols = 46244
[0.681s][info][aot,hashtables] Shared subgraphs table stats -------- base: 0x0000000800000000
[0.681s][info][aot,hashtables] Number of entries       :         1
[0.681s][info][aot,hashtables] Total bytes used        :        24
[0.681s][info][aot,hashtables] Average bytes per entry :    24.000
[0.681s][info][aot,hashtables] Average bucket size     :     1.000
[0.681s][info][aot,hashtables] Variance of bucket size :     0.000
[0.681s][info][aot,hashtables] Std. dev. of bucket size:     0.000
[0.681s][info][aot,hashtables] Maximum bucket size     :         1
[0.681s][info][aot,hashtables] Empty buckets           :         0
[0.681s][info][aot,hashtables] Value_Only buckets      :         1
[0.681s][info][aot,hashtables] Other buckets           :         0
[0.688s][info][aot,hashtables] Shared symbol table stats -------- base: 0x0000000800000000
[0.688s][info][aot,hashtables] Number of entries       :     46244
[0.688s][info][aot,hashtables] Total bytes used        :    393792
[0.688s][info][aot,hashtables] Average bytes per entry :     8.516
[0.688s][info][aot,hashtables] Average bucket size     :     7.734
[0.688s][info][aot,hashtables] Variance of bucket size :     7.513
[0.688s][info][aot,hashtables] Std. dev. of bucket size:     2.741
[0.688s][info][aot,hashtables] Maximum bucket size     :        20
[0.688s][info][aot,hashtables] Empty buckets           :         2
[0.688s][info][aot,hashtables] Value_Only buckets      :        24
[0.688s][info][aot,hashtables] Other buckets           :      5953

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

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3666964418

From liach at openjdk.org  Wed Dec 17 22:07:29 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 17 Dec 2025 22:07:29 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
Message-ID: <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>

On Wed, 17 Dec 2025 20:04:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
>> 
>> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
>> 
>> Examples of subgraphs:
>> 
>> - `java.lang.Integer$IntegerCache::cache`
>> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
>> 
>> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
>> 
>> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
>> 
>> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry

The new tests look fine to me.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3589877162

From iklam at openjdk.org  Wed Dec 17 22:19:58 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 22:19:58 GMT
Subject: <i18n dev> RFR: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer [v3]
In-Reply-To: <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
 <ObHUe60IbQtKQeY50_QL4HRA1IB54iUsNL71yo4RcNw=.dc0d6b3e-33d3-49ff-b468-dd99d59592a2@github.com>
 <UGi8SIOC2541L09U7Ma21UhtgRObvJ5KsG4xrSsjPvk=.8263a392-1936-4224-b9ce-630d45ba4c6a@github.com>
Message-ID: <wtmcXvHzUT_C4xaZCjpaDpG_0OQJZ0SOt-TGnoLhrrQ=.3c109b8a-2b38-4a5c-b912-9855773c2d78@github.com>

On Wed, 17 Dec 2025 22:04:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry
>
> The new tests look fine to me.

Thank you @liach @DanHeidinga for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3667419351

From iklam at openjdk.org  Wed Dec 17 22:20:00 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 17 Dec 2025 22:20:00 GMT
Subject: <i18n dev> Integrated: 8373392: Replace CDS object subgraphs with
 @AOTSafeClassInitializer
In-Reply-To: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
References: <nwFU9L_ngxAg_QtXjVq_IvhIxlnHj49sWV-qMUCS0YY=.4417a88a-c604-415f-b389-12a19938fed3@github.com>
Message-ID: <UkRvaYW_7gXE7xTCwdt_nZ7OxrdwYIdeC1OqsEGH1H8=.95d3746f-746f-47e0-9e22-bef7673a7838@github.com>

On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs"
> 
> https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171
> 
> Examples of subgraphs:
> 
> - `java.lang.Integer$IntegerCache::cache`
> - `jdk.internal.module.ArchivedBootLayer::bootLayer`
> 
> The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand.
> 
> To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes.
> 
> Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with  `@AOTSafeClassInitializer`.

This pull request has now been integrated.

Changeset: 232b41b2
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/232b41b2227bc9d03d88d316aa28d0cbe87086f7
Stats:     642 lines in 30 files changed: 406 ins; 186 del; 50 mod

8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer

Reviewed-by: liach, heidinga

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

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