From jlu at openjdk.org  Fri Mar  1 01:05:14 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Mar 2024 01:05:14 GMT
Subject: <i18n dev> RFR: JDK-6801704: ChoiceFormat::applyPattern
 inconsistency for invalid patterns [v6]
In-Reply-To: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
References: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
Message-ID: <MKdVlFyU_07-a02drAMj08IKnUfVgmSTIa5xmPQUbAA=.f9e92e83-2319-47f3-9531-7a2dcb0d1350@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

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

  wording: punctuation and use 'constructor'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17856/files
  - new: https://git.openjdk.org/jdk/pull/17856/files/8e5bbe05..aa1071e2

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

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

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

From naoto at openjdk.org  Fri Mar  1 18:55:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Mar 2024 18:55:21 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v10]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <dnSrOIX0FJCxNVB_9S8lj9x4mMvAEd4BBc4pVt1s-Vw=.caf7a418-2238-48b8-aef0-c5cf70b0cee1@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  Removed the gc test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/7c1ca90e..84f5f692

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

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

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

From naoto at openjdk.org  Fri Mar  1 21:32:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Mar 2024 21:32:29 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v11]
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

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

  copyright year revert

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14404/files
  - new: https://git.openjdk.org/jdk/pull/14404/files/84f5f692..41150e12

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

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

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

From rriggs at openjdk.org  Fri Mar  1 21:32:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Mar 2024 21:32:29 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale [v11]
In-Reply-To: <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <eUCMcXPPY9mk5ttu2aLB_KX6W35EuB5hQkeg4BTiF3A=.05bfb1c9-057d-424a-aadb-5f7f324da8aa@github.com>
Message-ID: <6BjJBX0Aw_PoVS-TuUlaaQxtdj2CELy2w9q_eSu8v94=.de3fe830-b0a6-4c48-a28a-0239bb3a0a05@github.com>

On Fri, 1 Mar 2024 21:29:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
>> 
>> (w/o fix)
>> 
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
>> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
>> 
>> (w/ fix)
>> Benchmark                       Mode  Cnt      Score     Error  Units
>> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
>> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyright year revert

Much simpler and looks good.  Thanks

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14404#pullrequestreview-1912051206

From jlu at openjdk.org  Sat Mar  2 00:39:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 2 Mar 2024 00:39:19 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
Message-ID: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>

Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.

The cause is that the maximum fraction digits is initialized to `Integer.MAX_VALUE` which causes StringBuilder to eventually throw OOME when internally doubling capacity too many times when toPattern is invoked. CSR covers potential behavioral compatibility changes.

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

Commit messages:
 - minor additions
 - init

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

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

From rgiulietti at openjdk.org  Sat Mar  2 14:28:42 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Sat, 2 Mar 2024 14:28:42 GMT
Subject: <i18n dev> RFR: 8326718: Test java/util/Formatter/Padding.java
 should timeout on large inputs before fix in JDK-8299677 [v2]
In-Reply-To: <kLxU3DOdW6K7xh94umCx03Emvc682CU6H337aAPTRPM=.3181ec15-fe16-4462-a9cc-686c238638dc@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
 <kLxU3DOdW6K7xh94umCx03Emvc682CU6H337aAPTRPM=.3181ec15-fe16-4462-a9cc-686c238638dc@github.com>
Message-ID: <d2H-p0REtceYAfDjiaHKBY9FsXJcwSGuaBMfhm6yk0U=.6c8526ff-7bae-43ab-a381-00ce44973931@github.com>

On Wed, 28 Feb 2024 00:00:01 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
>> 
>> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Test updates

test/jdk/java/util/Formatter/Padding.java line 44:

> 42: 
> 43:     private static final String tenMillionZeros = "0".repeat(10000000);
> 44:     private static final String tenMillionBlanks = " ".repeat(10000000);

Just a nit to help readability
Suggestion:

    private static final String tenMillionZeros = "0".repeat(10_000_000);
    private static final String tenMillionBlanks = " ".repeat(10_000_000);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18033#discussion_r1509251657

From gli at openjdk.org  Sun Mar  3 05:02:51 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Sun, 3 Mar 2024 05:02:51 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs.

It seems a bug in `toPattern` or `StringBuilder`? May be better to investigate more about it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1975023075

From rriggs at openjdk.org  Mon Mar  4 16:06:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 4 Mar 2024 16:06:53 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

src/java.base/share/classes/java/text/DecimalFormat.java line 3717:

> 3715:             // As maxFracDigits are fully displayed unlike maxIntDigits
> 3716:             // Prevent OOME by setting to a much more reasonable value.
> 3717:             setMaximumFractionDigits(DOUBLE_FRACTION_DIGITS);

Setting a reasonable default makes sense.  
In other control paths, the max fraction digits come from the inputs or are explicitly set.

It might be a reasonable related change to use StringBuilder.repeat() instead of a loop at LIne 3312-3319, where the pattern char(s) are being appended to the result.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1511404338

From naoto at openjdk.org  Mon Mar  4 18:44:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Mar 2024 18:44:00 GMT
Subject: <i18n dev> Integrated: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
Message-ID: <DNuZkLuJKs8zHctNbprC3qzanXQOGofv1F3MpG4GuKI=.f60e36c3-5457-4fad-bace-95e7bb2a2f38@github.com>

On Fri, 9 Jun 2023 22:17:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is stemming from the PR: https://github.com/openjdk/jdk/pull/14211 where aggressive GC can cause NPE in `BaseLocale$Key` class. I refactored the in-house cache with WeakHashMap, and removed the Key class as it is no longer needed (thus the original NPE will no longer be possible). Also with the new JMH test case, it gains some performance improvement:
> 
> (w/o fix)
> 
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   5781.275 ? 569.580  ns/op
> LocaleCache.testLocaleOf        avgt   20  62564.079 ? 406.697  ns/op
> 
> (w/ fix)
> Benchmark                       Mode  Cnt      Score     Error  Units
> LocaleCache.testForLanguageTag  avgt   20   4801.175 ? 371.830  ns/op
> LocaleCache.testLocaleOf        avgt   20  60394.652 ? 352.471  ns/op

This pull request has now been integrated.

Changeset: f615ac4b
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f615ac4bdf94750390d18aa954d41f72eb4ef4d2
Stats:     437 lines in 4 files changed: 43 ins; 267 del; 127 mod

8309622: Re-examine the cache mechanism in BaseLocale

Reviewed-by: dfuchs, rriggs

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

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

From naoto at openjdk.org  Mon Mar  4 19:07:44 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Mar 2024 19:07:44 GMT
Subject: <i18n dev> RFR: 8174269: Remove COMPAT locale data provider
 from JDK [v6]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

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 44 additional commits since the last revision:

 - Merge branch 'master' into JDK-8174269-COMPAT-Removal
 - Addressing review comments
 - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
   
   Co-authored-by: Justin Lu <Justin.lu at oracle.com>
 - Remove `GensrcLocaleData.gmk`
 - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - cleanup
 - BreakIteratorProvider available locales fix
 - clean-up
 - test fixes
 - makeZoneData.pl fix
 - ... and 34 more: https://git.openjdk.org/jdk/compare/fe877cfd...b771e303

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/d5953788..b771e303

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

  Stats: 19239 lines in 1290 files changed: 10762 ins; 3853 del; 4624 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

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

From duke at openjdk.org  Mon Mar  4 21:42:52 2024
From: duke at openjdk.org (Raju Gupta)
Date: Mon, 4 Mar 2024 21:42:52 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <zYA3R0Eg2eU70YtWCregenTvT8UQkjbHHOB03W7vWjM=.ed96e265-7688-4f95-897f-52481c88ea49@github.com>

On Sat, 2 Mar 2024 00:34:32 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

Would declaring an object for the input and then invoking the two methods on the same object rather than creating two objects be considered an alternative?

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

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

PR Review: https://git.openjdk.org/jdk/pull/18094#pullrequestreview-1915406613

From jlu at openjdk.org  Tue Mar  5 00:32:47 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:47 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v2]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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

 - cleanup/typo
 - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
 - implement feedback + improve pattern related tests
 - minor additions
 - init

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/fc8a7ce4..7ca56500

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

  Stats: 5885 lines in 919 files changed: 2483 ins; 1248 del; 2154 mod
  Patch: https://git.openjdk.org/jdk/pull/18094.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18094/head:pull/18094

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

From jlu at openjdk.org  Tue Mar  5 00:32:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:48 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
Message-ID: <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>

On Sun, 3 Mar 2024 05:00:36 GMT, Guoxiong Li <gli at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
>> When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs.
> 
> It seems a bug in `toPattern` or `StringBuilder`? May be better to investigate more about it.

Hi @lgxbslgx,

For clarification, this is entirely a bug with DecimalFormat, not StringBuilder. An empty String pattern DecimalFormat sets the maximum fraction digits to `Integer.MAX_VALUE`. When toPattern() is invoked, the local StringBuilder will append until an OOME is thrown by the StringBuilder as there is not enough memory, when internally, the buffer is doubled for a value too large. But such an OOME would occur for any large enough value, so the issue lies with DecimalFormat.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1977712428

From jlu at openjdk.org  Tue Mar  5 00:32:48 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 00:32:48 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v2]
In-Reply-To: <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <ycyUibb8e5NBVff0ftU7WeAhlreWrW0qLIXJu9zbv1E=.d4694e1a-fded-4dfc-a57c-8632590aa8ab@github.com>
Message-ID: <Ltk6S6M2A9oKxGf3dHZUO-SD2LhbcnZm0EcwYVsICmo=.44ba2165-8738-42c4-9b92-3e5dd9edf462@github.com>

On Mon, 4 Mar 2024 16:03:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - cleanup/typo
>>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>>  - implement feedback + improve pattern related tests
>>  - minor additions
>>  - init
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 3717:
> 
>> 3715:             // As maxFracDigits are fully displayed unlike maxIntDigits
>> 3716:             // Prevent OOME by setting to a much more reasonable value.
>> 3717:             setMaximumFractionDigits(DOUBLE_FRACTION_DIGITS);
> 
> Setting a reasonable default makes sense.  
> In other control paths, the max fraction digits come from the inputs or are explicitly set.
> 
> It might be a reasonable related change to use StringBuilder.repeat() instead of a loop at LIne 3312-3319, where the pattern char(s) are being appended to the result.

Thanks for taking a look. Updated the loop with `repeat` as you suggested, and decided to refactor the rest of the method while I was at it.

Additionally, I added some more tests, as it seems that there is a lack of pattern tests for DecimalFormat in general.

> In other control paths, the max fraction digits come from the inputs or are explicitly set.

Right, while `Integer.MAX_VALUE` can still be set by other control paths (and thus an OOME if toPattern() is invoked), this is something explicitly done by the user, and thus we decided we would still allow the behavior.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1511966791

From joehw at openjdk.org  Tue Mar  5 06:52:54 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Mar 2024 06:52:54 GMT
Subject: <i18n dev> RFR: 8174269: Remove COMPAT locale data provider
 from JDK [v6]
In-Reply-To: <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
Message-ID: <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>

On Mon, 4 Mar 2024 19:07:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> 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 44 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8174269-COMPAT-Removal
>  - Addressing review comments
>  - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
>    
>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>  - Remove `GensrcLocaleData.gmk`
>  - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - cleanup
>  - BreakIteratorProvider available locales fix
>  - clean-up
>  - test fixes
>  - makeZoneData.pl fix
>  - ... and 34 more: https://git.openjdk.org/jdk/compare/9da59104...b771e303

LGTM. This is a lot of work. Looking through the files alone takes hours. Kudos to the great work!

I kind of like some of the date formats in COMPACT to be honest :-)

make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1320:

> 1318:      * "US<NBSP>dst" -> "D"
> 1319:      *
> 1320:      * `tzdbLinks` retains `Link`s of time zones. if the value

nit, "if the value" seems to be an unfinished sentence.

src/java.base/share/classes/sun/util/locale/provider/BaseLocaleDataMetaInfo.java line 31:

> 29:  * It is used to avoid loading non-existent localized resources so that
> 30:  * jar files won't be opened unnecessary to look up them.
> 31:  */

nit: move the class description to right above the class? "unnecessary" -> "unnecessarily"

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1915980264
PR Comment: https://git.openjdk.org/jdk/pull/17991#issuecomment-1978071713
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1512206671
PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1512207766

From gli at openjdk.org  Tue Mar  5 11:56:45 2024
From: gli at openjdk.org (Guoxiong Li)
Date: Tue, 5 Mar 2024 11:56:45 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <opssWK17CH7cXcdSq6M7Qxjux4xlIlNcujGIgH-wZkU=.9d26b388-a23d-477c-b185-1dc85f3e3a23@github.com>
 <3hQuEgs2G2EaqOYtju-thoLE36yjHCkj_fgYSEPBB24=.819fbdde-471c-49f5-822a-3c49cc7f4d50@github.com>
Message-ID: <FgItzEBaBwqeuTcueenqJHMyPOUTBTn3SZfNM1XWr_c=.aa28b7e9-4d35-4d2e-b8f5-3e490311cfcd@github.com>

On Tue, 5 Mar 2024 00:15:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> For clarification, this is entirely a bug with DecimalFormat, not StringBuilder. An empty String pattern DecimalFormat sets the maximum fraction digits to Integer.MAX_VALUE. When toPattern() is invoked, the local StringBuilder will append until an OOME is thrown by the StringBuilder as there is not enough memory, when internally, the buffer is doubled for a value too large. But such an OOME would occur for any large enough value, so the issue lies with DecimalFormat.

Got it. Thanks for your explanation.

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

PR Comment: https://git.openjdk.org/jdk/pull/18094#issuecomment-1978591032

From naoto at openjdk.org  Tue Mar  5 17:50:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:50:09 GMT
Subject: <i18n dev> RFR: 8174269: Remove COMPAT locale data provider
 from JDK [v7]
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

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

  Reflects review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/17991/files
  - new: https://git.openjdk.org/jdk/pull/17991/files/b771e303..78a5130e

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

  Stats: 13 lines in 3 files changed: 5 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/17991.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/17991/head:pull/17991

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

From naoto at openjdk.org  Tue Mar  5 17:50:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 17:50:14 GMT
Subject: <i18n dev> RFR: 8174269: Remove COMPAT locale data provider
 from JDK [v6]
In-Reply-To: <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <T8EvrAU2TaEKGwnqcAv1q3TsREiAFSoblLo-NPRvRBo=.2a7aaa81-da1c-477b-b612-b1cafee8e9d0@github.com>
 <BTe8l5vnvQEU9F1G-g8IeYmEP_GMUHpBK1nqnnrG4Kg=.fcb7149f-f6a0-4773-a182-2f26d7774d8a@github.com>
Message-ID: <XM_GpXkUjbHcbxlbDPL-lrI4oO3s3ZT4npxsZTwyMfs=.ac9e9fb6-f665-423a-9b29-ce3a382b7140@github.com>

On Tue, 5 Mar 2024 06:44:52 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> 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 44 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8174269-COMPAT-Removal
>>  - Addressing review comments
>>  - Update test/jdk/java/text/Format/DateFormat/Bug6683975.java
>>    
>>    Co-authored-by: Justin Lu <Justin.lu at oracle.com>
>>  - Remove `GensrcLocaleData.gmk`
>>  - Update make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java
>>    
>>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>>  - cleanup
>>  - BreakIteratorProvider available locales fix
>>  - clean-up
>>  - test fixes
>>  - makeZoneData.pl fix
>>  - ... and 34 more: https://git.openjdk.org/jdk/compare/7faf5495...b771e303
>
> make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 1320:
> 
>> 1318:      * "US<NBSP>dst" -> "D"
>> 1319:      *
>> 1320:      * `tzdbLinks` retains `Link`s of time zones. if the value
> 
> nit, "if the value" seems to be an unfinished sentence.

Thanks. Not only the sentence, the description itself was unfinished. Corrected.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/17991#discussion_r1513248212

From joehw at openjdk.org  Tue Mar  5 18:42:48 2024
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 5 Mar 2024 18:42:48 GMT
Subject: <i18n dev> RFR: 8174269: Remove COMPAT locale data provider
 from JDK [v7]
In-Reply-To: <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
 <fzGtSyEbpU0QGOK-minXRamVv9EWt5L_qLYuAPcThF0=.65bc53ce-4cf0-4d5a-96f5-9a2980fddda9@github.com>
Message-ID: <7C49Hs0D7ZXRz5sn63NdYDO4Hh3VSQpukJoFj0M7CTQ=.011b6a93-ec7b-4475-8950-4d85f39641a1@github.com>

On Tue, 5 Mar 2024 17:50:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/17991#pullrequestreview-1917852026

From naoto at openjdk.org  Tue Mar  5 19:26:47 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 19:26:47 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v2]
In-Reply-To: <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
Message-ID: <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>

On Tue, 5 Mar 2024 00:32:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - cleanup/typo
>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>  - implement feedback + improve pattern related tests
>  - minor additions
>  - init

src/java.base/share/classes/java/text/DecimalFormat.java line 3367:

> 3365:             }
> 3366:         }
> 3367:         return false;

can simply be a single return statement.

test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:

> 58:         dFmt.setMinimumFractionDigits(minFrac);
> 59: 
> 60:         String[] patterns = dFmt.toPattern().split("\\.");

Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.

test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 110:

> 108:     // 8326908: Verify that an empty pattern DecimalFormat does not throw an
> 109:     // OutOfMemoryError when toPattern() is invoked. Behavioral change of
> 110:     // MAXIMUM_INTEGER_DIGITS replaced with DOUBLE_FRACTION_DIGITS for empty

Should we explicitly check `new DecimalFormat("").getMaximumFractionDigits() == DOUBLE_FRACTION_DIGITS`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513356393
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513364152
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513378668

From naoto at openjdk.org  Tue Mar  5 19:34:54 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 19:34:54 GMT
Subject: <i18n dev> Integrated: 8174269: Remove COMPAT locale data provider
 from JDK
In-Reply-To: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
References: <XNQIVyE7hhaSZ-1WYKTId7-Jd1D8_zzaJ5uTlXtlKY0=.e9ac4371-1c6a-4bc1-9382-d26b9ffd7f1e@github.com>
Message-ID: <vOXZQwyVBubfdf7g8HPAAfNdF_-x-jHlPFtsTkSUPcM=.0b74ef70-2017-42ae-9b89-6dd22dfc1fb2@github.com>

On Fri, 23 Feb 2024 21:24:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR intends to remove the legacy `COMPAT` locale data from the JDK. The `COMPAT` locale data was introduced for applications' migratory purposes transitioning to `CLDR`. It is becoming a technical debt and now is the time to remove it (we've been emitting a warning at JVM startup since JDK21, if the app is using `COMPAT`). A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 809995b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/809995b526ea79e4fd9fd4f911bcce811f77eb89
Stats:     67953 lines in 568 files changed: 483 ins; 66704 del; 766 mod

8174269: Remove COMPAT locale data provider from JDK

Reviewed-by: ihse, joehw

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

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

From jlu at openjdk.org  Tue Mar  5 21:27:09 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:27:09 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v3]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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

  reflect review

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/7ca56500..7ee87fc2

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

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

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

From jlu at openjdk.org  Tue Mar  5 21:27:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:27:11 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v2]
In-Reply-To: <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
 <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
Message-ID: <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>

On Tue, 5 Mar 2024 19:10:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - cleanup/typo
>>  - Merge branch 'master' into JDK-8326908-emptyPattern-OOME
>>  - implement feedback + improve pattern related tests
>>  - minor additions
>>  - init
>
> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:
> 
>> 58:         dFmt.setMinimumFractionDigits(minFrac);
>> 59: 
>> 60:         String[] patterns = dFmt.toPattern().split("\\.");
> 
> Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.

Actually, since `toPattern()` is non-localized, it will always use "." as specified by DecimalFormat.

I removed the misleading comment `// Use a US dFmt, which uses '.' as the decimal separator` that indicated we needed to use a DecimalFormatSymbols where "." was the decimal separator. Can just simply use a DecimalFormat returned by the default constructor.

> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 110:
> 
>> 108:     // 8326908: Verify that an empty pattern DecimalFormat does not throw an
>> 109:     // OutOfMemoryError when toPattern() is invoked. Behavioral change of
>> 110:     // MAXIMUM_INTEGER_DIGITS replaced with DOUBLE_FRACTION_DIGITS for empty
> 
> Should we explicitly check `new DecimalFormat("").getMaximumFractionDigits() == DOUBLE_FRACTION_DIGITS`?

Thanks for the review, added an explicit check

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513517348
PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513517336

From naoto at openjdk.org  Tue Mar  5 21:41:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v2]
In-Reply-To: <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <q8ezC_57Gv8P98pwv-kTZdPQmumaUn4Rziot93ZnfT0=.edb542c3-7399-4f06-bba3-b5f0313dc6d6@github.com>
 <c2AryhpH3YNSYzCF7XBwoDw8yicqKlfyqd9OzOSYGi8=.827f0d55-fc2d-42e1-a68c-abd71394f03a@github.com>
 <VLbpgbwApZG30uaGComVDznk1UBO2oBP8f9WLIPiE4g=.54cc3c91-fb93-4329-bc1e-fe0486df1810@github.com>
Message-ID: <crRbTXX92VunbgijX8whMkOOlh2l6cxSIlgBYnjKU50=.071a7221-e405-474a-8751-3bf964d1bcea@github.com>

On Tue, 5 Mar 2024 21:23:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/text/Format/DecimalFormat/ToPatternTest.java line 60:
>> 
>>> 58:         dFmt.setMinimumFractionDigits(minFrac);
>>> 59: 
>>> 60:         String[] patterns = dFmt.toPattern().split("\\.");
>> 
>> Instead of assuming/hardcoding the decimal separator, `DecimalFormatSymbols.getInstance(Locale.US).getDecimalSeparator()` may be better.
>
> Actually, since `toPattern()` is non-localized, it will always use "." as specified by DecimalFormat.
> 
> I removed the misleading comment `// Use a US dFmt, which uses '.' as the decimal separator` that indicated we needed to use a DecimalFormatSymbols where "." was the decimal separator. Can just simply use a DecimalFormat returned by the default constructor.

Oh right. Yes, so we should not use the US locale for this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18094#discussion_r1513526760

From jlu at openjdk.org  Tue Mar  5 21:41:00 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v4]
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <ZCLWqqwlkQs7AknGn-Uux6ql1dsQ84SCqo8OAB-mIxo=.a6beba47-957d-4800-bce0-21008dc04594@github.com>

> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
> 
> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.

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

  locale no longer needed, remove unusued imports

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18094/files
  - new: https://git.openjdk.org/jdk/pull/18094/files/7ee87fc2..e9e86da7

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

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

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

From naoto at openjdk.org  Tue Mar  5 21:41:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Mar 2024 21:41:00 GMT
Subject: <i18n dev> RFR: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string [v3]
In-Reply-To: <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
 <8YD325UqNtT5sDADtJBwWalIvH2VPqcXeCZcF17igyw=.f429c7da-fcd9-4661-ba58-fec5e1b3b519@github.com>
Message-ID: <nIuki7as8gNR5RFJNLbxe8-1equa0E87H2RTSi5kC8U=.c0a6007a-59e8-4a79-93a3-084e4301327a@github.com>

On Tue, 5 Mar 2024 21:27:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which prevents an OutOfMemoryError by restricting the initial maximum fraction digits for an empty pattern DecimalFormat.
>> 
>> For an empty String pattern DecimalFormat, the maximum fraction digits is initialized to `Integer.MAX_VALUE`. When toPattern() is invoked, StringBuilder internally doubles capacity attempting to append Integer.MAX_VALUE digits until OOME occurs. CSR covers potential behavioral compatibility changes.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18094#pullrequestreview-1918175848

From jlu at openjdk.org  Tue Mar  5 22:40:51 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 5 Mar 2024 22:40:51 GMT
Subject: <i18n dev> Integrated: JDK-6801704: ChoiceFormat::applyPattern
 inconsistency for invalid patterns
In-Reply-To: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
References: <S0h5X3J918JmJvvNLa3VVAo_p0JZGgqD6PemhQ_W_pc=.49ebe3b9-5f80-4523-9a31-deed19cde778@github.com>
Message-ID: <ySLrxpNMgno7Pjy-dbWQVuCHf5Y9giMgIuZDXJ5ylOg=.f98bcccc-2ef5-4725-8eb0-6955eec7f81f@github.com>

On Wed, 14 Feb 2024 22:29:07 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8317756) which defines the behavior for creating ChoiceFormats with incorrect patterns. The wording is added to both the ChoiceFormat constructor and ChoiceFormat::applyPattern method.
> 
> While ideally the inconsistent behavior itself could be fixed, this behavior has been long-standing for 20+ years and the benefit of consistent error handling does not outweigh the risk of breaking applications that may be relying on the "expected" incorrect behavior.
> 
> Examples of the range of behavior, (all examples violate the pattern syntax defined in the class description)
> 
> 
> // no limit -> throws an expected IllegalArgumentException
> var a = new ChoiceFormat("#foo");
> // no limit or relation in the last subPattern -> discards the incorrect portion, 'baz' and continues
> var b = new ChoiceFormat("0#foo|1#bar|baz"); 
> b.format(2); // returns 'bar'
> // no relation or limit -> discards the incorrect portion, 'foo' and continues
> var c = new ChoiceFormat("foo");
> c.format(1); // throws AIOOBE

This pull request has now been integrated.

Changeset: b665fe3a
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b665fe3ac10f4e85b91737228780b1d50ae81514
Stats:     21 lines in 1 file changed: 13 ins; 0 del; 8 mod

6801704: ChoiceFormat::applyPattern inconsistency for invalid patterns

Reviewed-by: naoto

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

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

From duke at openjdk.org  Tue Mar  5 23:00:16 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Tue, 5 Mar 2024 23:00:16 GMT
Subject: <i18n dev> RFR: 8326718: Test java/util/Formatter/Padding.java
 should timeout on large inputs before fix in JDK-8299677 [v3]
In-Reply-To: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
Message-ID: <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>

> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
> 
> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.

Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:

  Add underscores to large number

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18033/files
  - new: https://git.openjdk.org/jdk/pull/18033/files/45d0acdd..2e24a459

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

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

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

From rgiulietti at openjdk.org  Wed Mar  6 15:58:51 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 6 Mar 2024 15:58:51 GMT
Subject: <i18n dev> RFR: 8326718: Test java/util/Formatter/Padding.java
 should timeout on large inputs before fix in JDK-8299677 [v3]
In-Reply-To: <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
 <nmdhjce7rqWQBMCyNhCt8vIs6kbKRuk-2ITlOC3DTiA=.b7dd99c3-ee5b-41e0-98aa-22d447e7fa16@github.com>
Message-ID: <VCn3qKPNqTwDduo_deEj0VtBqz3YxgdO2vNFqdlQLWQ=.26e61c5b-0d6c-43f9-b3df-99a2c0cbebb3@github.com>

On Tue, 5 Mar 2024 23:00:16 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

>> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
>> 
>> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.
>
> Chad Rakoczy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add underscores to large number

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18033#pullrequestreview-1920152315

From duke at openjdk.org  Wed Mar  6 19:57:49 2024
From: duke at openjdk.org (Chad Rakoczy)
Date: Wed, 6 Mar 2024 19:57:49 GMT
Subject: <i18n dev> Integrated: 8326718: Test
 java/util/Formatter/Padding.java should timeout on large inputs before fix
 in JDK-8299677
In-Reply-To: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
References: <VZRVXk6F4GWkDmWCwKs6PB98VB3DMGk1vsMAWlw-u4U=.b794825b-886d-4cd4-85f2-f827b8d486b6@github.com>
Message-ID: <v6gDQQG1UmXirs58KvQDPmkCxI3VefuPha50bGvAc6w=.8ac46d2f-610e-422a-b7c1-c09dde1be112@github.com>

On Tue, 27 Feb 2024 17:24:03 GMT, Chad Rakoczy <duke at openjdk.org> wrote:

> [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) fixes a bug with Formatter.format taking a long time when there is a lot of padding. This test runs Formatter.format with very large padding. Test fails before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677) and passes after.
> 
> Timeout for the test was set to 10 seconds. Test passes locally with as low as 1 (after [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) and fails as high as 120 (before [JDK-8299677](https://bugs.openjdk.java.net/browse/JDK-8299677)) so it should be consistent.

This pull request has now been integrated.

Changeset: 4f336085
Author:    Chad Rakoczy <chadrako at amazon.com>
Committer: Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4f336085d1098e7fba7b58f0a73c028179a2a13d
Stats:     41 lines in 1 file changed: 39 ins; 0 del; 2 mod

8326718: Test java/util/Formatter/Padding.java should timeout on large inputs before fix in JDK-8299677

Reviewed-by: rgiulietti

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

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

From naoto at openjdk.org  Wed Mar  6 21:37:00 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 6 Mar 2024 21:37:00 GMT
Subject: <i18n dev> RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
Message-ID: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>

Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

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

Commit messages:
 - initial commit

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

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

From jlu at openjdk.org  Wed Mar  6 23:06:51 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 6 Mar 2024 23:06:51 GMT
Subject: <i18n dev> RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <Aq7Q9WbtpSA9f4t1QAAc2rMhxut3PKQ3PJBzGu-kV1s=.25f65a9f-7bc0-4bfd-868c-fe9bf714570b@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Solution makes sense, LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921004473

From rriggs at openjdk.org  Wed Mar  6 23:10:53 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 6 Mar 2024 23:10:53 GMT
Subject: <i18n dev> RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <fORsWZE79weq74parUVApKm4kKMSqfuXj-35S3x1lCs=.adec313c-bae3-466a-9d1a-17415f6e4658@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Looks good; will save a lot of of CI time and still cover the cases.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921008397

From iris at openjdk.org  Wed Mar  6 23:39:54 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 6 Mar 2024 23:39:54 GMT
Subject: <i18n dev> RFR: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <333BLYvYF_WIN_sYOxnxVpqcSYjgvigSL-8iG5qfjbk=.40deba36-4111-4b8d-925e-b6b4d31c095b@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18143#pullrequestreview-1921039503

From naoto at openjdk.org  Thu Mar  7 00:54:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Mar 2024 00:54:57 GMT
Subject: <i18n dev> Integrated: 8327434: Test
 java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out
In-Reply-To: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
References: <0Riep9P5PEosfKdfJ7s-cublbckfoyyp0FWNcNPz4is=.77d25a24-1ae5-4d4c-baee-852b2d7cdb23@github.com>
Message-ID: <xxi5VGZa8qUDHK8oOk97fz7MzIl7LZ8Nj6AHc4Pvfeg=.b156cfb6-4639-4b27-9c7a-0f3401bcb2e5@github.com>

On Wed, 6 Mar 2024 21:32:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing timeout failures in the test case. Time zone names that are missing (chiefly for minor locales) are now calculated at runtime after the fix to JDK-8174269. This extra calculation time was multiplied in the test case as it iterated over all locales x timezones, which caused timeouts in some configurations. Changed the test case to not iterate all locales, but iterate over relevant ones.

This pull request has now been integrated.

Changeset: 1bd4abf9
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bd4abf98e26d04076f330c0b2e44f666f8c27a1
Stats:     6 lines in 1 file changed: 2 ins; 1 del; 3 mod

8327434: Test java/util/PluggableLocale/TimeZoneNameProviderTest.java timed out

Reviewed-by: jlu, rriggs, iris

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

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

From naoto at openjdk.org  Thu Mar  7 19:32:03 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Mar 2024 19:32:03 GMT
Subject: <i18n dev> RFR: 8327167: Add add() example for Leap Day in
 Calendar's doc
Message-ID: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>

A simple doc update to include a leap day example in the `Calendar` class.

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

Commit messages:
 - initial commit

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

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

From bpb at openjdk.org  Thu Mar  7 21:11:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Mar 2024 21:11:52 GMT
Subject: <i18n dev> RFR: 8327167: Add add() example for Leap Day in
 Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <LE5lVn6-15Hity9enQTP7JI7Y9sV8w8txglwk4aXaXI=.49a1142d-48a3-4a69-a558-47735a35aa4b@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Looks good.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923550002

From joehw at openjdk.org  Thu Mar  7 21:14:54 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 7 Mar 2024 21:14:54 GMT
Subject: <i18n dev> RFR: 8327167: Add add() example for Leap Day in
 Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <1he6cAEu-i3EueuYlMMLLf6hIFmO5mmtRVS0WMYKmvQ=.44a8ecae-9f42-4920-82fd-7bc74766b96a@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923559732

From lancea at openjdk.org  Thu Mar  7 21:23:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 7 Mar 2024 21:23:55 GMT
Subject: <i18n dev> RFR: 8327167: Add add() example for Leap Day in
 Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <40T77DVsSyHvCqXBmem6pDOZBtM8UUTLrnDaCJg-hiM=.877db9ce-a53b-4c88-b37d-080c5085fbcb@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923575615

From jlu at openjdk.org  Thu Mar  7 21:39:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Mar 2024 21:39:52 GMT
Subject: <i18n dev> RFR: 8327167: Add an example for Leap Day in
 Calendar's doc
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <eg-nuzP7O1vUAa9aCqXqCv2rf7P3a4aUyCz-i3XvV1g=.2beca255-2e22-4904-95d5-5ea961d2a62f@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923601796

From jlu at openjdk.org  Thu Mar  7 23:36:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 7 Mar 2024 23:36:01 GMT
Subject: <i18n dev> RFR: JDK-8327631: Update IANA Language Subtag Registry
 to Version 2024-03-07
Message-ID: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>

Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.

Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

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

Commit messages:
 - init

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

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

From iris at openjdk.org  Fri Mar  8 00:59:53 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Mar 2024 00:59:53 GMT
Subject: <i18n dev> RFR: 8327167: Clarify the handling of Leap year by
 Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <Cm_KCTXzp7-bByXrrTaT5gU2-NNsYGHTbCrXtCG1VEY=.b5e5b300-c40b-45c5-a887-213df680ef4c@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1923843891

From rriggs at openjdk.org  Fri Mar  8 16:24:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 8 Mar 2024 16:24:54 GMT
Subject: <i18n dev> RFR: 8327167: Clarify the handling of Leap year by
 Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <dzOd5VGA78g9IcyXEjdSUFc3xQNlW-3Pambi7Wzr9H8=.61ec14c9-3ede-46aa-90e7-6cbfd55d4331@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18158#pullrequestreview-1925260836

From jlu at openjdk.org  Fri Mar  8 18:12:59 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 8 Mar 2024 18:12:59 GMT
Subject: <i18n dev> Integrated: JDK-8326908: DecimalFormat::toPattern throws
 OutOfMemoryError when pattern is empty string
In-Reply-To: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
References: <yYh4g-z3irMpiUoJXZwl_1RHAfNI5iLgpYAmN7xysKs=.e00b1990-cb8b-444e-9b3d-15e1c66d0dd2@github.com>
Message-ID: <biBtM98scIiA0Z9M2-krpwdAQkhuWspHwgmNAq1UGWc=.04e35c6e-55e2-46b4-9c74-20b4a7dbafc7@github.com>

An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20240308/ac458786/attachment.htm>

From naoto at openjdk.org  Fri Mar  8 18:40:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 18:40:56 GMT
Subject: <i18n dev> Integrated: 8327167: Clarify the handling of Leap year
 by Calendar
In-Reply-To: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
References: <WykpKf2FV7ao9r1IqqbD52UeCbEc33LaWsvgDMFIbKc=.1fa3315e-d513-4c7c-9db0-a1ee9624f00f@github.com>
Message-ID: <kMsHLW9U50TvfeEQpHYcRqBmZgbHuTz5vumMcKTPn40=.8cc13ffc-8c35-409a-9e31-81dceb19f30e@github.com>

On Thu, 7 Mar 2024 19:28:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A simple doc update to include a leap day example in the `Calendar` class.

This pull request has now been integrated.

Changeset: 87b40c6a
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87b40c6ad2b0fa972fa6c5699a52045e82e0c7ef
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8327167: Clarify the handling of Leap year by Calendar

Reviewed-by: bpb, joehw, lancea, jlu, iris, rriggs

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

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

From naoto at openjdk.org  Fri Mar  8 19:42:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Mar 2024 19:42:52 GMT
Subject: <i18n dev> RFR: JDK-8327631: Update IANA Language Subtag
 Registry to Version 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <z1YqqfDbtobaAHQz6Ii0VvvitHNqMVRMuDFMY1T5pVQ=.d047c2b9-f4ac-447f-9197-76ab8b1fe820@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18159#pullrequestreview-1925720318

From iris at openjdk.org  Fri Mar  8 20:56:53 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Mar 2024 20:56:53 GMT
Subject: <i18n dev> RFR: JDK-8327631: Update IANA Language Subtag
 Registry to Version 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <wZ_QGetglDBuwFkHrmeBKu_vxvbF3QbjgIZA3sumbX8=.959667a3-c6c5-454c-93f9-3476f501e749@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18159#pullrequestreview-1925817696

From duke at openjdk.org  Mon Mar 11 16:41:03 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 11 Mar 2024 16:41:03 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset related
 methods added in Java 10
Message-ID: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>

# Issue
- JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10

I changed the @\since tags to better accurately show when the methods and constructors were introduced.

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

Commit messages:
 - fixed @ since tag for Formatter.java class Constructors
 - fixed @ since tag for Channels.java class newWriter and newReader methods

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

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

From job at kimmeringer.de  Tue Mar 12 14:20:42 2024
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Tue, 12 Mar 2024 15:20:42 +0100
Subject: <i18n dev> Calendar.set(Calendar.DAY_OF_WEEK,
 ...) changes times as well
Message-ID: <42bcc6fd-ded8-4b6a-a6fa-d8f557e6ce4f@kimmeringer.de>

Hello,

this might be Dunning Kruger at play (at least my Imposter Syndrom
tells me it is ;-) but I think I've found a bug in Calendar, when
working with a different timezonethan the default one.

Attached you can find my test case that is showing the effect but
it breaks down to the following:

         Calendar cal = Calendar.getInstance();
         cal.setTimeInMillis(1709269200000L); // March 01 2024 06:00:00 CET
         cal.setTimeZone(TimeZone.getTimeZone(TIMEZONE));
         assertEquals("Fri Mar 01 06:00:00 CET 2024", cal.getTime().toString(), "check date before change");
         cal.set(Calendar.DAY_OF_WEEK, Calendar.MONDAY);
         assertEquals("Mon Feb 26 06:00:00 CET 2024", cal.getTime().toString(), "check date after change");

If TIMEZONE is the system's default, the test goes through, if it differs,
the offset time is added to the resulting date after setting the day of
the week. With Europe/Berlin (+0100 at that date) as default and
America/New_York (-0500 at that date) as the timezone being set to the
Calendar, the result is Mon Feb 26 12:00:00 CET 2024 (previous time plus
+1 minus -5).

The workaround for this is using Calendar.add instead of set:

         cal.add(Calendar.DAY_OF_YEAR, -(cal.get(Calendar.DAY_OF_WEEK) - Calendar.MONDAY));

sets the day to monday without changes to the time.

Tested with

  - Java 8.0.312_win_x64
  - Java 11.0.20.1_win_x64
  - Java 17.0.7_win_x64
  - Java 21.0.0_win_x64


Thanks and best regards,

Lothar Kimmeringer
-------------- next part --------------
import static org.junit.jupiter.api.Assertions.*;

import java.util.Calendar;
import java.util.Locale;
import java.util.TimeZone;

import org.junit.jupiter.api.AfterEach;
import org.junit.jupiter.api.BeforeEach;
import org.junit.jupiter.api.Test;

class __Test_CalendarSetWeekday {
    
    private Locale defaultLocale;
    private TimeZone defaultTimeZone;

    @BeforeEach
    public void setup() {
        defaultLocale = Locale.getDefault();
        defaultTimeZone = TimeZone.getDefault();
        TimeZone.setDefault(TimeZone.getTimeZone("Europe/Berlin"));
    }
    
    @AfterEach
    public void tearDown() {
        Locale.setDefault(defaultLocale);
        TimeZone.setDefault(defaultTimeZone);
    }
    
    @Test
    void testCalAddingBerlinVsNewYork() {
        Calendar cal = Calendar.getInstance();
        cal.setTimeInMillis(1709269200000L); // March 01 2024
        cal.setTimeZone(TimeZone.getTimeZone("America/New_York"));
        assertEquals("Fri Mar 01 06:00:00 CET 2024", cal.getTime().toString(), "check date before change");
        cal.set(Calendar.DAY_OF_WEEK, Calendar.MONDAY);
        assertEquals("Mon Feb 26 06:00:00 CET 2024", cal.getTime().toString(), "check date after change");
    }
    
    @Test
    void testCalAddingBerlinVsBerlin() {
        Calendar cal = Calendar.getInstance();
        cal.setTimeInMillis(1709269200000L); // March 01 2024 06:00:00 CET
        cal.setTimeZone(TimeZone.getTimeZone("Europe/Berlin"));
        assertEquals("Fri Mar 01 06:00:00 CET 2024", cal.getTime().toString(), "check date before change");
        cal.set(Calendar.DAY_OF_WEEK, Calendar.MONDAY);
        assertEquals("Mon Feb 26 06:00:00 CET 2024", cal.getTime().toString(), "check date after change");
    }
    
    
}

From naoto.sato at oracle.com  Tue Mar 12 18:04:46 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 12 Mar 2024 11:04:46 -0700
Subject: <i18n dev> Calendar.set(Calendar.DAY_OF_WEEK,
 ...) changes times as well
In-Reply-To: <42bcc6fd-ded8-4b6a-a6fa-d8f557e6ce4f@kimmeringer.de>
References: <42bcc6fd-ded8-4b6a-a6fa-d8f557e6ce4f@kimmeringer.de>
Message-ID: <22a895cf-a24d-4d32-a5e1-823697ab3fce@oracle.com>

Hi Lothar,

The behavior is the long standing one: 
https://bugs.openjdk.org/browse/JDK-7055392, and probably not being 
fixed for the compatibility reasons. A workaround would be to issue 
cal.get(Calendar.DAY_OF_WEEK) just after the call to cal.setTimeZone(). 
That will re-calculate fields after the time zone is set.

HTH,
Naoto

On 3/12/24 7:20 AM, Lothar Kimmeringer wrote:
> Hello,
> 
> this might be Dunning Kruger at play (at least my Imposter Syndrom
> tells me it is ;-) but I think I've found a bug in Calendar, when
> working with a different timezonethan the default one.
> 
> Attached you can find my test case that is showing the effect but
> it breaks down to the following:
> 
>  ??????? Calendar cal = Calendar.getInstance();
>  ??????? cal.setTimeInMillis(1709269200000L); // March 01 2024 06:00:00 CET
>  ??????? cal.setTimeZone(TimeZone.getTimeZone(TIMEZONE));
>  ??????? assertEquals("Fri Mar 01 06:00:00 CET 2024", 
> cal.getTime().toString(), "check date before change");
>  ??????? cal.set(Calendar.DAY_OF_WEEK, Calendar.MONDAY);
>  ??????? assertEquals("Mon Feb 26 06:00:00 CET 2024", 
> cal.getTime().toString(), "check date after change");
> 
> If TIMEZONE is the system's default, the test goes through, if it differs,
> the offset time is added to the resulting date after setting the day of
> the week. With Europe/Berlin (+0100 at that date) as default and
> America/New_York (-0500 at that date) as the timezone being set to the
> Calendar, the result is Mon Feb 26 12:00:00 CET 2024 (previous time plus
> +1 minus -5).
> 
> The workaround for this is using Calendar.add instead of set:
> 
>  ??????? cal.add(Calendar.DAY_OF_YEAR, -(cal.get(Calendar.DAY_OF_WEEK) - 
> Calendar.MONDAY));
> 
> sets the day to monday without changes to the time.
> 
> Tested with
> 
>  ?- Java 8.0.312_win_x64
>  ?- Java 11.0.20.1_win_x64
>  ?- Java 17.0.7_win_x64
>  ?- Java 21.0.0_win_x64
> 
> 
> Thanks and best regards,
> 
> Lothar Kimmeringer

From jlu at openjdk.org  Tue Mar 12 21:13:16 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 12 Mar 2024 21:13:16 GMT
Subject: <i18n dev> Integrated: JDK-8327631: Update IANA Language Subtag
 Registry to Version 2024-03-07
In-Reply-To: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
References: <V4ZSXBRMDNCFzwss6q5W_LVLGaD49oQ9lhpkX7zqjt8=.9f7c9f50-8888-4c44-955a-63f41d9cd030@github.com>
Message-ID: <BsNZ4j_kpOR2XNMpELOxrjOR1SzqNnypgzNEEF8YYBM=.b41379b7-6a7e-4d10-8de5-49c0898ae85f@github.com>

On Thu, 7 Mar 2024 23:31:46 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a trivial update to the IANA sub tag registry to version 2024-03-07. Tests pass as expected after update.
> 
> Associated announcement -> https://mm.icann.org/pipermail/ietf-languages-announcements/2024-March/000090.html

This pull request has now been integrated.

Changeset: d5b95a0e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5b95a0ed38b10ed9f51d20255e06eb38fdd8b82
Stats:     80 lines in 2 files changed: 77 ins; 0 del; 3 mod

8327631: Update IANA Language Subtag Registry to Version 2024-03-07

Reviewed-by: naoto, iris

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

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

From clanger at openjdk.org  Wed Mar 13 07:58:20 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 07:58:20 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java has
 unnecessary high heap requirement after JDK-8326718
Message-ID: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>

4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.

In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.

I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

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

Commit messages:
 - JDK-8328037

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

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

From rgiulietti at openjdk.org  Wed Mar 13 09:45:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 09:45:13 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

What about factoring out the 4 invocations of `tenMillionBlanks()` in each source method in a local var?

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1993965369

From rgiulietti at openjdk.org  Wed Mar 13 13:18:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 13:18:13 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <8i5zAp-P2q5zGVzu2j2sTitj_IEUC0QWMVxWiEniE3U=.25880fe6-5555-448d-b1b7-cae193352156@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

L.26-27 to

 * @bug 4906370 8299677 8326718 8328037
 * @summary Tests to exercise padding on int and double values,

test/jdk/java/util/Formatter/Padding.java line 43:

> 41: public class Padding {
> 42: 
> 43:     private static final String tenMillionZeros() {

Suggestion:

    private static String tenMillionZeros() {

test/jdk/java/util/Formatter/Padding.java line 46:

> 44:         return "0".repeat(10_000_000);
> 45:     }
> 46:     private static final String tenMillionBlanks() {

Suggestion:

    private static String tenMillionBlanks() {

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994382507
PR Review Comment: https://git.openjdk.org/jdk/pull/18264#discussion_r1523241759
PR Review Comment: https://git.openjdk.org/jdk/pull/18264#discussion_r1523241920

From clanger at openjdk.org  Wed Mar 13 14:10:29 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 14:10:29 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Generate large strings in parameter generator methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18264/files
  - new: https://git.openjdk.org/jdk/pull/18264/files/8e3e9509..be84e5e8

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

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

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

From clanger at openjdk.org  Wed Mar 13 14:13:12 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 14:13:12 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718
In-Reply-To: <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <dqf1lgTC6CTTs67zMD83XpoLFCxbsXKMdM_bS-vQn4A=.1c7dd6ba-88d6-49dd-b9a3-ee401f543973@github.com>
Message-ID: <_GU6KezLJckwYdT1YS6-5SldXcDwyDZDD9U1fCkQ6M0=.0edcd83b-1ada-4410-ad9b-58bdc11534dd@github.com>

On Wed, 13 Mar 2024 09:42:34 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> What about factoring out the 4 invocations of `tenMillionBlanks()` in each source method in a local var?

OK, I inlined the generation of the ten million character strings into the parameter generator methods. I looked a bit at the test runtime and it seems like it doesn't make a lot of difference in a test JVM with larger heap but for smaller test VMs it seems to improve things.

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994497012

From rgiulietti at openjdk.org  Wed Mar 13 14:25:13 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Mar 2024 14:25:13 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
Message-ID: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>

On Wed, 13 Mar 2024 14:10:29 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
>> 
>> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
>> 
>> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Generate large strings in parameter generator methods

I was thinking more something like

        var tenMillionBlanks = tenMillionBlanks();

and similarly for `tenMillionsZeros`, thus maintaining the `private static` (but not `final` ;-) ) methods as in your previous commit.
But if you are happy with the last commit, it's OK as well.

Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?

Otherwise looks fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1994522269

From clanger at openjdk.org  Wed Mar 13 21:07:54 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 21:07:54 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v3]
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18264/files
  - new: https://git.openjdk.org/jdk/pull/18264/files/be84e5e8..ca3ec0d5

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

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

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

From clanger at openjdk.org  Wed Mar 13 21:07:55 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Wed, 13 Mar 2024 21:07:55 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
 <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
Message-ID: <Bi2BI0CY9keENBJVDtRW_XjOZ5cAH7oRoO87akCpuz4=.d012ec06-bbb5-44db-9b19-9ab3737d8fc1@github.com>

On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?

Done.

I kept the tenMillion... handling.

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1995807615

From rgiulietti at openjdk.org  Thu Mar 14 10:33:44 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 14 Mar 2024 10:33:44 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v3]
In-Reply-To: <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <c7AjuntbLje8ElfRXnM6beeEqXmfRAPhbsLqMPcdhQg=.b2686d32-54f6-4db9-8671-6e4e40c0f8eb@github.com>
Message-ID: <xOTW_0PlpFULbYkhsBpMVkV8fw1MjwIJV1RWey8-TKE=.8498acbf-d63f-4cc2-af82-100488b91029@github.com>

On Wed, 13 Mar 2024 21:07:54 GMT, Christoph Langer <clanger at openjdk.org> wrote:

>> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
>> 
>> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
>> 
>> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`
>
> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions

Marked as reviewed by rgiulietti (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18264#pullrequestreview-1936282689

From clanger at openjdk.org  Fri Mar 15 06:44:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 06:44:42 GMT
Subject: <i18n dev> RFR: 8328037: Test java/util/Formatter/Padding.java
 has unnecessary high heap requirement after JDK-8326718 [v2]
In-Reply-To: <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
 <rK4kQL8x2zB8ZJC045nbJNCGaxYeONaiks8t90680kk=.192da756-f3f5-458e-8aea-22222c916091@github.com>
 <J2YRJbV0eJHwdkIR-2Vh4zc6An8vyz34j5QzzeyIKH4=.60cff437-d27f-4899-857f-7df7d5adc9b3@github.com>
Message-ID: <ISXiplfASW3-h_sNJnJvxXE2EoxNlnfjRU9zPm_gEfc=.1f8c9e2a-5cd0-4fa0-95c7-b856230eabe3@github.com>

On Wed, 13 Mar 2024 14:23:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Christoph Langer has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Generate large strings in parameter generator methods
>
> I was thinking more something like
> 
>         var tenMillionBlanks = tenMillionBlanks();
> 
> and similarly for `tenMillionsZeros`, thus maintaining the `private static` (but not `final` ;-) ) methods as in your previous commit.
> But if you are happy with the last commit, it's OK as well.
> 
> Can you please add the bug id to `@bug` and correct the typo, as suggested [here](https://github.com/openjdk/jdk/pull/18264#issuecomment-1994382507)?
> 
> Otherwise looks fine.

Thanks, @rgiulietti for reviewing this.

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

PR Comment: https://git.openjdk.org/jdk/pull/18264#issuecomment-1999033956

From clanger at openjdk.org  Fri Mar 15 06:44:42 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 15 Mar 2024 06:44:42 GMT
Subject: <i18n dev> Integrated: 8328037: Test
 java/util/Formatter/Padding.java has unnecessary high heap requirement
 after JDK-8326718
In-Reply-To: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
References: <nfx8v4WDi39WkxM2xY32q0oI93f13Z9HSDdeO7WD1PM=.9bdc1b9f-2612-4a39-8290-b633eead6638@github.com>
Message-ID: <Zdts3gVXfAX1LBJ09-41hqcb1LQEeyQ6nkICxVH7mZM=.5f79d47f-e0c3-4ee9-a702-0fc558eb5a3f@github.com>

On Wed, 13 Mar 2024 07:53:30 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> 4f336085d1098e7fba7b58f0a73c028179a2a13d ([JDK-8326718](https://bugs.openjdk.org/browse/JDK-8326718)) added a few cases to test java/util/Formatter/Padding.java with huge Strings as arguments. Since all possible argument combinations for the test are stored in one array, nothing can be garbage collected while the test is running and the heap requirement is blown up.
> 
> In one of our test pipelines we run tier1 tests with VMs that default to 384M of heap and this is not sufficient any longer.
> 
> I'm improving this by splitting the one large @ParameterizedTest into multiple ones. With that, I could run the test successfully in a test VM with 96M of heap, e.g. by modifying `@run junit Padding` to `@run junit/othervm -Xmx96m Padding`

This pull request has now been integrated.

Changeset: 128e60a2
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/128e60a29f1bd1e1fbe165ac382107070858ecc6
Stats:     650 lines in 1 file changed: 343 ins; 269 del; 38 mod

8328037: Test java/util/Formatter/Padding.java has unnecessary high heap requirement after JDK-8326718

Reviewed-by: rgiulietti

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

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

From duke at openjdk.org  Sun Mar 17 18:31:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 18:31:50 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v2]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <KuFvmtJkJrOnOmzcc5kjHbajtkzMNKQnHpperfTK9LI=.c22ef053-17ec-4ec8-8465-29b8c8eb5ef9@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  fixed @ since tag for Channels.java class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8a829541..e80f99e1

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

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

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

From duke at openjdk.org  Sun Mar 17 23:40:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 23:40:50 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v3]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <bAIsgoT0mopCkvsLbpjKe8PxLNB1v_WojMMuq3k8qyA=.5d13138a-1369-4640-a123-8ecf125c65ef@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - fixed a mistake
 - fixed a mistake

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/e80f99e1..c51f6cb9

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

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

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

From duke at openjdk.org  Sun Mar 17 23:56:48 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Sun, 17 Mar 2024 23:56:48 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v4]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Hzb3BRT3YdYFxjfcEng90akTVQkea995UaZPKD5JrDY=.8d9664c8-b366-478b-9552-536d8eaa761c@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  final version for channels.java - might need to remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/c51f6cb9..8e5a711e

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

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

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

From duke at openjdk.org  Mon Mar 18 00:02:31 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 18 Mar 2024 00:02:31 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v5]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <9z0zSGIWOSNLzbXHUV0EVx88bAPaade33W-lnsPl3UI=.6ee04546-60ec-403b-bba8-2ed647b96876@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  remove whitespace

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8e5a711e..4822dede

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

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

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

From jlu at openjdk.org  Mon Mar 18 06:29:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Mar 2024 06:29:40 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
Message-ID: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>

Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.

The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.

Below is an example of the change, the CSR can be viewed for further detail.


DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
fmt.setLenient(false);
fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
fmt.setGroupingSize(2);
fmt.parse("12,34,567"); // throws ParseException
fmt.setParseIntegerOnly(true)
fmt.parse("12,34.56"); // throws ParseException
fmt.parse("12,34"); // successfully returns the Number 1234


The associated tests are all localized, and the data is converted properly during runtime.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/18339/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18339&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8327640
  Stats: 1199 lines in 6 files changed: 1157 ins; 10 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

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

From duke at openjdk.org  Mon Mar 18 12:44:46 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Mon, 18 Mar 2024 12:44:46 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v6]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  added terminal new line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/4822dede..abc5a6ab

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

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

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

From jlu at openjdk.org  Tue Mar 19 00:07:37 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 00:07:37 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v2]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

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

  Replace protected field with a public getter -> isStrict().
  Replace setLenient() with setStrict() to avoid messy inversion of boolean.
  Add a leniency section to NumberFormat.
  Overhaul of NumberFormat class specification to be much more organized/readable.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/8843c56f..c3a32500

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

  Stats: 208 lines in 5 files changed: 77 ins; 54 del; 77 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

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

From jlu at openjdk.org  Tue Mar 19 00:48:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 00:48:24 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v6]
In-Reply-To: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <XovkM9T-EQ1X2jzj2lvn4IuxeeKVkm6BrBxtqXNBaDE=.e920c3d1-7813-47c0-b32d-0fcb5ffd6a4d@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added terminal new line

The `@since 10` tags look consistent with the JDK release those methods / constructors were introduced in.

Can you update the latter years for the Oracle copyrights only in both these files, thanks.

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

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1944702560

From aturbanov at openjdk.org  Tue Mar 19 08:59:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 19 Mar 2024 08:59:23 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v2]
In-Reply-To: <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
Message-ID: <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>

On Tue, 19 Mar 2024 00:07:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
>> 
>> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
>> 
>> Below is an example of the change, the CSR can be viewed for further detail.
>> 
>> 
>> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
>> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
>> fmt.setLenient(false);
>> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
>> fmt.setGroupingSize(2);
>> fmt.parse("12,34,567"); // throws ParseException
>> fmt.setParseIntegerOnly(true)
>> fmt.parse("12,34.56"); // throws ParseException
>> fmt.parse("12,34"); // successfully returns the Number 1234
>> 
>> 
>> The associated tests are all localized, and the data is converted properly during runtime.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace protected field with a public getter -> isStrict().
>   Replace setLenient() with setStrict() to avoid messy inversion of boolean.
>   Add a leniency section to NumberFormat.
>   Overhaul of NumberFormat class specification to be much more organized/readable.

src/java.base/share/classes/java/text/DecimalFormat.java line 2419:

> 2417:             if (gotPositive) {
> 2418:                 boolean containsPosSuffix =
> 2419:                         text.regionMatches(position, positiveSuffix,0, positiveSuffix.length());

Suggestion:

                        text.regionMatches(position, positiveSuffix, 0, positiveSuffix.length());

src/java.base/share/classes/java/text/DecimalFormat.java line 2426:

> 2424:             if (gotNegative) {
> 2425:                 boolean containsNegSuffix =
> 2426:                         text.regionMatches(position, negativeSuffix,0, negativeSuffix.length());

Suggestion:

                        text.regionMatches(position, negativeSuffix, 0, negativeSuffix.length());

src/java.base/share/classes/java/text/DecimalFormat.java line 2428:

> 2426:                         text.regionMatches(position, negativeSuffix,0, negativeSuffix.length());
> 2427:                 boolean endsWithNegSuffix =
> 2428:                         containsNegSuffix && text.length() == position  + negativeSuffix.length();

Suggestion:

                        containsNegSuffix && text.length() == position + negativeSuffix.length();

src/java.base/share/classes/java/text/DecimalFormat.java line 2482:

> 2480:         // process digits or Inf, find decimal position
> 2481:         status[STATUS_INFINITE] = false;
> 2482:         if (!isExponent && text.regionMatches(position, symbols.getInfinity(),0,

Suggestion:

        if (!isExponent && text.regionMatches(position, symbols.getInfinity(), 0,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965478
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529965780
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966184
PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1529966645

From duke at openjdk.org  Tue Mar 19 10:54:41 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 10:54:41 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v6]
In-Reply-To: <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <Iraa7JaXyKqcMvAnupV-lUr4bNfGS12IBfWiSFHcvJ4=.37245437-b8e8-4797-97bc-f10c3cbe1b9b@github.com>
Message-ID: <AzDSHkHxsYiIZjvEbYs9mOtKyeitmU11N82MEW6miEg=.fc52ea51-7905-4cfd-a8e6-0e50e63493f2@github.com>

On Mon, 18 Mar 2024 12:44:46 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added terminal new line

I have updated them

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

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2006812767

From duke at openjdk.org  Tue Mar 19 10:54:41 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 10:54:41 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v7]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  update the latter years for the Oracle copyrights

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/abc5a6ab..8bcc364f

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

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

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

From jlu at openjdk.org  Tue Mar 19 16:16:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 16:16:24 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v7]
In-Reply-To: <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
Message-ID: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>

On Tue, 19 Mar 2024 10:54:41 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update the latter years for the Oracle copyrights

src/java.base/share/classes/java/nio/channels/Channels.java line 2:

> 1: /*
> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.

Thanks for updating, but needs a little adjustment.

Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
So in this case ->  `2000, 2024,`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530694415

From duke at openjdk.org  Tue Mar 19 17:02:36 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 17:02:36 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>

> # Issue
> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
> 
> I changed the @\since tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - update the copyright year to 2024
 - Revert "update the latter years for the Oracle copyrights"
   
   This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/8bcc364f..56968dcd

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

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

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

From duke at openjdk.org  Tue Mar 19 17:08:23 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 17:08:23 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v7]
In-Reply-To: <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
Message-ID: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>

On Tue, 19 Mar 2024 16:13:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update the latter years for the Oracle copyrights
>
> src/java.base/share/classes/java/nio/channels/Channels.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Thanks for updating, but needs a little adjustment.
> 
> Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
> So in this case ->  `2000, 2024,`

Thanks for the explanation, I have fixed it.
I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530770401

From jlu at openjdk.org  Tue Mar 19 17:23:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 17:23:21 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v7]
In-Reply-To: <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <31WyPy0h58G15W4UL6rodnL76556uCBFJf4KmJCAZvs=.a910caaa-513c-4c04-ad2e-9ff7d6bca022@github.com>
 <5hkFuK2LSLIR907zeic58OFPFPW3egEPTiYrP8CpiE0=.e3359a87-eece-44cd-bc59-98743657455f@github.com>
 <pgb660qilJEEIrWt4c8yDOn1f4Ci3JDjLiaCr0AW-6E=.d2a6a284-b5cc-4508-86b2-cf88b57c9488@github.com>
Message-ID: <Tquf1xKBVkshr66HGgVy9yVpl53oCjPH2KrSQYNq1VM=.e2fd363a-7bab-4f78-923a-6c1a153de746@github.com>

On Tue, 19 Mar 2024 17:05:50 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/channels/Channels.java line 2:
>> 
>>> 1: /*
>>> 2:  * Copyright (c) 2000, 2023, 2024, Oracle and/or its affiliates. All rights reserved.
>> 
>> Thanks for updating, but needs a little adjustment.
>> 
>> Rather than adding a third year, the format should be: "original year, current year, Oracle ..."
>> So in this case ->  `2000, 2024,`
>
> Thanks for the explanation, I have fixed it.
> I have a couple other similar PRs, is the policy to update the copyright year every time a file is changed? whether it's an addition or removal of code?

Yes, you should update the copyright year to the current year if you make a change to the file, regardless if the change itself is "significant" or not.

Note that there are two formats: `Year1, Year2, Oracle` and `Year, Oracle`. The latter would be used if say you added a new file in 2024.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18032#discussion_r1530792055

From jlu at openjdk.org  Tue Mar 19 17:32:21 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Mar 2024 17:32:21 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <GXW2-arZymX_4iLIBbcG608h4-QvxtH8P97lWY-hWeI=.6f57894b-aa5f-423e-b9a9-4f32da6a37a6@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

Change looks good to me, but you will need someone with reviewer status to sponsor your changes before you can integrate them.

BTW, I also added a `noreg-doc` label to your JBS issue, which just means that no tests are needed for this change as it is a documentation only change.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1946933024

From duke at openjdk.org  Tue Mar 19 18:02:21 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 19 Mar 2024 18:02:21 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

Thank you justin

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

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2007813492

From naoto at openjdk.org  Wed Mar 20 17:46:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Mar 2024 17:46:24 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
Message-ID: <pjgeEs6MaHAk8pv0ZGE9VNEZ1XAm0hVfSUb9WcEilFk=.33042064-905e-4e73-b05b-a246fc581908@github.com>

On Tue, 19 Mar 2024 17:02:36 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect @\since Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the @\since tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - update the copyright year to 2024
>  - Revert "update the latter years for the Oracle copyrights"
>    
>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18032#pullrequestreview-1949627443

From duke at openjdk.org  Wed Mar 20 18:04:50 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Wed, 20 Mar 2024 18:04:50 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v9]
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>

> # Issue
> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
> 
> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.

Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:

 - Update full name
 - Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18032/files
  - new: https://git.openjdk.org/jdk/pull/18032/files/56968dcd..99f54fe2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=18032&range=07-08

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

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

From jlu at openjdk.org  Thu Mar 21 16:53:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 16:53:23 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
Message-ID: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>

On Tue, 19 Mar 2024 17:59:48 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - update the copyright year to 2024
>>  - Revert "update the latter years for the Oracle copyrights"
>>    
>>    This reverts commit 8bcc364fef8287c4d9aff7c60ed6fc0ea9155f64.
>
> Thank you justin

Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2012982347

From jlu at openjdk.org  Thu Mar 21 18:12:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 18:12:52 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v3]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <7_mpxWeNVmfq7TzzANs25293m8lD0cmUkT1595MFT1I=.344529c9-6ce2-4ef3-a8aa-d5f6de2131fd@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

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

 - Re-work specification wording from Format down to subclasses
 - implement white space suggestions
 - remove unsupported methods header, should go in JDK-8327875 instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/c3a32500..c09a34dd

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

  Stats: 128 lines in 4 files changed: 21 ins; 64 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

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

From jlu at openjdk.org  Thu Mar 21 18:12:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Mar 2024 18:12:52 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v2]
In-Reply-To: <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
 <rl0Y0vv1IjraFLkn_iIpCIFgk9X4qE08snhdc3AP55s=.d7cf85ca-0b90-4145-9c5b-86dac3bed664@github.com>
 <EvPX2cY93CUliSON9s06Ecx0oqLAidIj1R60PORW5ig=.b58a7655-e11d-4a02-a831-cb85ee8dbaf6@github.com>
Message-ID: <yDGG6eJVLsqQBE9cMZRRWqw-qmlbsRpyBfzXEPvY3mQ=.1f8ba92d-0a4d-41bf-b13b-9238cc8b2800@github.com>

On Tue, 19 Mar 2024 08:56:46 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Replace protected field with a public getter -> isStrict().
>>   Replace setLenient() with setStrict() to avoid messy inversion of boolean.
>>   Add a leniency section to NumberFormat.
>>   Overhaul of NumberFormat class specification to be much more organized/readable.
>
> src/java.base/share/classes/java/text/DecimalFormat.java line 2482:
> 
>> 2480:         // process digits or Inf, find decimal position
>> 2481:         status[STATUS_INFINITE] = false;
>> 2482:         if (!isExponent && text.regionMatches(position, symbols.getInfinity(),0,
> 
> Suggestion:
> 
>         if (!isExponent && text.regionMatches(position, symbols.getInfinity(), 0,

Thanks, this and the other suggestions you provided should be fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18339#discussion_r1534407476

From duke at openjdk.org  Fri Mar 22 10:28:24 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 10:28:24 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @since tags for Charset
 related methods added in Java 10 [v9]
In-Reply-To: <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <_LFnCmIQInkNBTDQq2qhzMEQVvM2OFFA103Ta6XQfLY=.944a1568-15e4-4867-ac91-4687c84f4973@github.com>
Message-ID: <OrMrE0Qq8TigtKpb2SMcyaZ2CXZqfGmpHIW61GkpXOo=.90051740-7358-4dd6-a844-8e375d930d37@github.com>

On Wed, 20 Mar 2024 18:04:50 GMT, Nizar Benalla <duke at openjdk.org> wrote:

>> # Issue
>> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
>> 
>> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.
>
> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update full name
>  - Update full name

I spent some time running some tests to learn the process.

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

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2014786660

From duke at openjdk.org  Fri Mar 22 15:52:28 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 15:52:28 GMT
Subject: <i18n dev> RFR: JDK-8326853 Missing @ since tags for Charset
 related methods added in Java 10 [v8]
In-Reply-To: <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
 <2-WQaDMFndxdiMFRgQzYJv5406TN_hLoKW4n6hfjSPA=.28c6aaca-7a92-409a-aaf7-b9785250df5b@github.com>
 <I5sZ4ot_RfZZsI9Qu2bUgHmpfdbF3ptq5cd971_8suM=.0fc07e54-a842-4a48-9bac-01c001899c13@github.com>
 <ESiMAPbL2cdi6Q_kHy5dg_vYeII27v-2US20oLxMxLY=.bc367e20-affe-4624-a4d4-216042f32d5e@github.com>
Message-ID: <ybe6vfwdT6TWJEIUIvx7aJrcFaEKGNKuoQZZ05Q6k90=.b3b2a78f-80f4-4a4a-9321-42ca44a9eaf2@github.com>

On Thu, 21 Mar 2024 16:50:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Thank you justin
>
> Hi @nizarbenalla , you can comment `/integrate` whenever you're ready, and we can sponsor the change to have it integrated.

@justin-curtis-lu I realized there is a small issue with the commit message

8326853: Missing @since tags for Charset related methods added in Java 10

Reviewed-by: jlu, naoto

there is a github user with the username `@since` and he will be tagged in the commit message, so there should be a space here. I added a space in the PR title

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

PR Comment: https://git.openjdk.org/jdk/pull/18032#issuecomment-2015380584

From duke at openjdk.org  Fri Mar 22 16:14:26 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Fri, 22 Mar 2024 16:14:26 GMT
Subject: <i18n dev> Integrated: JDK-8326853 Missing `@since` tags for
 Charset related methods added in Java 10
In-Reply-To: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
References: <oBavwlRgOstmcNVI8xNYMM6XYybqLMUQqxGt-CL1-cg=.88bca87b-3fd4-4f8a-8794-bf3dd6092680@github.com>
Message-ID: <4cUvcPClyJ-k2flHg2HTAheLLeCUKQsee04x-gQ9B5M=.6eefac93-ca3d-435a-990b-27de51410e3c@github.com>

On Tue, 27 Feb 2024 16:28:26 GMT, Nizar Benalla <duke at openjdk.org> wrote:

> # Issue
> - JDK-8326853 Incorrect `@since` Tags for Charset Related Methods Added in JDK 10
> 
> I changed the `@since` tags to better accurately show when the methods and constructors were introduced.

This pull request has now been integrated.

Changeset: 4d932d61
Author:    Nizar Benalla <nizar.benalla at oracle.com>
Committer: Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4d932d615c78f45516a4f136398e7610546065a6
Stats:     12 lines in 2 files changed: 10 ins; 0 del; 2 mod

8326853: Missing `@since` tags for Charset related methods added in Java 10

Reviewed-by: jlu, naoto

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

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

From jlu at openjdk.org  Fri Mar 22 21:09:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 22 Mar 2024 21:09:38 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v4]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <GVu3-2eQOKxA9-HVDYBCj8dV9_3N7xIt0WqYRN8t8U4=.1ca00df7-0437-44fe-9677-7e65684a73cd@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

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

 - replace protected field for private fields in subclasses for consistency
 - drop Format implNote as well
 - setStrict and isStrict should be optional in NumberFormat
   - specify and throw UOE as default
   - override and implement in dFmt and cmpctNFmt
   parseStrict should be protected, and utilized by subclasses. The public methods should just
   serve as API.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/c09a34dd..4edb4802

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

  Stats: 148 lines in 4 files changed: 87 ins; 24 del; 37 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

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

From jlu at openjdk.org  Tue Mar 26 20:53:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 20:53:31 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional subformat
 pattern tests under en_US locale
Message-ID: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>

Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.

There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.

As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

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

Commit messages:
 - run in othervm
 - init

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

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

From jlu at openjdk.org  Tue Mar 26 20:55:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 20:55:35 GMT
Subject: <i18n dev> RFR: JDK-8327875: ChoiceFormat should advise throwing
 UnsupportedOperationException for unused methods
Message-ID: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>

Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.

The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

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

Commit messages:
 - remove contract wording
 - move and clarify api/impl note
 - init

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

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

From naoto at openjdk.org  Tue Mar 26 21:56:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 21:56:22 GMT
Subject: <i18n dev> RFR: JDK-8327875: ChoiceFormat should advise
 throwing UnsupportedOperationException for unused methods
In-Reply-To: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
References: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
Message-ID: <m4o61XoB3mrrZRABF3wohKzCv2NrhTJX8lWneYvkn6s=.e089bd72-d788-49fd-a657-fe3b1cac671f@github.com>

On Tue, 26 Mar 2024 20:50:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.
> 
> The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18499#pullrequestreview-1961808439

From naoto at openjdk.org  Tue Mar 26 22:00:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 22:00:25 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>

On Tue, 26 Mar 2024 20:49:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:

> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats

I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 43:

> 41: import static org.junit.jupiter.api.Assertions.assertEquals;
> 42: 
> 43: // This tests expects an en_US locale, as this locale provides distinct instances

Nit: typo tests -> test

test/jdk/java/text/Format/MessageFormat/ListSubFormats.java line 31:

> 29:  *          STANDARD, OR, and UNIT types are supported as built-in patterns for
> 30:  *          MessageFormat. All types use the FULL style.
> 31:  * @run junit/othervm -Duser.language=en -Duser.country=US ListSubFormats

Same as above

test/jdk/java/text/Format/MessageFormat/ListSubFormats.java line 42:

> 40: import static org.junit.jupiter.api.Assertions.assertThrows;
> 41: 
> 42: // This tests expects an en_US locale, as this locale provides distinct instances

ditto

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157210
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157737
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157897
PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540157979

From jlu at openjdk.org  Tue Mar 26 22:26:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 22:26:49 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v2]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <K4JdqqjPrQ2u33__VOHzYQt2P0aZfPnk4kNla7tVJzo=.42f1524a-67c8-44ae-8b1c-c0f576561588@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

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

  implement suggestions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/1ea2cd4e..33dc70ab

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

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

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

From jlu at openjdk.org  Tue Mar 26 22:26:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 22:26:49 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v2]
In-Reply-To: <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
Message-ID: <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>

On Tue, 26 Mar 2024 21:56:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   implement suggestions
>
> test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:
> 
>> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
>> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
>> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats
> 
> I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.

Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540182774

From naoto at openjdk.org  Tue Mar 26 22:34:23 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 22:34:23 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v2]
In-Reply-To: <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
 <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
Message-ID: <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>

On Tue, 26 Mar 2024 22:23:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 29:
>> 
>>> 27:  * @summary Test MessageFormatPattern ability to recognize and produce
>>> 28:  *          appropriate FormatType and FormatStyle for CompactNumberFormat.
>>> 29:  * @run junit/othervm -Duser.language=en -Duser.country=US CompactSubFormats
>> 
>> I would instantiate MessageFormat explicitly with the `US` locale (using the 2-arg constructor), instead of implicitly specifying it with the system property.
>
> Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)

I meant using `new MessageFormat(String, Locale.US)`, instead of `new MessageFormat(String)`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540192178

From jlu at openjdk.org  Tue Mar 26 23:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:02:34 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v3]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

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

  correct update

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/33dc70ab..bf99aa92

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

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

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

From jlu at openjdk.org  Tue Mar 26 23:02:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:02:34 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v3]
In-Reply-To: <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <2kYvjR5bmf2KjU9RTnTRpK3B-9I9ADwpDx90gH_4jPQ=.96c8a1ee-a3de-4001-b625-76454098138f@github.com>
 <W54BKumgdPRjShLWOLSqvViJrHtYoe0kfXRNZSZ2n78=.c0cbf6a1-d104-4eba-94a8-147800160f3e@github.com>
 <UmF-W2RBFVrF51fR36XpkyXXaf0EgXkIyzqWZL86EOo=.2d5fdc2e-7ad0-47ce-b44e-d9be84a18ec2@github.com>
Message-ID: <L71qIrJHyr73mDlLV3Fml50yZJti4h3brSYcF7juzgw=.07dd725d-1ec6-4e6e-bb76-9855d42caf4d@github.com>

On Tue, 26 Mar 2024 22:32:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Thanks for the review and suggestions, PR should be updated. (I presume you meant the 2-arg Locale.of() method, not the constructor)
>
> I meant using `new MessageFormat(String, Locale.US)`, instead of `new MessageFormat(String)`.

Ah, gotchu. Updated with the two arg `MessageFormat` constructor, although I think it would have been fine previously as well just passing the locale in directly to the subformat.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540210872

From naoto at openjdk.org  Tue Mar 26 23:12:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 23:12:21 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v3]
In-Reply-To: <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <0ExY69tWdqSeR8NMpuQ8Ep8MnyFJMqL2AEKQnHrQeSY=.82568e42-e8ee-4c7b-b2db-38cedff0e85a@github.com>
Message-ID: <QAb8yaJz4OiKGhD52j1jzg69XqEAZ7UDKq45xeYXIqE=.9e2a56f4-9023-48af-a191-d0eb26c26547@github.com>

On Tue, 26 Mar 2024 23:02:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   correct update

test/jdk/java/text/Format/MessageFormat/CompactSubFormats.java line 47:

> 45:     // This test expects an en_US locale, as this locale provides distinct instances
> 46:     // for different styles.
> 47:     private static final Locale loc = Locale.of("en", "US");

No need to define this field. You can directly use the `Locale.US` constant in the constructor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18498#discussion_r1540220164

From jlu at openjdk.org  Tue Mar 26 23:32:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 26 Mar 2024 23:32:34 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v4]
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

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

  drop loc field for US constant

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18498/files
  - new: https://git.openjdk.org/jdk/pull/18498/files/bf99aa92..5e797fe4

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

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

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

From naoto at openjdk.org  Tue Mar 26 23:44:21 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 26 Mar 2024 23:44:21 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v4]
In-Reply-To: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
Message-ID: <RqztHsFJs6juuGLsOyyhIjvEWhS4pMvaLRDPFMnuz-k=.83fc9ab4-0551-411f-a439-69cae3aababd@github.com>

On Tue, 26 Mar 2024 23:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop loc field for US constant

LGTM. Thanks for fixing it

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18498#pullrequestreview-1961949433

From jlu at openjdk.org  Wed Mar 27 21:00:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 27 Mar 2024 21:00:58 GMT
Subject: <i18n dev> RFR: JDK-8327640: Allow NumberFormat strict parsing
 [v5]
In-Reply-To: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
References: <c66iCcbmaNtxx3Sn00Zlwj__r5eZeMqt_jGGBx8bDIE=.f0de359c-e263-40ed-8ba3-e4f085075be1@github.com>
Message-ID: <HiouyCW1mXtZpMp7hyAKhuuZesxtu5BeFrQDJZ68fvo=.2903f485-499e-4af5-87a7-ca5c503d7fef@github.com>

> Please review this PR and associated [CSR](https://bugs.openjdk.org/browse/JDK-8327703) which introduces strict parsing for NumberFormat.
> 
> The concrete subclasses that will utilize this leniency value are `DecimalFormat` and `CompactNumberFormat`. Strict leniency allows for parsing to be used as an input validation technique for localized formatted numbers. The default leniency mode will remain lenient, and can only be set to strict through an intentional `setLenient(boolean)` method call. Leniency operates differently based off the values returned by `isGroupingUsed()`, `getGroupingSize()`, and `isParseIntegerOnly()`.
> 
> Below is an example of the change, the CSR can be viewed for further detail.
> 
> 
> DecimalFormat fmt = (DecimalFormat) NumberFormat.getNumberInstance(Locale.US);
> fmt.parse("1,,,0,,,00,.23Zabced45");  // returns 1000.23
> fmt.setLenient(false);
> fmt.parse("1,,,0,,,00,.23Zabced45"); // Now throws a ParseException
> fmt.setGroupingSize(2);
> fmt.parse("12,34,567"); // throws ParseException
> fmt.setParseIntegerOnly(true)
> fmt.parse("12,34.56"); // throws ParseException
> fmt.parse("12,34"); // successfully returns the Number 1234
> 
> 
> The associated tests are all localized, and the data is converted properly during runtime.

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

 - improve wording consistency and see tags
 - Merge branch 'master' into JDK-8327640-NumberFormat-strictParsing
 - revert cleanup changes; (to go into a separate change)
 - use directed 'inheritDoc' tag
 - update example for lenient parsing
 - replace protected field for private fields in subclasses for consistency
 - drop Format implNote as well
 - setStrict and isStrict should be optional in NumberFormat
   - specify and throw UOE as default
   - override and implement in dFmt and cmpctNFmt
   parseStrict should be protected, and utilized by subclasses. The public methods should just
   serve as API.
 - Re-work specification wording from Format down to subclasses
 - implement white space suggestions
 - ... and 3 more: https://git.openjdk.org/jdk/compare/c8a9b97f...3f2b097a

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18339/files
  - new: https://git.openjdk.org/jdk/pull/18339/files/4edb4802..3f2b097a

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

  Stats: 349232 lines in 2746 files changed: 15275 ins; 10415 del; 323542 mod
  Patch: https://git.openjdk.org/jdk/pull/18339.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18339/head:pull/18339

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

From jlu at openjdk.org  Wed Mar 27 21:16:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 27 Mar 2024 21:16:34 GMT
Subject: <i18n dev> Integrated: JDK-8327875: ChoiceFormat should advise
 throwing UnsupportedOperationException for unused methods
In-Reply-To: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
References: <zE8ujyq3yqEJU9ciQDVzZUUSkUZ_DE01Alvqtz8-85I=.f9682163-b989-4750-8334-e2d5735dfcf5@github.com>
Message-ID: <NXhPvCzD8HkOtZut27PIv4xa5kaVzZVMZj-lPkQBgCg=.0ca657c9-c6b6-40ee-9e81-dc84e64de214@github.com>

On Tue, 26 Mar 2024 20:50:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which advises ChoiceFormat subclasses throw `UnsupportedOperationException` for unused inherited methods.
> 
> The CSR covers the proposed wording, and the reasons as to why this is a specification and not an implementation update. In addition, the `api/implNote` tags have been moved to the bottom of the class description, as they are no longer only relevant to the pattern section, (where they were previously located).

This pull request has now been integrated.

Changeset: 0cb0b5db
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0cb0b5db2ac0f9b5a8fe40c5be5f7b12124fe402
Stats:     25 lines in 1 file changed: 15 ins; 10 del; 0 mod

8327875: ChoiceFormat should advise throwing UnsupportedOperationException for unused methods

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Thu Mar 28 22:47:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 28 Mar 2024 22:47:35 GMT
Subject: <i18n dev> Integrated: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale
In-Reply-To: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
Message-ID: <n8_EAOJGS30upo8VDp_vWEgXU1uVAqAZjQ-8MrA3Nlc=.bb837a5d-4aa4-4d5f-8f95-f0dc858f45e9@github.com>

On Tue, 26 Mar 2024 20:49:48 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
> 
> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
> 
> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.

This pull request has now been integrated.

Changeset: bf93e77e
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bf93e77e72ccce56685fd10dde83587c703a37b3
Stats:     18 lines in 2 files changed: 6 ins; 0 del; 12 mod

8329118: Run MessageFormat additional subformat pattern tests under en_US locale

Reviewed-by: naoto

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

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

From jiefu at openjdk.org  Sat Mar 30 02:30:55 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 30 Mar 2024 02:30:55 GMT
Subject: <i18n dev> RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
Message-ID: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>

Hi all,

java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
I'm not an expert in this area and just guess it can be fixed like this.
Please review it.

Thanks.
Best regards,
Jie

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

Commit messages:
 - 8329354: java/text/Format/MessageFormat/CompactSubFormats.java fails

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

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

From jiefu at openjdk.org  Sat Mar 30 02:32:40 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sat, 30 Mar 2024 02:32:40 GMT
Subject: <i18n dev> RFR: JDK-8329118: Run MessageFormat additional
 subformat pattern tests under en_US locale [v4]
In-Reply-To: <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
References: <8wbqf4ybyJ92xbBsHLR3HOz9gmsNVxV_CmY95JK2viM=.6e6d2b41-4be6-4668-bffc-e64b26e052be@github.com>
 <FS8FgbKCW44LTpb9WYFkcTBr8m6z4ZKDgAXUB6-k6-k=.8758371f-d065-442d-a7cd-ff116f518217@github.com>
Message-ID: <0CnJenyEVXAB2BQa9-u9TJzfW6a3kTAgez9barB0m9k=.ecf1c355-d9bd-480d-948d-b7ed8b31d652@github.com>

On Tue, 26 Mar 2024 23:32:34 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates two MessageFormat sub format related tests to be guaranteed to run under the `en_US` locale.
>> 
>> There exists locale that do not provide distinct instances for separate styles. For example, the `en_IN` locale provides the same LONG and SHORT compact number instances. The test data is built to test sub formats under the assumption that different styles do provide distinct instances.
>> 
>> As this is the case, these tests should be ran under a locale that does provide distinct instances for separate styles.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop loc field for US constant

Hi, please see the test failure: https://github.com/openjdk/jdk/pull/18557
Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18498#issuecomment-2027884264

From jlu at openjdk.org  Sat Mar 30 22:03:31 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 30 Mar 2024 22:03:31 GMT
Subject: <i18n dev> RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
Message-ID: <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@github.com>

On Sat, 30 Mar 2024 02:26:32 GMT, Jie Fu <jiefu at openjdk.org> wrote:

> Hi all,
> 
> java/text/Format/MessageFormat/CompactSubFormats.java fails in our testing machines.
> I'm not an expert in this area and just guess it can be fixed like this.
> Please review it.
> 
> Thanks.
> Best regards,
> Jie

Hi Jie,

This is indeed the correct solution to ensure that the DecimalFormat, (specifically, the underlying DecimalFormatSymbols) has the same locale as the MessageFormat subformat.

Thank you for the fix, it LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/18557#pullrequestreview-1970062699

From jiefu at openjdk.org  Sun Mar 31 11:03:30 2024
From: jiefu at openjdk.org (Jie Fu)
Date: Sun, 31 Mar 2024 11:03:30 GMT
Subject: <i18n dev> RFR: 8329354:
 java/text/Format/MessageFormat/CompactSubFormats.java fails
In-Reply-To: <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@github.com>
References: <TLYc6Ubasvqv7Sul60TQiyPxtawYUw8dR0VfJ_wRLts=.cdc2f57d-6779-40c9-b9fb-b60d11cd3271@github.com>
 <YC6n_tlt_PA0Wz_9xwJwR8c8SCJm8HHotJXsMVif8rU=.cbdd4307-1e3a-47b5-a29e-b4250c67dffc@github.com>
Message-ID: <hQHRsRgkNADsegx73q2LegWbTD2z6O6ytUKqrbYYDBc=.05d322e5-f5dd-4417-8086-5e5284fadce0@github.com>

On Sat, 30 Mar 2024 22:00:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> This is indeed the correct solution to ensure that the DecimalFormat, (specifically, the underlying DecimalFormatSymbols) has the same locale as the MessageFormat subformat.

Thanks @justin-curtis-lu for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/18557#issuecomment-2028644596