never change

{@snippet lang=java :

 and  are unnecessary, @snippet handles the formatting.

src/java.base/share/classes/java/lang/String.java line 2445:

> 2443:      * {@code compareToIgnoreCase}.
> 2444:      * For example:
> 2445:      * {@snippet lang=java :

 and  are redundant and should be removed.  @snippet handles all the formatting.

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

PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3500569860
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556436806
PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2556430920

From jlu at openjdk.org  Mon Nov 24 21:25:09 2025
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 24 Nov 2025 21:25:09 GMT
Subject:  Integrated: 8368001:
 java/text/Format/NumberFormat/NumberRoundTrip.java timed out
In-Reply-To: 
References: 
Message-ID: <7_obcIOpQ_NcANkYryTmj9TsYahuluoMPa4RwmI8r04=.77cecfa4-d60a-4f60-b608-b6776980825e@github.com>

On Thu, 20 Nov 2025 22:55:41 GMT, Justin Lu  wrote:

> JDK-8260555 exposed test/jdk/java/text/Format/NumberFormat/NumberRoundTrip.java as being susceptible to timeouts.
> While the timeout factor is reverted, this test was testing too many inputs, and should be changed. 
> Originally, it was testing (~1000 locales * 4 factories) against ~30 numeric inputs. The test does not need to be exhaustive to this degree.
> 
> The total amount of locales is changed to sample around a 1/4 of those provided by the provider. The numeric inputs are reduced to about ~20. (The fixed ones remain, and the random ones are cut in half.)
> 
> Locally, I observe average execution for this test to be about ~1.3 seconds, compared to ~3.4 seconds previously. The PR also does a drive-by clean up of the test, i.e. getting rid of the unnecessary escaping + string manipulation/printing and separating the test inputs from the actual testing work done.

This pull request has now been integrated.

Changeset: 507a6d32
Author:    Justin Lu 
URL:       https://git.openjdk.org/jdk/commit/507a6d327f1c613a130273727ee4154b5b4d7ca4
Stats:     230 lines in 1 file changed: 60 ins; 132 del; 38 mod

8368001: java/text/Format/NumberFormat/NumberRoundTrip.java timed out

Reviewed-by: naoto

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

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

From swen at openjdk.org  Tue Nov 25 06:32:34 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:34 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance
Message-ID: 

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%

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

Commit messages:
 - bug fix, form @liach
 - use EnumMap
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/28471/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8372460
  Stats: 153 lines in 5 files changed: 149 ins; 0 del; 4 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 liach at openjdk.org  Tue Nov 25 06:32:36 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 25 Nov 2025 06:32:36 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance
In-Reply-To: 
References: 
Message-ID: 

On Mon, 24 Nov 2025 08:02:35 GMT, Shaojin Wen  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%

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java line 2593:

> 2591:             for (DateTimePrinterParser pp : printerParsers) {
> 2592:                 if ((pp instanceof NumberPrinterParser    npp && !(npp.field instanceof ChronoField))
> 2593:                  || (pp instanceof CompositePrinterParser cpp && !cpp.onlyChronoField())) {

Missing check for `TextPrinterParser`

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

> 132:         if (onlyChronoField) {
> 133:             return new HashMap<>();
> 134:         } else {

Is this condition inverted :thinking: seems like it but how do you get the performance numbers

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

PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3502735627
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2558118611
PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2558120676

From swen at openjdk.org  Tue Nov 25 06:32:37 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:37 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance
In-Reply-To: 
References: 
Message-ID: <-1FtUeUFm9JM8dRl4kyOMwYASWBnVxKgAvLZclN480Q=.13cac2c7-f9b7-4397-8415-1a7fb3aec078@github.com>

On Mon, 24 Nov 2025 08:02:35 GMT, Shaojin Wen  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%

# 1. Shell
We run the following Shell command

# master
git checkout b6495573e9dc5470df268b63f8e7a93f38406cd2
make test TEST="micro:java.time.format.DateTimeFormatterParse"

# this pr
git checkout d8742d7514abfe0e36f105fa7310fdb1755ae546
make test TEST="micro:java.time.format.DateTimeFormatterParse"

# 2. Raw Benchmark Data

Performance data running on a MacBook M1 Pro:

# b649557 (master)
Benchmark                                           Mode  Cnt     Score     Error   Units
DateTimeFormatterParse.parseInstant                thrpt   15  2066.130 ? 126.134  ops/ms
DateTimeFormatterParse.parseLocalDate              thrpt   15  5014.987 ? 424.759  ops/ms
DateTimeFormatterParse.parseLocalDateTime          thrpt   15  3821.083 ? 390.928  ops/ms
DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  3529.090 ? 209.195  ops/ms
DateTimeFormatterParse.parseLocalTime              thrpt   15  4275.904 ? 335.752  ops/ms
DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  4596.255 ? 195.175  ops/ms
DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  2330.924 ? 152.061  ops/ms
DateTimeFormatterParse.parseZonedDateTime          thrpt   15  1837.753 ? 107.873  ops/ms

# d8742d7 (this pr)
Benchmark                                           Mode  Cnt     Score     Error   Units
DateTimeFormatterParse.parseInstant                thrpt   15  2900.168 ?  56.079  ops/ms
DateTimeFormatterParse.parseLocalDate              thrpt   15  9787.592 ? 384.437  ops/ms
DateTimeFormatterParse.parseLocalDateTime          thrpt   15  5046.838 ? 271.451  ops/ms
DateTimeFormatterParse.parseLocalDateTimeWithNano  thrpt   15  3963.050 ? 434.662  ops/ms
DateTimeFormatterParse.parseLocalTime              thrpt   15  8196.707 ? 329.547  ops/ms
DateTimeFormatterParse.parseLocalTimeWithNano      thrpt   15  8387.213 ? 652.292  ops/ms
DateTimeFormatterParse.parseOffsetDateTime         thrpt   15  3291.076 ? 294.889  ops/ms
DateTimeFormatterParse.parseZonedDateTime          thrpt   15  2069.595 ? 293.385  ops/ms

# 3. Performance Comparison

Performance Comparison: b6495573e9dc5470df268b63f8e7a93f38406cd2 vs d8742d7514abfe0e36f105fa7310fdb1755ae546

| Benchmark | b6495573e9dc5470df268b63f8e7a93f38406cd2 | d8742d7514abfe0e36f105fa7310fdb1755ae546 | Improvement Factor |
| --- | --- | --- | --- |
| DateTimeFormatterParse.parseInstant | 2066.130 ? 126.134 | 2900.168 ? 56.079 | 1.404x |
| DateTimeFormatterParse.parseLocalDate | 5014.987 ? 424.759 | 9787.592 ? 384.437 | 1.952x |
| DateTimeFormatterParse.parseLocalDateTime | 3821.083 ? 390.928 | 5046.838 ? 271.451 | 1.321x |
| DateTimeFormatterParse.parseLocalDateTimeWithNano | 3529.090 ? 209.195 | 3963.050 ? 434.662 | 1.123x |
| DateTimeFormatterParse.parseLocalTime | 4275.904 ? 335.752 | 8196.707 ? 329.547 | 1.919x |
| DateTimeFormatterParse.parseLocalTimeWithNano | 4596.255 ? 195.175 | 8387.213 ? 652.292 | 1.825x |
| DateTimeFormatterParse.parseOffsetDateTime | 2330.924 ? 152.061 | 3291.076 ? 294.889 | 1.412x |
| DateTimeFormatterParse.parseZonedDateTime | 1837.753 ? 107.873 | 2069.595 ? 293.385 | 1.126x |

java/time/tck/java/time/temporal/TCKWeekFields.java
java/time/tck/java/time/temporal/TCKIsoFields.java
java/time/tck/java/time/temporal/TCKJulianFields.java
java/time/tck/java/time/format/TCKDateTimeParseResolver.java
java/time/tck/java/time/format/TCKLocalizedFieldParser.java
java/time/tck/java/time/format/TCKDateTimeFormatters.java
java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java

The existing tests above can cover the cases where there are no non-ChronoFields, so no additional tests are needed.

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

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

From swen at openjdk.org  Tue Nov 25 06:32:38 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:32:38 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance
In-Reply-To: 
References: 

Message-ID: 

On Tue, 25 Nov 2025 00:31:27 GMT, Chen Liang  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%
>
> src/java.base/share/classes/java/time/format/Parsed.java line 134:
> 
>> 132:         if (onlyChronoField) {
>> 133:             return new HashMap<>();
>> 134:         } else {
> 
> Is this condition inverted :thinking: seems like it but how do you get the performance numbers

You're right, it's reversed, it's written incorrectly. And this should be in the constructor, not here. The placement is wrong, but it's still using EnumMap, so the performance is still improved.

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

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

From swen at openjdk.org  Tue Nov 25 06:44:57 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 25 Nov 2025 06:44:57 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v2]
In-Reply-To: 
References: 
Message-ID: 

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

  copyright

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

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

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

  Stats: 3 lines in 2 files changed: 1 ins; 0 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 sherman at openjdk.org  Tue Nov 25 20:21:26 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 25 Nov 2025 20:21:26 GMT
Subject:  RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>
Message-ID: 

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

Xueming Shen has updated the pull request incrementally with one additional commit since the last revision:

  minor doc formatting update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27628/files
  - new: https://git.openjdk.org/jdk/pull/27628/files/0aafb674..e5da752f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27628&range=09-10

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

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

From rriggs at openjdk.org  Tue Nov 25 21:13:15 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:13:15 GMT
Subject:  RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>

Message-ID: <-caDaiJwJQ_T1kM5_TjsEe8HsNj40wfIparhZaLfZa4=.8c0248ea-04e7-42d3-bb7f-0f811d8d2813@github.com>

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen  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 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

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

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

From rriggs at openjdk.org  Tue Nov 25 21:31:38 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 25 Nov 2025 21:31:38 GMT
Subject:  RFR: 8365675: Add String Unicode Case-Folding
 Support [v11]
In-Reply-To: 
References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com>

Message-ID: 

On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen  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 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

Try again for information on the issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/27628#issuecomment-3577662129

From jlu at openjdk.org  Wed Nov 26 18:40:58 2025
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 26 Nov 2025 18:40:58 GMT
Subject:  RFR: 8372609: Bug4944439 does not enforce locale
 correctly
Message-ID: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com>

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

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Wed Nov 26 18:44:53 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 26 Nov 2025 18:44:53 GMT
Subject:  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: <-s62C3uRO9LEkSPJAuFU6TFWjS1QPET7MYOajC2sVvs=.23b92f93-7012-4f76-ae06-5e6d8373ba23@github.com>

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu  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).

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/28514#pullrequestreview-3512304444

From jpai at openjdk.org  Thu Nov 27 02:06:46 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 27 Nov 2025 02:06:46 GMT
Subject:  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: 

On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu  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?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28514#pullrequestreview-3513312964

From liach at openjdk.org  Sun Nov 30 05:36:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Sun, 30 Nov 2025 05:36:47 GMT
Subject:  RFR: 8372460: Use EnumMap instead of HashMap for
 DateTimeFormatter parsing to improve performance [v2]
In-Reply-To: 
References: 

Message-ID: <-M2fXk0-NVQKUcMw8Wyx0ENjNr3584l41Bwa3tv-bW8=.ad669cec-e0a1-442a-ba93-6ccf729b7ed5@github.com>

On Tue, 25 Nov 2025 06:44:57 GMT, Shaojin Wen  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:
> 
>   copyright

I think instead of checking each component printer parser, we should check the public methods on `DateTimeFormatterBuilder` that can take a `TemporalField` and track the `onlyChronoField` there.

This is better because this is where users can actaully pass in non-ChronoField. For example, I last time discovered text printer parser, and now have discovered DefaultValueParser is problematic too.

So I believe guarding where users can pass custom TemporalField and adding a boolean field on a DateTimeFormatterBuilder to keep track of this is better.

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

Changes requested by liach (Reviewer).

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

Composing lazy constants