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

From jlu at openjdk.org  Fri Dec 19 00:21:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 Dec 2025 00:21:40 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests to
 use JUnit over TestNG
Message-ID: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>

Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.

First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
The rest of the commits are aesthetic related.

Before conversion stats


Test results: passed: 187
Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit


After conversion stats


Test results: passed: 187
Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

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

Commit messages:
 - Fixing @timeout as well as unrelated stray spacing
 - Apply copyright years
 - Cleaning up some leftover whitespace from tool
 - Automated conversion created statement lambdas for exception tests. Modify to expression lambdas
 - Cleaning up unused JUnit imports
 - Fix converted lambdas
 - Mark TEST.properties as JUnit dirs
 - Apply JUnitConvert

Changes: https://git.openjdk.org/jdk/pull/28911/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8373830
  Stats: 13726 lines in 178 files changed: 2264 ins; 690 del; 10772 mod
  Patch: https://git.openjdk.org/jdk/pull/28911.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28911/head:pull/28911

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

From jlu at openjdk.org  Fri Dec 19 00:21:40 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 Dec 2025 00:21:40 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <jwvjV90tyIuZlwhlUMSY0R280zmXc0iM10C6MWnQOfc=.132e0225-085c-40ee-9529-2e2ce3aec181@github.com>

On Thu, 18 Dec 2025 23:01:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java line 202:

> 200:     @Test
> 201:     public void test_get_TemporalField_invalidField() {
> 202:         Assertions.assertThrows(DateTimeException.class, () -> {

It appears that not all the `TemporalAccessor`s from `samples()` are being tested. I want to keep the total count of tests before and after the migration the same, so handling this separate from this issue. Filed [JDK-8374051](https://bugs.openjdk.org/browse/JDK-8374051).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2632918995

From swen at openjdk.org  Fri Dec 19 02:43:01 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 19 Dec 2025 02:43:01 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <zPkawnY3vT48jEQD32D6rAzz32T6U5Iy33I_7JEOusM=.5dbd6fea-6b8b-4a20-9a6d-ac32c5456f2c@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>
 <zPkawnY3vT48jEQD32D6rAzz32T6U5Iy33I_7JEOusM=.5dbd6fea-6b8b-4a20-9a6d-ac32c5456f2c@github.com>
Message-ID: <IjQkmwYM_eOceqzaw9wITAgYRealQpnZg040LKWY5_w=.fa6fe19a-30ec-4ee5-bbf6-a8e6975fe914@github.com>

On Wed, 17 Dec 2025 09:01:09 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> 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).

Good suggestion, but that should be a separate PR

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

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

From swen at openjdk.org  Fri Dec 19 02:46:55 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 19 Dec 2025 02:46:55 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <r9BWz89yocKktk50StqOdJMypA--deUq0fEfigeRBis=.9520597c-e2e1-4a90-af41-8211d3010615@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>
 <r9BWz89yocKktk50StqOdJMypA--deUq0fEfigeRBis=.9520597c-e2e1-4a90-af41-8211d3010615@github.com>
Message-ID: <m8DAAldKdZmN5GIBC-L1layYau86d8CyUNATqTbsbto=.47b25040-eb23-4587-a4d6-2a3f3e965851@github.com>

On Wed, 17 Dec 2025 12:11:14 GMT, Johannes D?bler <duke at openjdk.org> wrote:

>> 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).

https://github.com/openjdk/jdk/pull/28471/changes/d8742d7514abfe0e36f105fa7310fdb1755ae546

The initial version was similar to what you suggested. In the discussion above, I accepted liach's suggestion and modified it into the current implementation. I prefer the current implementation, and it will be easier to calculate chronoFieldsBitSet in the next step.

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

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

From naoto at openjdk.org  Fri Dec 19 18:40:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Dec 2025 18:40:14 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <hM6fYrMyLbRrriUdpzSRmG-k4zAt3mkHjdV2fm8unmo=.c67f82bc-7781-4812-afff-4a621481aa9d@github.com>

On Thu, 18 Dec 2025 23:01:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

LGTM over all. There may be a bug in the tool, as I see duplicated comments for no apparent reason (did not check all the files)
Also, please rename the directory `java/time/nontestng` to `java/time/nonjunit`.

test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java line 89:

> 87:     static final int HIJRAH_DATE_TYPE = 6;       // java.time.chrono.Ser.HIJRAH_DATE_TYPE
> 88:     static final int MINGUO_DATE_TYPE = 7;       // java.time.chrono.Ser.MINGUO_DATE_TYPE
> 89:     static final int THAIBUDDHIST_DATE_TYPE = 8; // java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE// java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE

The comment seems duplicated for no apparent reason. (Tool's bug?)

test/jdk/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java line 76:

> 74: public class TCKChronologySerialization extends AbstractTCKTest {
> 75: 
> 76:     static final int CHRONO_TYPE = 1;            // java.time.chrono.Ser.CHRONO_TYPE// java.time.chrono.Ser.CHRONO_TYPE

Same here

test/jdk/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java line 95:

> 93: public class TCKEraSerialization extends AbstractTCKTest {
> 94: 
> 95:     static final int JAPANESE_ERA_TYPE = 5;     // java.time.chrono.Ser.JAPANESE_ERA// java.time.chrono.Ser.JAPANESE_ERA

And here too

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

PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3599617701
PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635940661
PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635942887
PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635944980

From naoto.sato at oracle.com  Fri Dec 19 18:54:38 2025
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 19 Dec 2025 10:54:38 -0800
Subject: <i18n dev> Result: Withdraw sponsorship of Locale Enhancement
 Project
Message-ID: <e47fbd37-bcc7-487e-8ad0-60cea87685e6@oracle.com>

Voting on this motion [1] is now closed.

Yes: 2
Veto: 0
Abstain: 0

According to the Bylaws definitions of Lazy Consensus [2], this is 
sufficient to approve the motion and the Internationalization group 
withdraws sponsorship of the Locale Enhancement Project.

Naoto

[1] https://mail.openjdk.org/pipermail/i18n-dev/2025-December/012158.html
[2] https://openjdk.org/bylaws#lazy-consensus

From jlu at openjdk.org  Fri Dec 19 19:52:34 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 Dec 2025 19:52:34 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v2]
In-Reply-To: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
Message-ID: <oGu8syexb-9cYNrP88mB7Q8OXFFVTTMyhY_KnF8YcN0=.1b3c2971-58f1-4d53-a77d-8e4c71d71ffd@github.com>

> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
> 
> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
> The rest of the commits are aesthetic related.
> 
> Before conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
> 
> 
> After conversion stats
> 
> 
> Test results: passed: 187
> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit

Justin Lu has updated the pull request incrementally with two additional commits since the last revision:

 - nontestng -> nonjunit
 - Fix comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28911/files
  - new: https://git.openjdk.org/jdk/pull/28911/files/d07c912c..d90d23ed

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

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

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

From jlu at openjdk.org  Fri Dec 19 19:52:36 2025
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 Dec 2025 19:52:36 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v2]
In-Reply-To: <hM6fYrMyLbRrriUdpzSRmG-k4zAt3mkHjdV2fm8unmo=.c67f82bc-7781-4812-afff-4a621481aa9d@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
 <hM6fYrMyLbRrriUdpzSRmG-k4zAt3mkHjdV2fm8unmo=.c67f82bc-7781-4812-afff-4a621481aa9d@github.com>
Message-ID: <UE_WHg_zkGVyvgSbEgjn4UKPB5JTm8FNrtp1lSE6MHo=.752523d4-07a4-4c35-9434-803aa2b52b51@github.com>

On Fri, 19 Dec 2025 18:33:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - nontestng -> nonjunit
>>  - Fix comments
>
> test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java line 89:
> 
>> 87:     static final int HIJRAH_DATE_TYPE = 6;       // java.time.chrono.Ser.HIJRAH_DATE_TYPE
>> 88:     static final int MINGUO_DATE_TYPE = 7;       // java.time.chrono.Ser.MINGUO_DATE_TYPE
>> 89:     static final int THAIBUDDHIST_DATE_TYPE = 8; // java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE// java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE
> 
> The comment seems duplicated for no apparent reason. (Tool's bug?)

Thanks for spotting, it does appear to be left by the tool. I searched for other occurrences and did not find any besides the ones you mentioned.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2636118993

From rriggs at openjdk.org  Fri Dec 19 21:44:59 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 19 Dec 2025 21:44:59 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: <XNKPXvOryp3qyKraqCIhjFzSa8hZgTaem2ekyEGMclo=.d9f7fc85-79c8-4627-8373-fa00a5f910c3@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 version isn't well encapsulated and has changes across multiple files.
What was suggested at the beginning of December is prototyped in PR #28936.

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

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

From naoto at openjdk.org  Sat Dec 20 00:27:58 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 20 Dec 2025 00:27:58 GMT
Subject: <i18n dev> RFR: 8373830: Refactor test/jdk/java/time/test tests
 to use JUnit over TestNG [v2]
In-Reply-To: <oGu8syexb-9cYNrP88mB7Q8OXFFVTTMyhY_KnF8YcN0=.1b3c2971-58f1-4d53-a77d-8e4c71d71ffd@github.com>
References: <DNZcuJz_CHKgdOTFes0deM69UHBjQf1ioBKVfjexxxQ=.649775b1-0fdd-485f-bc7a-ea1ca5286046@github.com>
 <oGu8syexb-9cYNrP88mB7Q8OXFFVTTMyhY_KnF8YcN0=.1b3c2971-58f1-4d53-a77d-8e4c71d71ffd@github.com>
Message-ID: <i8pn6b-oA3PByG47U7K7wDAvt7iJKMUyk3d-wLY72Go=.bd0a5410-1b65-40e6-8ac7-7625a702a8e5@github.com>

On Fri, 19 Dec 2025 19:52:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit.
>> 
>> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974.
>> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run.
>> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool.
>> The rest of the commits are aesthetic related.
>> 
>> Before conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit
>> 
>> 
>> After conversion stats
>> 
>> 
>> Test results: passed: 187
>> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit
>
> Justin Lu has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - nontestng -> nonjunit
>  - Fix comments

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3600504359

From swen at openjdk.org  Sat Dec 20 05:26:50 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sat, 20 Dec 2025 05:26:50 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <XNKPXvOryp3qyKraqCIhjFzSa8hZgTaem2ekyEGMclo=.d9f7fc85-79c8-4627-8373-fa00a5f910c3@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>
 <XNKPXvOryp3qyKraqCIhjFzSa8hZgTaem2ekyEGMclo=.d9f7fc85-79c8-4627-8373-fa00a5f910c3@github.com>
Message-ID: <z0sXxDck3-xcnKcweMcOLjjxGqbl8v3QBWmuKLejA_o=.f54f11f7-f61d-4acd-9dc3-4f50896fe001@github.com>

On Fri, 19 Dec 2025 21:42:14 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This version isn't well encapsulated and has changes across multiple files. What was suggested at the beginning of December is prototyped in PR #28936.

1. Using exceptions for logic control seems like a bad practice.

2. A DateTimeFormatter is reused multiple times. Our approach of calculating `onlyChronoField` only runs once during construction. However, using a runtime approach with `try-catch ClassCastException` executes the corresponding code every time `parse` is called. This is a choice between executing once and executing multiple times.

3. In the `DateTimeFormatter::checkField` method, we could later add an `int chronoFieldBitSet` field to record which ChronoFields are used. This could further optimize other methods of `Parsed`.

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

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

From duke at openjdk.org  Sat Dec 20 07:57:03 2025
From: duke at openjdk.org (khanbilal732)
Date: Sat, 20 Dec 2025 07:57:03 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: <1AAarrfD-phPgtlAouQqYJmVWtZ8RiilagnF3OH0P_w=.712748cd-4fb4-45b6-99b6-0efedd637756@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

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

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

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

From liach at openjdk.org  Sat Dec 20 15:46:56 2025
From: liach at openjdk.org (Chen Liang)
Date: Sat, 20 Dec 2025 15:46:56 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: <8SYcvuKQETAkpwcYiH8rhjuqx1QxN5BIfmHdiNeURw4=.7664b61d-c6a7-4d4b-9cf0-83a2ad7ecf88@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

I just noted that custom TemporalField implementations must be able to put any TemporalField they like into this map:
https://github.com/openjdk/jdk/blob/2d0928406027a848cf2d2d0574024970b8fb535c/src/java.base/share/classes/java/time/temporal/TemporalField.java#L364-L379

Roger's model will fail if a non-TemporalField puts into this map. This PR's model is safe because all `TemporalField` here will be `ChronoField` which won't try to do dangerous stuff to the map.

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

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

From rriggs at openjdk.org  Sat Dec 20 21:33:02 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 20 Dec 2025 21:33:02 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: <L2pIlRZN8yWKblHuskcShzrYI7xYBBUmgyO6pgvsx5E=.55e7513e-2f11-4ccc-adfa-739109fe3b61@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 PR has been through too many incremental changes.
I suspect a better solution is to implement a fit-for-purpose Map, optimized for ChronoFields but taking into account the possibility of unknown TemporalFields. All within the implementation of a Map<TemporalField, Long>.
I'd like to see this PR closed and take a fresh look with all that is learned by the attempt.

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

Changes requested by rriggs (Reviewer).

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

From swen at openjdk.org  Sun Dec 21 03:11:58 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 21 Dec 2025 03:11:58 GMT
Subject: <i18n dev> RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v7]
In-Reply-To: <L2pIlRZN8yWKblHuskcShzrYI7xYBBUmgyO6pgvsx5E=.55e7513e-2f11-4ccc-adfa-739109fe3b61@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>
 <L2pIlRZN8yWKblHuskcShzrYI7xYBBUmgyO6pgvsx5E=.55e7513e-2f11-4ccc-adfa-739109fe3b61@github.com>
Message-ID: <02zE8rOqmMB8MdI-lumotct6Jac2d4x5c_JFQrJWvLQ=.cbedc414-08b4-41db-a22f-653954aa164e@github.com>

On Sat, 20 Dec 2025 21:30:32 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This PR has been through too many incremental changes. I suspect a better solution is to implement a fit-for-purpose Map, optimized for ChronoFields but taking into account the possibility of unknown TemporalFields. All within the implementation of a Map<TemporalField, Long>. I'd like to see this PR closed and take a fresh look with all that is learned by the attempt.

I believe that tasks that can be performed during the build process should not be done during the parse process.

The process of building a DateTimeBuilder is executed once, while the parsing process is executed N times.

For example, a pattern like `yyyy-MM-dd HH:mm:ss.SSS` requires calling the `put` method of the Map 7 times during the parsing process.

Therefore, I think we should check whether chronoFieldOnly is used in DateTimeFormatterBuilder.

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

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

From rriggs at openjdk.org  Mon Dec 22 14:34:04 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Dec 2025 14:34:04 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: <kuxRlRgvqc5sV8Vl8RA7zZFhQn4NQJzAg6vUrWGUQxM=.48a1cea2-91ac-4ad4-a2cb-b83fd5dc418a@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

Given early comments about parsing, I'd expect further work to allow queries of the Map testing for the fields needed by common patterns. A specialized Map could use a bitmap/array for the ChronoFields and test for multiple fields at a time.
A specialized Map could have a `putChronoField` method that would bypass extra testing on the type, it would be used by the implementation in Parsed maintaining encapsulation.
There is an edge case that could be used for an custom implementation of TemporalField in which the `TemporField.resolve` implementation for the new custom field could `put` a new non-ChronoField field into the map.

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

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

From liach at openjdk.org  Mon Dec 22 16:02:01 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 22 Dec 2025 16:02:01 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: <1fPWBjSZO5rye867HjTu4PDI_JMKhDniT59FaeZ1IXk=.0701f069-733d-4552-9ef7-ee7327ac82cc@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

I think this work may be accepted for now for its immediate performance gain. Properly implementing a Map is a more complex task that is no less error prone compared to this onlyChronoField boolean tracker field.

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

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

From rriggs at openjdk.org  Mon Dec 22 16:13:58 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 22 Dec 2025 16:13:58 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: <L6U_8lZ1ZOFXezPJjCUi1T8QsAanOdqOEDh9mpanFZY=.d6bd4855-bc09-426a-a4ae-62688f9ddfb3@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

I primarily object to the spread of state across multiple classes where it is not needed.
Accepting short term gains, just puts off final solutions and tends to muddy the implementation.

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

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

From iklam at openjdk.org  Mon Dec 22 18:05:44 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 22 Dec 2025 18:05:44 GMT
Subject: <i18n dev> RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java
 fails with JTREG_AOT_JDK=onestep
Message-ID: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>

This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 

Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.

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

Commit messages:
 - 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep

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

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

From duke at openjdk.org  Mon Dec 22 18:05:44 2025
From: duke at openjdk.org (khanbilal732)
Date: Mon, 22 Dec 2025 18:05:44 GMT
Subject: <i18n dev> RFR: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
Message-ID: <K0S_oBSqL71qsjAF6mjpXhsFUT_C3INXfmoGShC-imQ=.b78c12fd-dd49-4ec2-b9bb-75c335c2bf44@github.com>

On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
> 
> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600847786
PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600867977

From naoto at openjdk.org  Mon Dec 22 18:09:11 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Dec 2025 18:09:11 GMT
Subject: <i18n dev> RFR: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
Message-ID: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com>

On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
> 
> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.

Looks fine

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3605159944

From iklam at openjdk.org  Mon Dec 22 19:47:07 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 22 Dec 2025 19:47:07 GMT
Subject: <i18n dev> RFR: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
 <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com>
Message-ID: <Me6WX-OKTiVEfujjvwlIR2m1hHBXIW6pMG-j1MeVuRc=.3c9312c3-a20a-43f1-9633-f4ba5e7b3e8e@github.com>

On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
>> 
>> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.
>
> Looks fine

Thanks @naotoj for the review

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

PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3683897935

From iklam at openjdk.org  Mon Dec 22 19:47:09 2025
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 22 Dec 2025 19:47:09 GMT
Subject: <i18n dev> Integrated: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
Message-ID: <zMq1am93ACq3VmZVNWNiNPsQuv1rAnR7f7YmTAsBnHQ=.08fe6b46-0726-4b2e-a5a1-2196502ff3ba@github.com>

On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
> 
> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.

This pull request has now been integrated.

Changeset: 4b8eda30
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2
Stats:     6 lines in 1 file changed: 6 ins; 0 del; 0 mod

8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep

Reviewed-by: naoto

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

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

From alanb at openjdk.org  Tue Dec 23 08:33:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Dec 2025 08:33:10 GMT
Subject: <i18n dev> RFR: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
 <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com>
Message-ID: <KzlYP1sNkVbkR5d_Q1tPi8Jx0fgBeRrTAHx-bXOzago=.e0bd800c-b373-4d41-a4ce-740b2dfde80a@github.com>

On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
>> 
>> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.
>
> Looks fine

@naotoj java.locale.useOldISOCodes was added as a compatibility switch in JDK 17. Do you have any sense as to whether it is used? I'm just wondering if if the "no longer supported" warning when the property is specified on the command line is worth it.

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

PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3685715503

From naoto at openjdk.org  Tue Dec 23 17:39:14 2025
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Dec 2025 17:39:14 GMT
Subject: <i18n dev> RFR: 8373983:
 java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep
In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com>
Message-ID: <Og9VBPchvcuWwlqJLmiZxlY4t69uePeG-6Q0bnB5Q6g=.c14885f2-91f5-4918-90c5-49090084ff6f@github.com>

On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.<clinit>` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.<clinit>` is not executed when the test is running with an AOT cache, so the message is not printed. 
> 
> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode.

AFAIK, Google has been using the system property (cf. comments in https://bugs.openjdk.org/browse/JDK-8267069). So I would rather be on the safer side to emit the warning.

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

PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3687445514

From serb at openjdk.org  Tue Dec 23 23:46:20 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 23 Dec 2025 23:46:20 GMT
Subject: <i18n dev> RFR: 8374310: Update copyright year to 2025 for
 client-libs in files where it was missed
Message-ID: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>

The copyright year in client-area files updated in 2025 has been bumped to 2025.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
`

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

Commit messages:
 - 8374310: Update copyright year to 2025 for client-libs in files where it was missed

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

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

From serb at openjdk.org  Wed Dec 24 01:49:49 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 01:49:49 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for hotspot
 in files where it was missed
Message-ID: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>

The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

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

Commit messages:
 - 8374316: Update copyright year to 2025 for hotspot in files where it was missed

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

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

From kbarrett at openjdk.org  Wed Dec 24 04:34:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 24 Dec 2025 04:34:53 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for
 hotspot in files where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)

There are a lot of non-hotspot files in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688645543

From serb at openjdk.org  Wed Dec 24 04:52:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 04:52:58 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for
 hotspot in files where it was missed
In-Reply-To: <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
 <fJphLNivQT6v7aoC5o_wJqSbuRoZi7iBLlUmpD_B5cw=.eeed052d-b98e-4f5d-a3cf-3d516c3fad96@github.com>
Message-ID: <dBKMWCvfk1bUy0aCWJ7d6myTtQOQyg-kxA0whhThdYA=.e3f0e2a9-3f30-42ef-a48a-320f7308a133@github.com>

On Wed, 24 Dec 2025 04:32:25 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> There are a lot of non-hotspot files in this PR.

Most of them are related and were touched by the same commits pushed to `src/hotspot`.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688672537

From serb at openjdk.org  Wed Dec 24 05:27:56 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 05:27:56 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for
 hotspot in files where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <9cmIm_ANkhZ9knsjEEdCJjy4qJH6TGMFcLoPMS1OVBQ=.53c83270-52bb-4c26-a415-e54a9ed37f56@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I can split out some of these changes into a separate PR to make this one smaller, but I already have a bunch of them =(

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688721427

From serb at openjdk.org  Wed Dec 24 07:51:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 24 Dec 2025 07:51:02 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 java.base in files where it was missed
Message-ID: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>

This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

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

Commit messages:
 - 8374327: Update copyright year to 2025 for java.base in files where it was missed

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

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

From jdv at openjdk.org  Wed Dec 24 08:31:00 2025
From: jdv at openjdk.org (Jayathirth D V)
Date: Wed, 24 Dec 2025 08:31:00 GMT
Subject: <i18n dev> RFR: 8374310: Update copyright year to 2025 for
 client-libs in files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <yoD7DIfGGzKhyS6B6RrPYG5jmlziZ5nIUmuSEIyE3iQ=.1997dd66-2eac-4c4e-ad7e-a984feed9ade@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

Marked as reviewed by jdv (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28969#pullrequestreview-3610289018

From aivanov at openjdk.org  Wed Dec 24 16:33:18 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 24 Dec 2025 16:33:18 GMT
Subject: <i18n dev> RFR: 8374310: Update copyright year to 2025 for
 client-libs in files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <01H0rRIxetr3wciX_EjSows7a0tPIRV6Y1pNUAdwr5E=.65aa9657-d2de-4f8c-a0e2-c0747efd6fc1@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28969#pullrequestreview-3611328977

From serb at openjdk.org  Thu Dec 25 01:29:08 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Thu, 25 Dec 2025 01:29:08 GMT
Subject: <i18n dev> Integrated: 8374310: Update copyright year to 2025 for
 client-libs in files where it was missed
In-Reply-To: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
References: <Olbh-jqCDSQjNclJ8O-lLn2gSzJXlnFQNpn4i7jJwKE=.d81ffd4f-e887-49e9-b2ba-5c66021d5b7d@github.com>
Message-ID: <qUFZkKRYr5XML0dkWvfcOBcrNQLEOsKaYqkPWRW1Shk=.0e821234-aa50-4963-8bbe-4c370afb2e89@github.com>

On Tue, 23 Dec 2025 22:47:39 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in client-area files updated in 2025 has been bumped to 2025.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
> `

This pull request has now been integrated.

Changeset: 73a8629c
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/73a8629c5b52b678febcc9d339e01ebcc5277909
Stats:     565 lines in 565 files changed: 0 ins; 0 del; 565 mod

8374310: Update copyright year to 2025 for client-libs in files where it was missed

Reviewed-by: jdv, aivanov

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

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

From serb at openjdk.org  Fri Dec 26 03:18:25 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 26 Dec 2025 03:18:25 GMT
Subject: <i18n dev> RFR: 8374365: Update copyright year to 2025 for test/jdk
 in files where it was missed
Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>

The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.

**Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

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

Commit messages:
 - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed

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

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

From phh at openjdk.org  Fri Dec 26 22:58:54 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Fri, 26 Dec 2025 22:58:54 GMT
Subject: <i18n dev> RFR: 8374365: Update copyright year to 2025 for
 test/jdk in files where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <I5ZJ3nhBTqj0rD4QaUxGPGkj7aymTjxki7HTtFrWCe8=.bd5028e4-e007-4dfe-8374-f2eb986cdc8a@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by phh (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569

From serb at openjdk.org  Sat Dec 27 07:07:04 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:07:04 GMT
Subject: <i18n dev> Integrated: 8374365: Update copyright year to 2025 for
 test/jdk in files where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <OVIzxn5wdIZIwLEH1aV5QOpA42bscvlkBnTJnCGxPcI=.1bf256e0-07ec-44a3-9090-79c3dad941e7@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 9512a43e
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92
Stats:     76 lines in 76 files changed: 0 ins; 0 del; 76 mod

8374365: Update copyright year to 2025 for test/jdk in files where it was missed

Reviewed-by: phh

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

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

From serb at openjdk.org  Sat Dec 27 07:30:59 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:30:59 GMT
Subject: <i18n dev> RFR: 8374365: Update copyright year to 2025 for
 test/jdk in files where it was missed
In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com>
Message-ID: <xzvWxS1jF-8teyOrN4Mwd2J8Ws63QJ524glMUW_wQZg=.2db4c8bb-d713-4dbc-90c4-96fe8128c732@github.com>

On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs.
> 
> **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137

From serb at openjdk.org  Sat Dec 27 07:40:58 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 07:40:58 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for
 hotspot in files where it was missed
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <weXDVzJ1NVeizP0nigye-yZwlOeGsXCvbYkOWOYffho=.8f7c44b3-def1-45c4-9cf7-e403355361a2@github.com>

On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately.

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

PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693798808

From serb at openjdk.org  Sat Dec 27 08:27:48 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Sat, 27 Dec 2025 08:27:48 GMT
Subject: <i18n dev> RFR: 8374316: Update copyright year to 2025 for
 hotspot in files where it was missed [v2]
In-Reply-To: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
References: <CRaBsrU3e-SWVyt7X3XsijXOqMXpRDIu8pWfr8wWkKk=.484c00ff-8601-4aeb-a599-4f10dd77303c@github.com>
Message-ID: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com>

> The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.)
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Sergey Bylokhov has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision:

  8374316: Update copyright year to 2025 for hotspot in files where it was missed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/28970/files
  - new: https://git.openjdk.org/jdk/pull/28970/files/e4855247..12ba39f6

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

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

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

From serb at openjdk.org  Tue Dec 30 20:18:34 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 20:18:34 GMT
Subject: <i18n dev> RFR: 8374391: Update the copyright year to 2025 in the
 remaining files under src/ where it was missed
Message-ID: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>

The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.

The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:

`git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

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

Commit messages:
 - 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

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

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

From serb at openjdk.org  Tue Dec 30 23:09:05 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Tue, 30 Dec 2025 23:09:05 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <cqf84TZVx1mruyXhcN3crmtIc4F0IK0HcvfHQz9c0ME=.603afa1d-0604-4f8a-9bc1-916939f1ebc1@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Looking for volunteers to review this patch. It cannot be integrated in 2026.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700774950

From liach at openjdk.org  Wed Dec 31 00:20:54 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 31 Dec 2025 00:20:54 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <WwEN8oclANNU5RqNuIdrIxmPJfNsWJ5PZrusKeIOMtc=.c8eddcd4-edd3-4d62-82cb-1db496ac9ced@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700907244

From serb at openjdk.org  Wed Dec 31 00:52:02 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 00:52:02 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <WwEN8oclANNU5RqNuIdrIxmPJfNsWJ5PZrusKeIOMtc=.c8eddcd4-edd3-4d62-82cb-1db496ac9ced@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
 <WwEN8oclANNU5RqNuIdrIxmPJfNsWJ5PZrusKeIOMtc=.c8eddcd4-edd3-4d62-82cb-1db496ac9ced@github.com>
Message-ID: <DH6Re_mkG25xTuvjOMcF2JmhDCYginmZ-2vJJMZj_Ag=.b3651e71-fe2b-4e95-9d10-0fb7d0d77d60@github.com>

On Wed, 31 Dec 2025 00:18:14 GMT, Chen Liang <liach at openjdk.org> wrote:

> Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future.

Yeah, usually [magicus](https://github.com/openjdk/jdk/pull/22642) updates those files, but for some reason this year updates were missing, so I decided to pick them up.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700942964

From jpai at openjdk.org  Wed Dec 31 01:32:52 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Dec 2025 01:32:52 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <ECiTSQOFFjDBi0nLUlKmZ2z1H396-O_JkJG9jiEpwVM=.d68e063e-4cee-4cea-8188-6d124244028d@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Hello Sergey,

> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
>
> git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done 

What is that command expected to return as output? I ran that on top of this PR and I don't see any output. It completes normally without any error. I'm on macos.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701057533

From jpai at openjdk.org  Wed Dec 31 01:49:51 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Dec 2025 01:49:51 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <1W3A16ibXOMrTbXRCkTywPfLx2l0Lm9Pxe2_aJft9Zc=.95756c42-e9a3-498e-b99c-7111af17b18b@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Looking at some other similar PRs that were open, I even tried the following command that was noted in one of them:


git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done

Even this one doesn't generate any output for me.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701127162

From serb at openjdk.org  Wed Dec 31 02:16:01 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 02:16:01 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <N6vhkI8UpDQLAGObtwc-fyjiuv3FIvK6LKEtl58woiY=.091a2181-109a-4621-ac81-1b77bd34fa07@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

`git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

The first command checks the files changed in the last commit of the PR and verifies whether each file has any commit history since January 1, 2025. If not, it prints "NOT IN 2025".

`git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done
`
The disadvantage of the first command is that it depends on a specific commit. The second command avoids this by comparing the current PR against master and using that diff as the list of changed files.

To test the second command, modify and commit a file in the PR branch that has not been modified in 2025. The script will flag it as "NOT IN 2025", because this PR is expected to change only files that already have commits on master in 2025.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701263133

From jpai at openjdk.org  Wed Dec 31 04:41:57 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 31 Dec 2025 04:41:57 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <L8lKaXxaVZCEsGPydf7O5ncdiVBf3NgaMQS0fvK68sQ=.3e3d52e0-fe3f-49d1-9058-c124e38391a6@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

Marked as reviewed by jpai (Reviewer).

Thank you for that detail, I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. The changes look good to me.

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

PR Review: https://git.openjdk.org/jdk/pull/28980#pullrequestreview-3620237303
PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701430051

From serb at openjdk.org  Wed Dec 31 09:17:07 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 09:17:07 GMT
Subject: <i18n dev> Integrated: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
Message-ID: <lkY986uvBl8LVksKCkJxC1bNkKb8NmNtzl73F64NRLE=.b49c79a4-fe3f-4a19-9b38-5b6edfad13a7@github.com>

On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done `

This pull request has now been integrated.

Changeset: 36d2c277
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/36d2c277c47767ba22208e2e49c46001642bd4f5
Stats:     80 lines in 80 files changed: 0 ins; 0 del; 80 mod

8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025

Reviewed-by: jpai

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

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

From alanb at openjdk.org  Wed Dec 31 09:25:13 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Dec 2025 09:25:13 GMT
Subject: <i18n dev> RFR: 8374327: Update copyright year to 2025 for
 files in java.base added/updated by commits in 2025
In-Reply-To: <L8lKaXxaVZCEsGPydf7O5ncdiVBf3NgaMQS0fvK68sQ=.3e3d52e0-fe3f-49d1-9058-c124e38391a6@github.com>
References: <Bza4yWa950eXwHsyd4Zg0K3299ujKHS7-dTP6Kd3WXc=.5c3dad5d-7d03-4a61-ae24-3c5d5d37eb5f@github.com>
 <L8lKaXxaVZCEsGPydf7O5ncdiVBf3NgaMQS0fvK68sQ=.3e3d52e0-fe3f-49d1-9058-c124e38391a6@github.com>
Message-ID: <_66pqVpeNUXYUPpnX4X56yihxoBpaIll4RdsJAUCSGo=.6b4217ed-c69a-4738-a719-3860c0ec212e@github.com>

On Wed, 31 Dec 2025 04:38:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. 

There's a handful of files that were last updated in Dec 2024 via PRs that were in progress at the time. The "/integrate" happened in early Jan 2025 so it looks like the files were updated in 2025. Probably happens every year.

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

PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701814018

From aivanov at openjdk.org  Wed Dec 31 15:35:53 2025
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 31 Dec 2025 15:35:53 GMT
Subject: <i18n dev> RFR: 8374391: Update the copyright year to 2025 in
 the remaining files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <qgHsAf6PG9vbKvWMtLS8qMjDZaiHK38XZseoMcctP1s=.af0a3852-bbf5-43cf-b615-5188ce2a29e0@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/29008#pullrequestreview-3621060611

From serb at openjdk.org  Wed Dec 31 17:20:09 2025
From: serb at openjdk.org (Sergey Bylokhov)
Date: Wed, 31 Dec 2025 17:20:09 GMT
Subject: <i18n dev> Integrated: 8374391: Update the copyright year to 2025
 in the remaining files under src/ where it was missed
In-Reply-To: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
References: <uo9SySuolbGqoeXPL8th0_bBaRt17Ux1fc0Y8NmkTeg=.623cb46e-973a-4715-b468-7a2dfe22c73e@github.com>
Message-ID: <F4AV_5qECl59yK4xOpwJv_zZJNk6uucZ2aQ1a8KRTrQ=.bf5679eb-75e2-474d-ad7a-8858342202b2@github.com>

On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:

> The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year.
> 
> The next command can be run (on top of this PR) to verify that each file had prior commits in 2025:
> 
> `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done`

This pull request has now been integrated.

Changeset: 2d1be8a9
Author:    Sergey Bylokhov <serb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f
Stats:     89 lines in 89 files changed: 0 ins; 0 del; 89 mod

8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed

Reviewed-by: aivanov

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

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