From shade at openjdk.org  Wed Nov  1 09:54:28 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 1 Nov 2023 09:54:28 GMT
Subject: <i18n dev> RFR: 8309622: Re-examine the cache mechanism in
 BaseLocale
In-Reply-To: <pw8M2rDyrS5DSt4Hxk7poIQ5pL6c9ZJKuL49-6DaWOQ=.e11e348f-7beb-4c1a-ab03-56e819893530@github.com>
References: <5MqmN4P1TLKDCfXPhKWrH1b2FTgOXmjtKgd1bVXDd_M=.2000f20d-365d-48dc-bc37-45d8bcb9447f@github.com>
 <zbx3xIqYwzCBzU6_qD-pnp0BS6s-RmUjv9J0phDd9ok=.b22fc675-1a82-451a-a13a-dfaf7e47e3e8@github.com>
 <pw8M2rDyrS5DSt4Hxk7poIQ5pL6c9ZJKuL49-6DaWOQ=.e11e348f-7beb-4c1a-ab03-56e819893530@github.com>
Message-ID: <kePMF24TshVQ7ee5v-5HYBV8FVQO6bb7wYuPAt6cUOA=.41275296-d4d9-4b84-b91c-5ef324acc352@github.com>

On Mon, 12 Jun 2023 17:28:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> One other thing to consider...
>> If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced.
>> Eliminating `.intern90` would make creating a normalized BaseLocale faster.
>
>> One other thing to consider... If the BaseLocale entries are being GC'd sooner, then perhaps the value of the String.intern() is reduced. Eliminating `.intern90` would make creating a normalized BaseLocale faster.
> 
> Some code inside the Locale still relies on `intern` and do `==` comparison. Yes, it would be faster but I think that would be out of the scope of this fix

@naotoj, we are still seeing the CI failures due to this. Are you planning to finish this work? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/14404#issuecomment-1788686569

From jlu at openjdk.org  Wed Nov  1 21:33:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Nov 2023 21:33:10 GMT
Subject: <i18n dev> Integrated: JDK-8317612: ChoiceFormat and MessageFormat
 constructors call non-final public method
In-Reply-To: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
References: <ZhGlItBcZc2lvTXB-2oWLy73kVagXcSl5lfNfxtU0Uc=.05de9a2e-8222-4429-b86e-b2337c87a6a3@github.com>
Message-ID: <OlVZb-z9W50hZIJehRwOgCIfgoXJK1XpPeEjxRYdiJI=.b6a2eda9-4f85-486d-a0b3-8923aa3926cf@github.com>

On Thu, 5 Oct 2023 20:44:55 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates ChoiceFormat and MessageFormat to no longer call overridable methods in their constructors.
> 
> The overridable methods called in the constructors are: _ChoiceFormat::applyPattern_, _ChoiceFormat::setChoices_, and _MessageFormat::applyPattern_. The code should be updated so that both the methods and constructors call a separate private method. Some other drive-by cleanup changes were included in the change as well.

This pull request has now been integrated.

Changeset: ee57e731
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ee57e731d03101ba6508297ef7d895082b04b427
Stats:     53 lines in 2 files changed: 36 ins; 3 del; 14 mod

8317612: ChoiceFormat and MessageFormat constructors call non-final public method

Reviewed-by: naoto, lancea

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

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

From jlu at openjdk.org  Wed Nov  1 21:35:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 1 Nov 2023 21:35:10 GMT
Subject: <i18n dev> RFR: 8318466: Improve spec of NumberFormat's methods
 with unsupported operations
Message-ID: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>

Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification.

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

Commit messages:
 - cleanup setRoundingMode()
 - Merge branch 'master' into JDK-8318466-NumberFormat-Unsupported
 - reflect review
 - init

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

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

From naoto at openjdk.org  Thu Nov  2 16:46:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 2 Nov 2023 16:46:04 GMT
Subject: <i18n dev> RFR: 8318466: Improve spec of NumberFormat's methods
 with unsupported operations
In-Reply-To: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
References: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
Message-ID: <ERJoEHFyVb6XlM14tgEZgSz6Z0JA46rc_rgaCaiC5Lo=.44a130a4-ae89-4afc-8d0b-66dab9ea5cdc@github.com>

On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16464#pullrequestreview-1710785970

From iris at openjdk.org  Thu Nov  2 17:14:02 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 2 Nov 2023 17:14:02 GMT
Subject: <i18n dev> RFR: 8318466: Improve spec of NumberFormat's methods
 with unsupported operations
In-Reply-To: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
References: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
Message-ID: <3ZrP-Qi2CcTiQYmZps5GlU8yJf-98rr5Qfefd_gvnI8=.9b34fbd4-db01-4089-83db-f130682a0aa1@github.com>

On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16464#pullrequestreview-1710843738

From jlahoda at openjdk.org  Fri Nov  3 15:02:11 2023
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 3 Nov 2023 15:02:11 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v3]
In-Reply-To: <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <_XrazddvO7-8lIILbhUn9VBpcp_YErXSWtxK4-eE53o=.7f423608-6901-4b34-a963-abc132d6c3cc@github.com>
Message-ID: <MYDQfxFlX5XdsSWlIlcTdA7UZh3Cs95OLPqKV6ilwWE=.29eee829-fbe5-44a7-a91e-005933f0c28f@github.com>

On Tue, 17 Oct 2023 16:03:25 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Cache process method type in JCStringTemplate

Looks good to me.

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

Marked as reviewed by jlahoda (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1712905674

From jlaskey at openjdk.org  Fri Nov  3 15:29:25 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 3 Nov 2023 15:29:25 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v4]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

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

 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Cache process method type in JCStringTemplate
 - Revert source
 - Revert @since 22
 - Accept qualified STR and RAW
 - String Templates (second preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/ae136779..2afadc69

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

  Stats: 53408 lines in 1930 files changed: 29390 ins; 10168 del; 13850 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

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

From jlu at openjdk.org  Fri Nov  3 17:36:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 3 Nov 2023 17:36:13 GMT
Subject: <i18n dev> Integrated: 8318466: Improve spec of NumberFormat's
 methods with unsupported operations
In-Reply-To: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
References: <Bv0na7TfXJVZ9nOR72vqOrKaXef2DJENVcSiSRi9ScA=.0920a6fe-759d-4fba-887a-be65199cc73f@github.com>
Message-ID: <g8Zodyp7zxdQkSQXWzDbpDM2WBE-v9wI3c6b8vlhSJI=.a97e7bbe-6132-4b33-9d27-874bf2f88534@github.com>

On Wed, 1 Nov 2023 21:27:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this simple change which refines the specification of some NumberFormat methods (with unsupported operations) to separate the API and implementation specification.

This pull request has now been integrated.

Changeset: ea6a88a0
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea6a88a0aa4e8a365a94e71078e67a4452f40945
Stats:     36 lines in 1 file changed: 9 ins; 11 del; 16 mod

8318466: Improve spec of NumberFormat's methods with unsupported operations

Reviewed-by: naoto, iris

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

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

From rriggs at openjdk.org  Fri Nov  3 20:33:47 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Nov 2023 20:33:47 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v3]
In-Reply-To: <MsXTIRsleBbIdFHXSxFu31toRNEfEzKqbt0x2c6l_Zw=.ba76dad5-cc04-498c-a9fd-56e35f707b70@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <MsXTIRsleBbIdFHXSxFu31toRNEfEzKqbt0x2c6l_Zw=.ba76dad5-cc04-498c-a9fd-56e35f707b70@github.com>
Message-ID: <Frx0cWBRcvXZwvpItcY23Cx_LQ7a4j-iqBIHLZuKTXY=.195318fa-c489-47da-963c-eff85fbefb4a@github.com>

On Mon, 16 Oct 2023 20:52:10 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo

Please separate out the change to be locale-independent from the fix for the original issue.
The compatibility risk may have an unknown impact on existing applications and needs further consideration.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1793059304

From redestad at openjdk.org  Fri Nov  3 21:01:45 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 3 Nov 2023 21:01:45 GMT
Subject: <i18n dev> RFR: 8319423: Improve Year.isLeap by checking
 divisibility by 16
Message-ID: <jzvL1koRTsVSRJ4RUrrLOJgmGm8RUTvdfU99cKXOCN0=.caef600b-152a-4841-ab2d-81d898dae5fd@github.com>

https://github.com/cassioneri/eaf suggest this code for leap year calculation:

    public static boolean isLeap(long year) {
        int d = year % 100 != 0 ? 4 : 16;
        return (year & (d - 1)) == 0;
    }

.. with a claim this would compile down to branchless, easily pipelined code.

This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`:


    public static boolean isLeap(long year) {
        return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0;
    }


Mac M1:

Name                           Cnt  Base   Error   Test   Error   Unit  Change
LeapYearBench.isLeapYear        15 0,743 ? 0,009  0,994 ? 0,005 ops/us   1,34x (p = 0,000*)
LeapYearBench.isLeapYearChrono  15 0,748 ? 0,006  0,991 ? 0,003 ops/us   1,32x (p = 0,000*)
LeapYearBench.isLeapYearNS      15 0,558 ? 0,026  0,552 ? 0,033 ops/us   0,99x (p = 0,602 )
  * = significant


Linux x64:

Name                           Cnt  Base   Error   Test   Error   Unit  Change
LeapYearBench.isLeapYear        15 0.534 ? 0.001  0.765 ? 0.004 ops/us   1.43x (p = 0.000*)
LeapYearBench.isLeapYearChrono  15 0.535 ? 0.000  0.753 ? 0.040 ops/us   1.41x (p = 0.000*)
LeapYearBench.isLeapYearNS      15 0.352 ? 0.000  0.351 ? 0.001 ops/us   1.00x (p = 0.000*)
  * = significant


30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up.

Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review.

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

Commit messages:
 - Add comment
 - Delegate IsoChronology.isLeapYear to Year.isLeap (both specified to behave identically), add microbenchmark testing the variant that optimize well with gcc
 - Merge branch 'master' into leapyear
 - Leap year optimization inspired by Neri & Schneider

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

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

From rriggs at openjdk.org  Fri Nov  3 21:01:45 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 3 Nov 2023 21:01:45 GMT
Subject: <i18n dev> RFR: 8319423: Improve Year.isLeap by checking
 divisibility by 16
In-Reply-To: <jzvL1koRTsVSRJ4RUrrLOJgmGm8RUTvdfU99cKXOCN0=.caef600b-152a-4841-ab2d-81d898dae5fd@github.com>
References: <jzvL1koRTsVSRJ4RUrrLOJgmGm8RUTvdfU99cKXOCN0=.caef600b-152a-4841-ab2d-81d898dae5fd@github.com>
Message-ID: <9rkJo2eaipAf-s54hk34o_UxUkzjsKii21xn7L1sRj8=.9229dc7e-381f-4132-977e-2e13bf420d3a@github.com>

On Fri, 3 Nov 2023 12:03:24 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> https://github.com/cassioneri/eaf suggest this code for leap year calculation:
> 
>     public static boolean isLeap(long year) {
>         int d = year % 100 != 0 ? 4 : 16;
>         return (year & (d - 1)) == 0;
>     }
> 
> .. with a claim this would compile down to branchless, easily pipelined code.
> 
> This doesn't currently happen with C2. In the meantime I think we can improve the current code in `Year.isLeap` and `IsoChronology.isLeapYear` by leveraging the fact that the `% 100` check is only needed if `(year & 15) != 0`:
> 
> 
>     public static boolean isLeap(long year) {
>         return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0;
>     }
> 
> 
> Mac M1:
> 
> Name                           Cnt  Base   Error   Test   Error   Unit  Change
> LeapYearBench.isLeapYear        15 0,743 ? 0,009  0,994 ? 0,005 ops/us   1,34x (p = 0,000*)
> LeapYearBench.isLeapYearChrono  15 0,748 ? 0,006  0,991 ? 0,003 ops/us   1,32x (p = 0,000*)
> LeapYearBench.isLeapYearNS      15 0,558 ? 0,026  0,552 ? 0,033 ops/us   0,99x (p = 0,602 )
>   * = significant
> 
> 
> Linux x64:
> 
> Name                           Cnt  Base   Error   Test   Error   Unit  Change
> LeapYearBench.isLeapYear        15 0.534 ? 0.001  0.765 ? 0.004 ops/us   1.43x (p = 0.000*)
> LeapYearBench.isLeapYearChrono  15 0.535 ? 0.000  0.753 ? 0.040 ops/us   1.41x (p = 0.000*)
> LeapYearBench.isLeapYearNS      15 0.352 ? 0.000  0.351 ? 0.001 ops/us   1.00x (p = 0.000*)
>   * = significant
> 
> 
> 30% higher throughput on M1, 40% on x64. `isLeapYearNS` runs a variant of the code from https://github.com/cassioneri/eaf ported to java - perhaps the JIT can be improved to do whatever clang/gcc does here and achieve an even better speed-up.
> 
> Testing: so far only java/time/tck/java/time locally, will run a few tiers before filing an enhancement and opening the PR for review.

Looks good. It probably needs a comment explaining why or a reference; otherwise it looks mysterious.

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

PR Comment: https://git.openjdk.org/jdk/pull/16491#issuecomment-1792984156

From alanb at openjdk.org  Sat Nov  4 13:31:11 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 4 Nov 2023 13:31:11 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v4]
In-Reply-To: <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
Message-ID: <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>

On Fri, 3 Nov 2023 15:29:25 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8315457
>  - Cache process method type in JCStringTemplate
>  - Revert source
>  - Revert @since 22
>  - Accept qualified STR and RAW
>  - String Templates (second preview)

Marked as reviewed by alanb (Reviewer).

src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424:

> 422:     * @since 21
> 423:     */
> 424:    @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)

I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release.

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

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1713768565
PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392709

From alanb at openjdk.org  Sat Nov  4 13:31:12 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 4 Nov 2023 13:31:12 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v4]
In-Reply-To: <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <bmeGeg-bMDjx68HjUq7joURHw-_r4LGbqrtgdZ-2s6k=.90be47de-47ae-4c1a-aa66-4b2f8591efbd@github.com>
 <T9KFSi-LRPHyvBWOVytdVWzp6UVovZNtsLK-_98VOmM=.be01f7e4-6a56-4b2f-a8fb-3aaa62a9b649@github.com>
Message-ID: <jiazs5RU4mhB6cH1X4OgpBJKDPZt9zNusqTDGccVGg0=.b5a9481b-1e57-4a02-9f6c-f5c0b70e1a0f@github.com>

On Mon, 16 Oct 2023 14:31:46 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Wasn't sure about that. Thx.

When in doubt, JEP 12.  Alex provided good guidance for API authors on how `@since` should be used with preview APIs.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1382392982

From jlaskey at openjdk.org  Mon Nov  6 12:51:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Nov 2023 12:51:34 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v5]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <9uwfuPjY_0dSLi2a52bsIoRswDtAH5-ILNQm6wm1Zjs=.b4222a67-f020-40b8-b5c6-cbdb26f46116@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:

  Remove preview from JavaLangAccess

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/2afadc69..4641ec05

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

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

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

From jlaskey at openjdk.org  Mon Nov  6 12:51:39 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 6 Nov 2023 12:51:39 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v4]
In-Reply-To: <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <QBZ8xuw5LtKRaCd0leYVluOCnU9tdoijoVTY6cc9B2o=.0c32ac07-c796-40fc-a84e-50a9bb412891@github.com>
 <X_tuDT6nvyXy39OvH09s1s0wQuhtZ1Nr_QXsEhLkjdM=.f5b876d7-d04b-4f05-a164-524400a2fad2@github.com>
Message-ID: <6mtIcg0H0wbOwcAzlmWG9thAjUpDCzQe55aLQDGA33Q=.deaada83-150c-4e1d-85c3-c07c61ff62a5@github.com>

On Sat, 4 Nov 2023 13:26:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into 8315457
>>  - Cache process method type in JCStringTemplate
>>  - Revert source
>>  - Revert @since 22
>>  - Accept qualified STR and RAW
>>  - String Templates (second preview)
>
> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 424:
> 
>> 422:     * @since 21
>> 423:     */
>> 424:    @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 
> I think you can drop both `@since` and `@PreviewFeature` from these methods. This in an internal interface, used for shared secrets, there is a lot of churn in JLA in each release.

Removed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16202#discussion_r1383275177

From duke at openjdk.org  Mon Nov  6 14:55:54 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 6 Nov 2023 14:55:54 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v4]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <jhs6bfYJQtwA_vz5Y7EPAbBDqH33fVjQ-kyv7ypHBDM=.6e4dc212-27df-4f30-9396-28e8a6b8d23d@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  revert localize change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/8b31e875..b6313fc0

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

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

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

From naoto at openjdk.org  Tue Nov  7 00:03:31 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 Nov 2023 00:03:31 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v4]
In-Reply-To: <jhs6bfYJQtwA_vz5Y7EPAbBDqH33fVjQ-kyv7ypHBDM=.6e4dc212-27df-4f30-9396-28e8a6b8d23d@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <jhs6bfYJQtwA_vz5Y7EPAbBDqH33fVjQ-kyv7ypHBDM=.6e4dc212-27df-4f30-9396-28e8a6b8d23d@github.com>
Message-ID: <7wlZslqihB6PE5hFT9I_j8GvRTPTNBJMHCdzK1xsapo=.b47e0d2c-5def-4cba-98d0-c7254263e30a@github.com>

On Mon, 6 Nov 2023 14:55:54 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert localize change

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

> 4493:                     int year = t.get(ChronoField.YEAR);
> 4494:                     if (year < 0) {
> 4495:                         sb.append('-');

Some locales use a different code point to express negative numbers from `hyphen-minus`, such as `minus sign` (U+2212). I'd suggest getting it from `DecimalFormatSymbols.getMinusSign()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384186755

From duke at openjdk.org  Tue Nov  7 01:31:03 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 7 Nov 2023 01:31:03 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  use DecimalFormatSymbols#getMinusSign

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/b6313fc0..7051ad51

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

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

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

From jlaskey at openjdk.org  Tue Nov  7 12:29:54 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 7 Nov 2023 12:29:54 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v6]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey 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 eight additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Remove preview from JavaLangAccess
 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Cache process method type in JCStringTemplate
 - Revert source
 - Revert @since 22
 - Accept qualified STR and RAW
 - String Templates (second preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/4641ec05..c616f48e

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

  Stats: 2467 lines in 114 files changed: 1740 ins; 357 del; 370 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

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

From naoto at openjdk.org  Tue Nov  7 13:31:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 Nov 2023 13:31:35 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
Message-ID: <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>

On Tue, 7 Nov 2023 01:31:03 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use DecimalFormatSymbols#getMinusSign

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

> 4493:                     int year = t.get(ChronoField.YEAR);
> 4494:                     if (year < 0) {
> 4495:                         sb.append(DecimalFormatSymbols.getInstance(l).getMinusSign());

Instead of creating the instance each time, `getMinusSign(Locale)` can be defined, analogous to `getZero(Locale)` so that the cached instance is reused.

test/jdk/java/util/Formatter/BasicDateTime.java line 473:

> 471:                 "%tF",
> 472:                 DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13",
> 473:                 LocalDate.of(-2023, 1, 13));

Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with  `Locale.availableLocale()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384355166
PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384915823

From redestad at openjdk.org  Tue Nov  7 13:51:40 2023
From: redestad at openjdk.org (Claes Redestad)
Date: Tue, 7 Nov 2023 13:51:40 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
 <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>
Message-ID: <qIEnswi7hQETF6-n3Rrxxq3kEd-ZkJo7AteTTQp1-5g=.80d6dcbb-eefc-4c81-a845-3e0585221c07@github.com>

On Tue, 7 Nov 2023 13:28:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use DecimalFormatSymbols#getMinusSign
>
> test/jdk/java/util/Formatter/BasicDateTime.java line 473:
> 
>> 471:                 "%tF",
>> 472:                 DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13",
>> 473:                 LocalDate.of(-2023, 1, 13));
> 
> Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with  `Locale.availableLocale()`.

While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): 

int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES"))
    .getMinusSign()
minus ==> 8722

int first = DateTimeFormatter.ISO_DATE
    .withLocale(Locale.forLanguageTag("eu-ES"))
    .format(ZonedDateTime.now()
    .minus(4000, java.time.temporal.ChronoUnit.YEARS)
    .charAt(0)
first ==> 45

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1384939609

From rriggs at openjdk.org  Tue Nov  7 15:06:36 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 7 Nov 2023 15:06:36 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <qIEnswi7hQETF6-n3Rrxxq3kEd-ZkJo7AteTTQp1-5g=.80d6dcbb-eefc-4c81-a845-3e0585221c07@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
 <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>
 <qIEnswi7hQETF6-n3Rrxxq3kEd-ZkJo7AteTTQp1-5g=.80d6dcbb-eefc-4c81-a845-3e0585221c07@github.com>
Message-ID: <dqC8jHzkC31cnwDDWkN3Hqwlz77lOqH1rHb3lDx9mCE=.e3cc3b45-9357-43af-8013-3bc325e97921@github.com>

On Tue, 7 Nov 2023 13:45:54 GMT, Claes Redestad <redestad at openjdk.org> wrote:

>> test/jdk/java/util/Formatter/BasicDateTime.java line 473:
>> 
>>> 471:                 "%tF",
>>> 472:                 DecimalFormatSymbols.getInstance(localeEuES).getMinusSign() + "2023-01-13",
>>> 473:                 LocalDate.of(-2023, 1, 13));
>> 
>> Needs some comments here, otherwise it would be a bit cryptic. Also, "eu-ES" locale using `\u2212` depends on the current CLDR implementation, so you might want to check all locales with  `Locale.availableLocale()`.
>
> While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): 
> 
> int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES"))
>     .getMinusSign()
> minus ==> 8722
> 
> int first = DateTimeFormatter.ISO_DATE
>     .withLocale(Locale.forLanguageTag("eu-ES"))
>     .format(ZonedDateTime.now()
>     .minus(4000, java.time.temporal.ChronoUnit.YEARS)
>     .charAt(0)
> first ==> 45

Within java.util.Formatter, the year formatter supports only the range [0,9999].
Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. 
The formatting in java.time is defined over the full range of years.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385067362

From duke at openjdk.org  Tue Nov  7 15:18:37 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 7 Nov 2023 15:18:37 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <dqC8jHzkC31cnwDDWkN3Hqwlz77lOqH1rHb3lDx9mCE=.e3cc3b45-9357-43af-8013-3bc325e97921@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
 <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>
 <qIEnswi7hQETF6-n3Rrxxq3kEd-ZkJo7AteTTQp1-5g=.80d6dcbb-eefc-4c81-a845-3e0585221c07@github.com>
 <dqC8jHzkC31cnwDDWkN3Hqwlz77lOqH1rHb3lDx9mCE=.e3cc3b45-9357-43af-8013-3bc325e97921@github.com>
Message-ID: <IYfYpol_hgpZQ1Ah8P2G0i_pbfrwJNUdnrZsH4vsc4I=.0484e571-714c-4ec7-9e50-b13850b2f4b3@github.com>

On Tue, 7 Nov 2023 15:04:16 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> While it might be reasonable to localize using `getMinusSign()` this will introduce a new inconsistency with `DateTimeFormatter` (which *does not* localize minus signs in front of years): 
>> 
>> int minus = DecimalFormatSymbols.getInstance(Locale.forLanguageTag("eu-ES"))
>>     .getMinusSign()
>> minus ==> 8722
>> 
>> int first = DateTimeFormatter.ISO_DATE
>>     .withLocale(Locale.forLanguageTag("eu-ES"))
>>     .format(ZonedDateTime.now()
>>     .minus(4000, java.time.temporal.ChronoUnit.YEARS)
>>     .charAt(0)
>> first ==> 45
>
> Within java.util.Formatter, the year formatter supports only the range [0,9999].
> Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. 
> The formatting in java.time is defined over the full range of years.

I think it is more reasonable for ISO_STANDARD_DATE to be consistent with java.time.DateTimeFormatter, ISO 8601 format is not localized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385083995

From naoto at openjdk.org  Tue Nov  7 16:44:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 7 Nov 2023 16:44:33 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v5]
In-Reply-To: <IYfYpol_hgpZQ1Ah8P2G0i_pbfrwJNUdnrZsH4vsc4I=.0484e571-714c-4ec7-9e50-b13850b2f4b3@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <rLM3w2R65HnYuqmxCzdioKrIfktvTcH2kTL16rKotTQ=.afff748f-ac4c-4eeb-9155-c256dd84e682@github.com>
 <M27OwPW_aCaCypNCVfQ-uLv5TYtNBFTKzH8UzwG36z0=.b325eb8e-4575-49b0-909c-22d17e0bc9ed@github.com>
 <qIEnswi7hQETF6-n3Rrxxq3kEd-ZkJo7AteTTQp1-5g=.80d6dcbb-eefc-4c81-a845-3e0585221c07@github.com>
 <dqC8jHzkC31cnwDDWkN3Hqwlz77lOqH1rHb3lDx9mCE=.e3cc3b45-9357-43af-8013-3bc325e97921@github.com>
 <IYfYpol_hgpZQ1Ah8P2G0i_pbfrwJNUdnrZsH4vsc4I=.0484e571-714c-4ec7-9e50-b13850b2f4b3@github.com>
Message-ID: <6VnaPgf9pbpLauwPU_ixQGQXSK7Pz28xi2VyFYe2ATI=.cd8aeb2c-3fc6-4720-81ae-efa57eef571c@github.com>

On Tue, 7 Nov 2023 15:15:19 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> Within java.util.Formatter, the year formatter supports only the range [0,9999].
>> Only ISO_STANDARD_DATE has a ISO 8601 format defined for numbers outside that range. 
>> The formatting in java.time is defined over the full range of years.
>
> I think it is more reasonable for ISO_STANDARD_DATE to be consistent with java.time.DateTimeFormatter, ISO 8601 format is not localized.

IIUC, what we are trying to fix here is to align the weird *behavior* outside of 0-9999 in java.util.Formatter with java.time's, not how they are represented. j.u.Formatter already formats numbers in local digits, so I believe it is natural to use the localized negative prefix as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1385229360

From duke at openjdk.org  Wed Nov  8 00:52:36 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Wed, 8 Nov 2023 00:52:36 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v6]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  Use minus sign from cached DecimalFormatSymbols and improved testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/7051ad51..47fc35f1

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

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

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

From job at kimmeringer.de  Wed Nov  8 12:38:42 2023
From: job at kimmeringer.de (Lothar Kimmeringer)
Date: Wed, 8 Nov 2023 13:38:42 +0100
Subject: <i18n dev> RFR: 8319423: Improve Year.isLeap by checking
 divisibility by 16
In-Reply-To: <jzvL1koRTsVSRJ4RUrrLOJgmGm8RUTvdfU99cKXOCN0=.caef600b-152a-4841-ab2d-81d898dae5fd@github.com>
References: <jzvL1koRTsVSRJ4RUrrLOJgmGm8RUTvdfU99cKXOCN0=.caef600b-152a-4841-ab2d-81d898dae5fd@github.com>
Message-ID: <ca222faf-c5c7-49b0-ae50-33f741334931@kimmeringer.de>



Am 03.11.2023 um 22:01 schrieb Claes Redestad:

>      public static boolean isLeap(long year) {
>          return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0;
>      }

Not sure if this has any effect in terms of performance but not being a
fan of duplicated code, a variant would be

   return (year & 3) == 0 && (year & 15 == 0 || year % 100 != 0);


Cheers, Lothar

From naoto at openjdk.org  Wed Nov  8 18:41:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Nov 2023 18:41:59 GMT
Subject: <i18n dev> RFR: 8306116: Update CLDR to Version 44.0
Message-ID: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>

Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:

CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)

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

Commit messages:
 - update license files
 - Merge branch 'master' into JDK-8306116-CLDR44
 - Merge branch 'master' into JDK-8306116-CLDR44
 - Fix to generate java.time.long.Eras
 - release-44
 - release-44-beta5
 - release-44-beta4
 - release-44-beta3
 - release-44-beta2
 - native UTF-8 for `mgo` name
 - ... and 9 more: https://git.openjdk.org/jdk/compare/cdf33735...f286ddd3

Changes: https://git.openjdk.org/jdk/pull/16439/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16439&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8306116
  Stats: 591898 lines in 499 files changed: 72642 ins; 463467 del; 55789 mod
  Patch: https://git.openjdk.org/jdk/pull/16439.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16439/head:pull/16439

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

From naoto at openjdk.org  Wed Nov  8 18:49:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Nov 2023 18:49:11 GMT
Subject: <i18n dev> RFR: 8296250" Update ICU4J to Version 74.1
Message-ID: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>

Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Nomalization and BiDi support

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

Commit messages:
 - update the license file
 - Merge branch 'master' into JDK-8296250-ICU4J-74.1
 - v74.1 final
 - iniital commit

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

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

From srl at openjdk.org  Wed Nov  8 18:50:01 2023
From: srl at openjdk.org (Steven Loomis)
Date: Wed, 8 Nov 2023 18:50:01 GMT
Subject: <i18n dev> RFR: 8306116: Update CLDR to Version 44.0
In-Reply-To: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
References: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
Message-ID: <VR49ILjoFdypLJkywgHY1TDIWT_9JnoS7uyGEhni-9Y=.3227e765-30ce-4dc0-92a5-e21d1a95b908@github.com>

On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:
> 
> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)

LGTM!

make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 517:

> 515:                 }
> 516:                 map.put(realKey, value);
> 517:                 map.put("java.time." + realKey, value);

I'm assuming this was a workaround no longer needed?

src/java.base/share/legal/cldr.md line 1:

> 1: ## Unicode Common Local Data Repository (CLDR) v44

Short and sweet!

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

Marked as reviewed by srl (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1721048254
PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059253
PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387059522

From naoto at openjdk.org  Wed Nov  8 19:00:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 8 Nov 2023 19:00:00 GMT
Subject: <i18n dev> RFR: 8306116: Update CLDR to Version 44.0
In-Reply-To: <VR49ILjoFdypLJkywgHY1TDIWT_9JnoS7uyGEhni-9Y=.3227e765-30ce-4dc0-92a5-e21d1a95b908@github.com>
References: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
 <VR49ILjoFdypLJkywgHY1TDIWT_9JnoS7uyGEhni-9Y=.3227e765-30ce-4dc0-92a5-e21d1a95b908@github.com>
Message-ID: <YhhzK5XDUs6tM2ehMaNNSbMBcq4aLo9mcFioJAEtGuQ=.56c1942d-dda7-445a-866d-6a918362fbfb@github.com>

On Wed, 8 Nov 2023 18:45:47 GMT, Steven Loomis <srl at openjdk.org> wrote:

>> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:
>> 
>> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
>> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
>> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
>> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
>> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
>> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)
>
> make/jdk/src/classes/build/tools/cldrconverter/Bundle.java line 517:
> 
>> 515:                 }
>> 516:                 map.put(realKey, value);
>> 517:                 map.put("java.time." + realKey, value);
> 
> I'm assuming this was a workaround no longer needed?

Since `short` and `abbreviated` handling differ between `java.text/util` and `java.time`, this is still needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16439#discussion_r1387071317

From joehw at openjdk.org  Thu Nov  9 00:46:55 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 9 Nov 2023 00:46:55 GMT
Subject: <i18n dev> RFR: 8296250" Update ICU4J to Version 74.1
In-Reply-To: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
References: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
Message-ID: <aZYU9EAfnE71I0ujWDeA0ARMj3nSkcLuweCPYG7R1o0=.c3132dac-69cd-483c-9898-09a6ca3dafde@github.com>

On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1721505890

From joehw at openjdk.org  Thu Nov  9 02:07:57 2023
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 9 Nov 2023 02:07:57 GMT
Subject: <i18n dev> RFR: 8306116: Update CLDR to Version 44.0
In-Reply-To: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
References: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
Message-ID: <Gf2nN71jTPazhToKrLAZwWCalxlCshPzKuQTmpcN5dA=.da95d5a3-93c5-46e8-a641-041b0394512c@github.com>

On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:
> 
> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1721571315

From lancea at openjdk.org  Thu Nov  9 11:32:57 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 9 Nov 2023 11:32:57 GMT
Subject: <i18n dev> RFR: 8296250" Update ICU4J to Version 74.1
In-Reply-To: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
References: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
Message-ID: <WvxQEfgqtY_fPEnrV5en98EX5Rt7rU_4hDa1RF75mSw=.277c1528-7feb-4f25-81ce-ae50efe905c2@github.com>

On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1722327026

From rriggs at openjdk.org  Thu Nov  9 15:44:02 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Nov 2023 15:44:02 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v6]
In-Reply-To: <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
Message-ID: <U_ZMRCV0FAP_taOhxghxGNsnN6iYRhSduvkz2Ab63VM=.ae68f67e-5583-4b35-8b45-6a00e85d7251@github.com>

On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use minus sign from cached DecimalFormatSymbols and improved testcase

Thanks for the updates.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16033#pullrequestreview-1722846831

From vromero at openjdk.org  Thu Nov  9 16:05:06 2023
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 9 Nov 2023 16:05:06 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v6]
In-Reply-To: <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
 <3NHJ2yDj2dW6Y4qPF8FmBkqkXcG7l-BzQ3EKWYArZMI=.28885188-9e99-46e8-81bd-6234023c1b1f@github.com>
Message-ID: <0K0xamwKYF8WAEot9UxNl8ncxWFkonJiSDgCVqs8b7A=.755020db-142d-4572-9a59-e1e31a741945@github.com>

On Tue, 7 Nov 2023 12:29:54 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Update String Templates for a second preview. With the addition of
>> 
>> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
>> 
>> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
>> 
>> - Raw (generic) process types are no longer an error.
>
> Jim Laskey 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 eight additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into 8315457
>  - Remove preview from JavaLangAccess
>  - Merge remote-tracking branch 'upstream/master' into 8315457
>  - Cache process method type in JCStringTemplate
>  - Revert source
>  - Revert @since 22
>  - Accept qualified STR and RAW
>  - String Templates (second preview)

lgtm

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16202#pullrequestreview-1722905748

From rriggs at openjdk.org  Thu Nov  9 16:05:59 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Nov 2023 16:05:59 GMT
Subject: <i18n dev> RFR: 8296250" Update ICU4J to Version 74.1
In-Reply-To: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
References: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
Message-ID: <7L1uSdeCYhYJZEwsjqWRVI2uVjxbp87DA-JGiV6neSM=.0e318dd7-a577-4493-b4d4-f579d69b8ca0@github.com>

On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16458#pullrequestreview-1722908995

From lancea at openjdk.org  Thu Nov  9 16:20:59 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 9 Nov 2023 16:20:59 GMT
Subject: <i18n dev> RFR: 8306116: Update CLDR to Version 44.0
In-Reply-To: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
References: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
Message-ID: <0DDdC9CF-OhIVtmCFum1POY7ZTgWhEi-7kDZO5QZq5Q=.4f0c1ddb-1527-45c1-963f-8fc6a5ac89e7@github.com>

On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:
> 
> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16439#pullrequestreview-1722957033

From naoto at openjdk.org  Thu Nov  9 17:18:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Nov 2023 17:18:03 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v6]
In-Reply-To: <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
Message-ID: <UCCRUuk-_GQJYVZqQMAT-Ta_6tXHuFx8C4XgW-G31d4=.b2c84bb2-f1d2-4053-a0fe-61b523a1b2d2@github.com>

On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use minus sign from cached DecimalFormatSymbols and improved testcase

Looks like your fix causes a regression test failure in test/jdk/java/time/test/java/util/TestFormatter.java

----------System.out:(1097/72894)----------
test test.java.util.TestFormatter.test("en_US"): success
test test.java.util.TestFormatter.test("th_TH"): success
ChronoZonedDateTimeImpl(Japanese)  actual: D:[04/19/05] F:[2023-04-19]
                FAILED; expected: D:[04/19/05] F:[0005-04-19]
java.lang.RuntimeException
	at test.java.util.TestFormatter.test(TestFormatter.java:198)
	at test.java.util.TestFormatter.testDate(TestFormatter.java:216)
	at test.java.util.TestFormatter.test(TestFormatter.java:114)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
	at org.testng.TestRunner.privateRun(TestRunner.java:764)
	at org.testng.TestRunner.run(TestRunner.java:585)
	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
	at org.testng.TestNG.runSuites(TestNG.java:1069)
	at org.testng.TestNG.run(TestNG.java:1037)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1570)

Please make sure all the related regression tests pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1804237006

From rriggs at openjdk.org  Thu Nov  9 17:27:00 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Nov 2023 17:27:00 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v6]
In-Reply-To: <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
Message-ID: <-GfViWiwQmceGNowaIERufq7gJn3DF3dA6oLo03BR04=.63199bff-9265-4d36-8bf3-0375800c1e6f@github.com>

On Wed, 8 Nov 2023 00:52:36 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use minus sign from cached DecimalFormatSymbols and improved testcase

Without the change localization of the dates, the CSR is not needed

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1804251322

From naoto at openjdk.org  Thu Nov  9 17:56:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 9 Nov 2023 17:56:10 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
Message-ID: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>

Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

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

Commit messages:
 - initial commit

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

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

From rriggs at openjdk.org  Thu Nov  9 18:38:56 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 9 Nov 2023 18:38:56 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <I8p11MfAY_pzQS3481NqKl6rSETueVRX9mEqObYZzzo=.4ca4f716-9356-44ee-b191-73bcd916143d@github.com>

On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723260458

From iris at openjdk.org  Thu Nov  9 18:57:01 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 9 Nov 2023 18:57:01 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <B39lQQYbDJI-liDrKhypDUsWOVNLwDWf1-8c6AGRihw=.9b3f8968-f729-4cfe-a09e-3f513c655308@github.com>

On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723287749

From jlu at openjdk.org  Thu Nov  9 22:05:15 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Nov 2023 22:05:15 GMT
Subject: <i18n dev> RFR: JDK-8318189: ChoiceFormat::format throws
 undocumented AIOOBE
Message-ID: <F3DmKBLQ7SFVb57KrMxJuyxDGRhckt0F45yqnC5fHqY=.f3b786f9-6aab-43f3-a423-db32f815177d@github.com>

Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format.

An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked.

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

Commit messages:
 - init

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

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

From jlu at openjdk.org  Thu Nov  9 22:54:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 9 Nov 2023 22:54:56 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <sLmEq9gYsFpqPXw31Uu2aAj-X9X9QPgPzp2q-WAhBiE=.51b1a818-9538-493e-907f-677b7ddc9a75@github.com>

On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1723639587

From naoto at openjdk.org  Fri Nov 10 00:08:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 10 Nov 2023 00:08:57 GMT
Subject: <i18n dev> RFR: JDK-8318189: ChoiceFormat::format throws
 undocumented AIOOBE
In-Reply-To: <F3DmKBLQ7SFVb57KrMxJuyxDGRhckt0F45yqnC5fHqY=.f3b786f9-6aab-43f3-a423-db32f815177d@github.com>
References: <F3DmKBLQ7SFVb57KrMxJuyxDGRhckt0F45yqnC5fHqY=.f3b786f9-6aab-43f3-a423-db32f815177d@github.com>
Message-ID: <sTjy4CeCOpRPJSqUAJPRI8kWr4_2DEyrEkpWSkWMlb4=.70ecf3fa-747e-4cb3-aa5a-d9342116798a@github.com>

On Thu, 9 Nov 2023 21:58:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format.
> 
> An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16587#pullrequestreview-1723711743

From joehw at openjdk.org  Fri Nov 10 01:22:57 2023
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 10 Nov 2023 01:22:57 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <RKySy9OAYidXVzO2HSViutmyCkUmBLMxFlq1vNROXNg=.b4d0bca7-981d-428d-b946-9b66fe96f7a3@github.com>

On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260:

> 258:             .toFormatter(Locale.ROOT)
> 259:             .toFormat();
> 260:         assertEquals(f.parseObject("17-30", new ParsePosition(0)), null);

I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1388762259

From duke at openjdk.org  Fri Nov 10 03:14:22 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 10 Nov 2023 03:14:22 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v7]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <pKYWbzFV8A02R1vAa3efmHOm5Hf-Ri5t_IPcWg8pgBk=.09f9bc60-8ad3-4d00-9b4f-cdf1b01799cd@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  fix format 'ja-JP-u-ca-japanese' ChronoLocalDate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/47fc35f1..902ab4ca

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

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

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

From duke at openjdk.org  Fri Nov 10 03:31:26 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 10 Nov 2023 03:31:26 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  fix format 'ja-JP-u-ca-japanese' ChronoLocalDate

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/902ab4ca..4e518b39

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

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

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

From aturbanov at openjdk.org  Sun Nov 12 09:18:04 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 12 Nov 2023 09:18:04 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <gUFWRZLpZK9i8wZ2Ejn7hj17C3yNj8c-mBSNi_S1V6I=.79b4a57d-7823-451c-bb8d-dd95384dbf20@github.com>

On Thu, 14 Sep 2023 08:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

Can I get a review?

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

PR Comment: https://git.openjdk.org/jdk/pull/15736#issuecomment-1807066050

From jlu at openjdk.org  Sun Nov 12 21:43:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sun, 12 Nov 2023 21:43:08 GMT
Subject: <i18n dev> Integrated: JDK-8318189: ChoiceFormat::format throws
 undocumented AIOOBE
In-Reply-To: <F3DmKBLQ7SFVb57KrMxJuyxDGRhckt0F45yqnC5fHqY=.f3b786f9-6aab-43f3-a423-db32f815177d@github.com>
References: <F3DmKBLQ7SFVb57KrMxJuyxDGRhckt0F45yqnC5fHqY=.f3b786f9-6aab-43f3-a423-db32f815177d@github.com>
Message-ID: <_7ErQkr_PSy1C9WH3F9l5AiVouA92CVKhLBSMuX768k=.d7cb535e-a601-457d-87e8-ab64606b709a@github.com>

On Thu, 9 Nov 2023 21:58:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which makes an `ArrayIndexOutOfBoundsException` apparent in ChoiceFormat::format.
> 
> An _incomplete_ ChoiceFormat can be created, which is not revealed until format is invoked.

This pull request has now been integrated.

Changeset: caf71810
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/caf71810f85ea55083ce7d1c76307a0c42d9be0e
Stats:     13 lines in 1 file changed: 11 ins; 0 del; 2 mod

8318189: ChoiceFormat::format throws undocumented AIOOBE

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Sun Nov 12 21:45:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sun, 12 Nov 2023 21:45:10 GMT
Subject: <i18n dev> RFR: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args
Message-ID: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter.

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

Commit messages:
 - init

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

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

From pminborg at openjdk.org  Mon Nov 13 11:45:06 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Nov 2023 11:45:06 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <feIF4cRqXWoUrif0H9jOGuTbBmweQ5joSmBWSoqg1tA=.8af125cf-035c-453d-add8-78945701de38@github.com>

On Thu, 14 Sep 2023 08:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

src/java.base/share/classes/sun/util/cldr/CLDRCalendarDataProviderImpl.java line 48:

> 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl {
> 47: 
> 48:     private static final Map<String, Integer> firstDay = new ConcurrentHashMap<>();

We might rename these fields to FIRST_DAY etc.

src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java line 63:

> 61: 
> 62:     // parent locales map
> 63:     private static final Map<Locale, Locale> parentLocalesMap;

Rename to PARENT_LOCALES_MAP?

src/java.base/share/classes/sun/util/locale/LocaleObjectCache.java line 102:

> 100:     }
> 101: 
> 102:     private static class CacheEntry<K, V> extends SoftReference<V> {

The class itself might be `final`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391002631
PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391004183
PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391005224

From pminborg at openjdk.org  Mon Nov 13 11:51:00 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 13 Nov 2023 11:51:00 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util' package
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <p6HToIxey7NrseUmDxMArBNdUgcU6n5ctcN9XbtQBlk=.e38ba390-f2a2-42dc-9144-3857a12cfb68@github.com>

On Thu, 14 Sep 2023 08:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

LGTM. See comments though.

src/java.base/share/classes/sun/util/locale/StringTokenIterator.java line 33:

> 31: package sun.util.locale;
> 32: 
> 33: public class StringTokenIterator {

The class may be `final`

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

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/15736#pullrequestreview-1727154051
PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1391008427

From naoto at openjdk.org  Mon Nov 13 16:57:14 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 16:57:14 GMT
Subject: <i18n dev> Integrated: 8296250" Update ICU4J to Version 74.1
In-Reply-To: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
References: <QPTI9FaR9rTcVw3lnQeITZniqIpEAjy9yy1DdPaSrIA=.3ee8a5f6-aa4a-4297-ab15-58cee63da978@github.com>
Message-ID: <SaSEusc-vVcM1rbNYmC3VILKEzf6yUIdyC-0kGf_Qb0=.74285f0b-a869-4e04-899a-a1a1b7052f7b@github.com>

On Wed, 1 Nov 2023 17:40:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the ICU4J components to v74.1 (https://icu.unicode.org/download/74). This change completes the Unicode 15.1 upgrade. The change is merely replacing binary data files used for the Normalization and BiDi support

This pull request has now been integrated.

Changeset: 88ccd646
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/88ccd646a7778045d773099da0f743efb169169c
Stats:     528 lines in 12 files changed: 80 ins; 426 del; 22 mod

8296250: Update ICU4J to Version 74.1

Reviewed-by: joehw, lancea, rriggs

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

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

From naoto at openjdk.org  Mon Nov 13 16:58:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 16:58:17 GMT
Subject: <i18n dev> Integrated: 8306116: Update CLDR to Version 44.0
In-Reply-To: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
References: <Fwd20srqUYO4sKyyJzPdFLxSo9aZ2nZ-QC8qAgmCYTE=.531a81f7-9ac3-4c3f-84d2-83cd85487215@github.com>
Message-ID: <ycQ-SdaKYnJf1ZRGLEVj2C3mv3FKYwqM-H16vjU-OPo=.ba717b96-70db-4d13-9309-444b2f76c003@github.com>

On Tue, 31 Oct 2023 21:06:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading CLDR to v44 (https://cldr.unicode.org/index/downloads/cldr-44). Besides the data upgrade, regression tests are modified to accommodate the following CLDR fixes:
> 
> CLDR-16534: Suggestion to rename the Islamic Calendar to Hijri Calendar (https://unicode-org.atlassian.net/browse/CLDR-16534)
> CLDR-17042: Use exception list for new languages (https://unicode-org.atlassian.net/browse/CLDR-17042)
> CLDR-16586: en_ID shows IDR rather than Rp for currency (https://unicode-org.atlassian.net/browse/CLDR-16586)
> CLDR-16358: Mexico and Latin America countries should be using 12 hours time format (https://unicode-org.atlassian.net/browse/CLDR-16358)
> CLDR-16974: en_GB and en_AU: request to remove comma from MMMEEEEd format (https://unicode-org.atlassian.net/browse/CLDR-16974)
> CLDR-16857: Need updated translations for new Sierra Leone currency - SLL became SLE (https://unicode-org.atlassian.net/browse/CLDR-16857)

This pull request has now been integrated.

Changeset: 3684b4b5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3684b4b5f24b413408b1b6d206917931b855844e
Stats:     591898 lines in 499 files changed: 72642 ins; 463467 del; 55789 mod

8306116: Update CLDR to Version 44.0

Reviewed-by: srl, joehw, lancea

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

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

From naoto at openjdk.org  Mon Nov 13 18:37:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 18:37:42 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v2]
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <F0AxSidKXA0eh18MJciIzWKRbvtOsVr2bf0ms4WCDxo=.a57c3019-1044-42c3-825c-dbc408bc73f5@github.com>

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

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

 - comment fix
 - Addresses review comments
 - Merge branch 'master' into JDK-8319640-ClassicFormat-parseObject
 - initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16586/files
  - new: https://git.openjdk.org/jdk/pull/16586/files/7a4b8ef2..2b03aa2d

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

  Stats: 611054 lines in 787 files changed: 78824 ins; 472476 del; 59754 mod
  Patch: https://git.openjdk.org/jdk/pull/16586.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16586/head:pull/16586

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

From naoto at openjdk.org  Mon Nov 13 18:37:42 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 18:37:42 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v2]
In-Reply-To: <RKySy9OAYidXVzO2HSViutmyCkUmBLMxFlq1vNROXNg=.b4d0bca7-981d-428d-b946-9b66fe96f7a3@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
 <RKySy9OAYidXVzO2HSViutmyCkUmBLMxFlq1vNROXNg=.b4d0bca7-981d-428d-b946-9b66fe96f7a3@github.com>
Message-ID: <t4ZlZbZ04dO4glwScketZ9lmMnNzI8Yr8mJLT5v5-_0=.bad1553e-3de5-48a2-9187-a8b05b48c4c0@github.com>

On Fri, 10 Nov 2023 01:20:28 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 four additional commits since the last revision:
>> 
>>  - comment fix
>>  - Addresses review comments
>>  - Merge branch 'master' into JDK-8319640-ClassicFormat-parseObject
>>  - initial commit
>
> test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260:
> 
>> 258:             .toFormatter(Locale.ROOT)
>> 259:             .toFormat();
>> 260:         assertEquals(f.parseObject("17-30", new ParsePosition(0)), null);
> 
> I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length.

Thanks, Joe. Added extra test for IOOBE.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1391518275

From naoto at openjdk.org  Mon Nov 13 18:41:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 18:41:08 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v3]
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com>

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

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

  comment fix^2

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16586/files
  - new: https://git.openjdk.org/jdk/pull/16586/files/2b03aa2d..f43ae0f2

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

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

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

From naoto at openjdk.org  Mon Nov 13 19:35:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 19:35:41 GMT
Subject: <i18n dev> RFR: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args
In-Reply-To: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
References: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
Message-ID: <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com>

On Sun, 12 Nov 2023 21:39:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter.

src/java.base/share/classes/java/text/DateFormat.java line 68:

> 66:  * styles. The formatting styles include {@link #FULL}, {@link #LONG}, {@link #MEDIUM}, and {@link #SHORT}.
> 67:  * For any of the factory methods with the parameter <i>style</i>, an {@code
> 68:  * IllegalArgumentException} will be thrown if <i>style</i> is not equal to one

I wonder if "not equal to *any* of the ..." may read better here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16624#discussion_r1391596506

From rriggs at openjdk.org  Mon Nov 13 19:52:10 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 13 Nov 2023 19:52:10 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v3]
In-Reply-To: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
 <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com>
Message-ID: <93p7Rpn6iffeQPULlFiHv_hFJxd63GGz8Of6hJsN9vc=.f811574f-276c-41a4-a1d7-204b4b6df32b@github.com>

On Mon, 13 Nov 2023 18:41:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment fix^2

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1728140279

From jlu at openjdk.org  Mon Nov 13 21:38:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Nov 2023 21:38:11 GMT
Subject: <i18n dev> RFR: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args [v2]
In-Reply-To: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
References: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
Message-ID: <WSH0q5YRWhKW0dm1iY6XLqHq8yN67S3QLqlBdgamYIg=.ac19c8dc-0922-42d3-9f69-1df370282094@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter.

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

  reflect review, one -> any

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16624/files
  - new: https://git.openjdk.org/jdk/pull/16624/files/f1a4b6c9..fa795543

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

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

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

From jlu at openjdk.org  Mon Nov 13 21:38:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 13 Nov 2023 21:38:11 GMT
Subject: <i18n dev> RFR: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args [v2]
In-Reply-To: <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com>
References: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
 <745WFfokAyTnXxGiMr6ux80MxA85Y2PyQr322jllonI=.d5d53f5e-18bb-4fd1-bd3e-c70184ea4be8@github.com>
Message-ID: <EfMohv7xFb-31Ic_t8faU7zaqM5Lhzv2AIov1l1AfmI=.e249336b-62e8-4ed4-83e2-66a193a62ef0@github.com>

On Mon, 13 Nov 2023 19:32:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review, one -> any
>
> src/java.base/share/classes/java/text/DateFormat.java line 68:
> 
>> 66:  * styles. The formatting styles include {@link #FULL}, {@link #LONG}, {@link #MEDIUM}, and {@link #SHORT}.
>> 67:  * For any of the factory methods with the parameter <i>style</i>, an {@code
>> 68:  * IllegalArgumentException} will be thrown if <i>style</i> is not equal to one
> 
> I wonder if "not equal to *any* of the ..." may read better here.

Agreed that sounds better. Changed in both the CSR and the PR, thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16624#discussion_r1391730654

From joehw at openjdk.org  Mon Nov 13 22:13:28 2023
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 13 Nov 2023 22:13:28 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v3]
In-Reply-To: <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
 <3kVo3Ekns0CGdqxh9XtcU3Nq3VfLjAN55kZ6qV7S2ck=.5401cdab-726f-4f71-96cd-50099e9cc81a@github.com>
Message-ID: <T2j-bMdvi9EUlBWcKwp9uBlk-EGMdWaGTzmOZcuWunw=.2c9909d5-11c7-4857-9adb-00b6ad60749a@github.com>

On Mon, 13 Nov 2023 18:41:08 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   comment fix^2

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16586#pullrequestreview-1728370308

From joehw at openjdk.org  Mon Nov 13 22:13:31 2023
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 13 Nov 2023 22:13:31 GMT
Subject: <i18n dev> RFR: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException [v3]
In-Reply-To: <t4ZlZbZ04dO4glwScketZ9lmMnNzI8Yr8mJLT5v5-_0=.bad1553e-3de5-48a2-9187-a8b05b48c4c0@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
 <RKySy9OAYidXVzO2HSViutmyCkUmBLMxFlq1vNROXNg=.b4d0bca7-981d-428d-b946-9b66fe96f7a3@github.com>
 <t4ZlZbZ04dO4glwScketZ9lmMnNzI8Yr8mJLT5v5-_0=.bad1553e-3de5-48a2-9187-a8b05b48c4c0@github.com>
Message-ID: <iW8eEz5zJFOInv2tfklWSJs3ho8WkpbFBEd8SV-fn6w=.aff87dfc-9056-45aa-a158-9ca8296aa324@github.com>

On Mon, 13 Nov 2023 18:33:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> test/jdk/java/time/test/java/time/format/TestDateTimeParsing.java line 260:
>> 
>>> 258:             .toFormatter(Locale.ROOT)
>>> 259:             .toFormat();
>>> 260:         assertEquals(f.parseObject("17-30", new ParsePosition(0)), null);
>> 
>> I might have missed it, but this test doesn't seem to exercise the situation where IOOBE would happen. Though the result would be the same as it catches RuntimeException always, I wonder whether an additional test case would be helpful to verify the IOOBE situation, e.g. set the position to be greater than the length.
>
> Thanks, Joe. Added extra test for IOOBE.

Thanks, Naoto.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16586#discussion_r1391759495

From naoto at openjdk.org  Mon Nov 13 23:40:27 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 23:40:27 GMT
Subject: <i18n dev> RFR: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args [v2]
In-Reply-To: <WSH0q5YRWhKW0dm1iY6XLqHq8yN67S3QLqlBdgamYIg=.ac19c8dc-0922-42d3-9f69-1df370282094@github.com>
References: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
 <WSH0q5YRWhKW0dm1iY6XLqHq8yN67S3QLqlBdgamYIg=.ac19c8dc-0922-42d3-9f69-1df370282094@github.com>
Message-ID: <Kzn9DyeDZVM_HBpcUyg5A93s9okXOD0hEuZupgnAcng=.8d068366-9f5b-4a24-a312-d74e3423e402@github.com>

On Mon, 13 Nov 2023 21:38:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review, one -> any

LGTM. The CSR has also been reviewed.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16624#pullrequestreview-1728451901

From naoto at openjdk.org  Mon Nov 13 23:40:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 23:40:36 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat
Message-ID: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>

Correcting the explanation of the `DateFormat.SHORT` constant.

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

Commit messages:
 - initial commit

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

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

From naoto at openjdk.org  Mon Nov 13 23:45:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 13 Nov 2023 23:45:37 GMT
Subject: <i18n dev> Integrated: 8319640: ClassicFormat::parseObject (from
 DateTimeFormatter) does not conform to the javadoc and may leak
 DateTimeException
In-Reply-To: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
References: <jHMPT71BvdW18s_eBSgKn8csceTWcF-P0evEKQlwqQ0=.309409a5-5704-471a-8fa3-f1eeb3e36774@github.com>
Message-ID: <GO9sDMxZcOIGROB92X1WXiPxQnOmfhUx0VflolgVQaE=.915a5a7e-f90f-46c7-b8f6-42f99c9f32c1@github.com>

On Thu, 9 Nov 2023 17:44:44 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing the `Format::parseObject(String, ParsePosition)` implementation in `DateTimeFormatter` class, to not throw `DateTimeException` but to return null.

This pull request has now been integrated.

Changeset: fe0ccdf5
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fe0ccdf5f8a5559a608d2e2cd2b6aecbe245c5ec
Stats:     50 lines in 2 files changed: 34 ins; 8 del; 8 mod

8319640: ClassicFormat::parseObject (from DateTimeFormatter) does not conform to the javadoc and may leak DateTimeException

Reviewed-by: rriggs, iris, jlu, joehw

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

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

From joehw at openjdk.org  Tue Nov 14 01:45:26 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 14 Nov 2023 01:45:26 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat
In-Reply-To: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
Message-ID: <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com>

On Mon, 13 Nov 2023 23:35:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Correcting the explanation of the `DateFormat.SHORT` constant.

src/java.base/share/classes/java/text/DateFormat.java line 120:

> 118:  * result; from {@link #SHORT} to {@link #MEDIUM} to {@link #LONG} to {@link #FULL}. The exact result depends
> 119:  * on the locale, but generally:
> 120:  * <ul><li>{@link #SHORT} is the shortest and mainly numeric, such as {@code 12.13.52} or {@code 3:30pm}

Not sure if we want to update the descriptions of all options, but if we want to be consistent, here's a suggestion, how about:
  {@link #SHORT} is a concise format using numeric digits, for example, {@code 12.13.52} or {@code 3:30pm}
  {@link #MEDIUM} provides more detail, such as {@code Jan 12, 1952}
  {@link #LONG} is a comprehensive format, such as {@code January 12, 1952} or {@code 3:30:32pm}
  {@link #FULL} provides a complete date representation, such as
  
  "pretty completely" is a bit casual :-)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1391880915

From naoto at openjdk.org  Tue Nov 14 17:16:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 17:16:59 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v2]
In-Reply-To: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
Message-ID: <kevr95eaWRgUJvDsPCkr2Uf18bbHXF8WpTS7jOhML-w=.29dfe285-6205-4975-a8ef-f3f0d80d8e76@github.com>

> Correcting the explanation of the `DateFormat.SHORT` constant.

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/16645/files
  - new: https://git.openjdk.org/jdk/pull/16645/files/2c9243a9..b5c33cc5

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

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

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

From naoto at openjdk.org  Tue Nov 14 17:17:02 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 17:17:02 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v2]
In-Reply-To: <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com>
Message-ID: <BzVpGGakpuq-VWeQfENowyHm26AO3Rgeci_94i129zU=.6a38d6b4-0f41-4f4e-b65d-5328ead05627@github.com>

On Tue, 14 Nov 2023 01:41:15 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/text/DateFormat.java line 120:
> 
>> 118:  * result; from {@link #SHORT} to {@link #MEDIUM} to {@link #LONG} to {@link #FULL}. The exact result depends
>> 119:  * on the locale, but generally:
>> 120:  * <ul><li>{@link #SHORT} is the shortest and mainly numeric, such as {@code 12.13.52} or {@code 3:30pm}
> 
> Not sure if we want to update the descriptions of all options, but if we want to be consistent, here's a suggestion, how about:
>   {@link #SHORT} is a concise format using numeric digits, for example, {@code 12.13.52} or {@code 3:30pm}
>   {@link #MEDIUM} provides more detail, such as {@code Jan 12, 1952}
>   {@link #LONG} is a comprehensive format, such as {@code January 12, 1952} or {@code 3:30:32pm}
>   {@link #FULL} provides a complete date representation, such as
>   
>   "pretty completely" is a bit casual :-)

Thanks for the feedback, Joe. I think I would rather keep the description somewhat abstract, simply mentioning the formatted output is `SHORT` <= `MEDIUM` <= `LONG` <= `FULL` in length-wise. As it is noted in the previous sentence, it is pretty much locale-dependent.
I simply replaced that casual wording with "the longest" for consistency.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1392948818

From jlu at openjdk.org  Tue Nov 14 17:46:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Nov 2023 17:46:31 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v2]
In-Reply-To: <kevr95eaWRgUJvDsPCkr2Uf18bbHXF8WpTS7jOhML-w=.29dfe285-6205-4975-a8ef-f3f0d80d8e76@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <kevr95eaWRgUJvDsPCkr2Uf18bbHXF8WpTS7jOhML-w=.29dfe285-6205-4975-a8ef-f3f0d80d8e76@github.com>
Message-ID: <JThM6Gi0XZpu49XhA8TFm6Whw_A2FkvcaAS8uEp2SVQ=.2fde1f88-8208-4027-a229-c78275d5c611@github.com>

On Tue, 14 Nov 2023 17:16:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflects review comments

src/java.base/share/classes/java/text/DateFormat.java line 122:

> 120:  * <ul><li>{@link #SHORT} is the shortest and mainly numeric, such as {@code 12.13.52} or {@code 3:30pm}
> 121:  * <li>{@link #MEDIUM} is longer, such as {@code Jan 12, 1952}
> 122:  * <li>{@link #LONG} is longer, such as {@code January 12, 1952} or {@code 3:30:32pm}

Does it make sense to change LONG to "_is even longer_" or "_is longer than MEDIUM_"?

Still keeps it abstract but clarifies it a little more IMO (and should still hold true regardless of locale)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1392996202

From naoto at openjdk.org  Tue Nov 14 17:52:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 17:52:45 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v2]
In-Reply-To: <JThM6Gi0XZpu49XhA8TFm6Whw_A2FkvcaAS8uEp2SVQ=.2fde1f88-8208-4027-a229-c78275d5c611@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <kevr95eaWRgUJvDsPCkr2Uf18bbHXF8WpTS7jOhML-w=.29dfe285-6205-4975-a8ef-f3f0d80d8e76@github.com>
 <JThM6Gi0XZpu49XhA8TFm6Whw_A2FkvcaAS8uEp2SVQ=.2fde1f88-8208-4027-a229-c78275d5c611@github.com>
Message-ID: <G_DCGa6T28XKGUGnbGwOmmZBSfSZ-McD7mEs4GfqSLI=.5e94c8b5-176e-489c-8f58-e5215fb6d63a@github.com>

On Tue, 14 Nov 2023 17:43:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reflects review comments
>
> src/java.base/share/classes/java/text/DateFormat.java line 122:
> 
>> 120:  * <ul><li>{@link #SHORT} is the shortest and mainly numeric, such as {@code 12.13.52} or {@code 3:30pm}
>> 121:  * <li>{@link #MEDIUM} is longer, such as {@code Jan 12, 1952}
>> 122:  * <li>{@link #LONG} is longer, such as {@code January 12, 1952} or {@code 3:30:32pm}
> 
> Does it make sense to change LONG to "_is even longer_" or "_is longer than MEDIUM_"?
> 
> Still keeps it abstract but clarifies it a little more IMO (and should still hold true regardless of locale)

Good point. Replaced as suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1393006111

From naoto at openjdk.org  Tue Nov 14 17:52:43 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 17:52:43 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v3]
In-Reply-To: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
Message-ID: <ICsg0tzWrYb2ASGhgt-10cbhZ2PN0CUm2uEaArmJ_SI=.b6346cfc-3df9-4a13-ae0d-1089593642ba@github.com>

> Correcting the explanation of the `DateFormat.SHORT` constant.

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

  Further clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16645/files
  - new: https://git.openjdk.org/jdk/pull/16645/files/b5c33cc5..47fa6c42

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

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

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

From rriggs at openjdk.org  Tue Nov 14 18:17:28 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Nov 2023 18:17:28 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v3]
In-Reply-To: <BzVpGGakpuq-VWeQfENowyHm26AO3Rgeci_94i129zU=.6a38d6b4-0f41-4f4e-b65d-5328ead05627@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com>
 <BzVpGGakpuq-VWeQfENowyHm26AO3Rgeci_94i129zU=.6a38d6b4-0f41-4f4e-b65d-5328ead05627@github.com>
Message-ID: <yeMhOEUZWUBOHp6CxdyJGXr7hJwOnVM8wxqxe0zMBqI=.6ce01f59-8968-4bb7-96a5-b189ef56c2bc@github.com>

On Tue, 14 Nov 2023 17:14:06 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/text/DateFormat.java line 120:
>> 
>>> 118:  * result; from {@link #SHORT} to {@link #MEDIUM} to {@link #LONG} to {@link #FULL}. The exact result depends
>>> 119:  * on the locale, but generally:
>>> 120:  * <ul><li>{@link #SHORT} is the shortest and mainly numeric, such as {@code 12.13.52} or {@code 3:30pm}
>> 
>> Not sure if we want to update the descriptions of all options, but if we want to be consistent, here's a suggestion, how about:
>>   {@link #SHORT} is a concise format using numeric digits, for example, {@code 12.13.52} or {@code 3:30pm}
>>   {@link #MEDIUM} provides more detail, such as {@code Jan 12, 1952}
>>   {@link #LONG} is a comprehensive format, such as {@code January 12, 1952} or {@code 3:30:32pm}
>>   {@link #FULL} provides a complete date representation, such as
>>   
>>   "pretty completely" is a bit casual :-)
>
> Thanks for the feedback, Joe. I think I would rather keep the description somewhat abstract, simply mentioning the formatted output is `SHORT` <= `MEDIUM` <= `LONG` <= `FULL` in length-wise. As it is noted in the previous sentence, it is pretty much locale-dependent.
> I simply replaced that casual wording with "the longest" for consistency.

Is there any value in mentioning that MEDIUM format typically uses abbreviations.
Whereas the LONG and FULL format typically does not use abbreviations.  (For months)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1393041408

From naoto at openjdk.org  Tue Nov 14 19:32:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 19:32:57 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
Message-ID: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>

> Correcting the explanation of the `DateFormat.SHORT` constant.

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

  abbreviated/full clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16645/files
  - new: https://git.openjdk.org/jdk/pull/16645/files/47fa6c42..523fcf30

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

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

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

From naoto at openjdk.org  Tue Nov 14 19:32:58 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 14 Nov 2023 19:32:58 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <yeMhOEUZWUBOHp6CxdyJGXr7hJwOnVM8wxqxe0zMBqI=.6ce01f59-8968-4bb7-96a5-b189ef56c2bc@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <8GdRmjvKIH0rjG6uP98UpaIGnl1qrYRKu74narYg0c4=.445ac7c3-fe57-41d4-9886-0e53c7e46bbb@github.com>
 <BzVpGGakpuq-VWeQfENowyHm26AO3Rgeci_94i129zU=.6a38d6b4-0f41-4f4e-b65d-5328ead05627@github.com>
 <yeMhOEUZWUBOHp6CxdyJGXr7hJwOnVM8wxqxe0zMBqI=.6ce01f59-8968-4bb7-96a5-b189ef56c2bc@github.com>
Message-ID: <zZ-fLPjfqpO9-yv4geG0LhcpqVh8bawCV1DZnKgFcqs=.05d0f0b8-ac2f-4dfe-bd87-a1f14d45a1e6@github.com>

On Tue, 14 Nov 2023 18:14:45 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Thanks for the feedback, Joe. I think I would rather keep the description somewhat abstract, simply mentioning the formatted output is `SHORT` <= `MEDIUM` <= `LONG` <= `FULL` in length-wise. As it is noted in the previous sentence, it is pretty much locale-dependent.
>> I simply replaced that casual wording with "the longest" for consistency.
>
> Is there any value in mentioning that MEDIUM format typically uses abbreviations.
> Whereas the LONG and FULL format typically does not use abbreviations.  (For months)

Added a sentence explaining it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16645#discussion_r1393160341

From joehw at openjdk.org  Tue Nov 14 20:00:31 2023
From: joehw at openjdk.org (Joe Wang)
Date: Tue, 14 Nov 2023 20:00:31 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
Message-ID: <nJhVJzmwypsLn981ZkRbU1WNmaWxDLYvqFxBRUJ9Tg0=.002756f8-5540-419e-8636-cfd35bb8c3b3@github.com>

On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   abbreviated/full clarification

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16645#pullrequestreview-1730654925

From rriggs at openjdk.org  Tue Nov 14 20:28:31 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 14 Nov 2023 20:28:31 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
Message-ID: <MeCpFF9StBMZDLDU8TjVLAIFqc8IEzcX1Fl-rA4HSoo=.0c072a13-e1e7-4d8c-9ec9-6ebd3e1337cb@github.com>

On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   abbreviated/full clarification

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16645#pullrequestreview-1730712231

From jlu at openjdk.org  Tue Nov 14 20:55:30 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Nov 2023 20:55:30 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
Message-ID: <_2yP9Kn5CcxLi7wh5eQcvUnnl-f1VrWsnYWOVnDy99I=.9b362752-02ee-48fc-aa4e-5bb4fa4f8e19@github.com>

On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   abbreviated/full clarification

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/16645#pullrequestreview-1730767526

From iris at openjdk.org  Tue Nov 14 20:59:31 2023
From: iris at openjdk.org (Iris Clark)
Date: Tue, 14 Nov 2023 20:59:31 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
Message-ID: <qeWUb8nhrryXpKCugGgOn1IJpPRz1hRALGngmmsGXn4=.bf2db68d-4da1-4a97-bff8-1da22f2e7199@github.com>

On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   abbreviated/full clarification

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16645#pullrequestreview-1730777438

From lancea at openjdk.org  Tue Nov 14 21:13:31 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 14 Nov 2023 21:13:31 GMT
Subject: <i18n dev> RFR: 8319986: Invalid/inconsistent description and
 example for DateFormat [v4]
In-Reply-To: <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
 <LEsWMKaoxhWFgF58Du8Z8wi2PZZlfClNx4Yf3ehwHMs=.64eb1fa7-430d-4f52-9786-0ddc34b4e2c4@github.com>
Message-ID: <Z4XQxYIj0yjmnuVzPyXvaSlVp-ngh7fM85lu9wcjAfQ=.112216f3-da37-4c87-a89b-6de790b5cb74@github.com>

On Tue, 14 Nov 2023 19:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Correcting the explanation of the `DateFormat.SHORT` constant.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   abbreviated/full clarification

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16645#pullrequestreview-1730811132

From jlu at openjdk.org  Tue Nov 14 23:40:38 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 14 Nov 2023 23:40:38 GMT
Subject: <i18n dev> Integrated: JDK-8319628: DateFormat does not mention
 IllegalArgumentException for invalid style args
In-Reply-To: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
References: <JJuGyuaLv0f6zYc5ke65Ackpt6Lx3KI2VsOtJm-s5w4=.0fafed58-2771-4010-ab26-fcc394174a40@github.com>
Message-ID: <tbsLjnIObOiZm_DFsXBTec7Fb5t6qOPNCxwjquGJLgc=.1f198d62-ed58-45f5-9dae-7e94301b5673@github.com>

On Sun, 12 Nov 2023 21:39:29 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8319868) which makes IllegalArgumentExceptions apparent for the _j.text.DateFormat_ static factory methods that have the _style_ parameter.

This pull request has now been integrated.

Changeset: d5abe496
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d5abe49670d81b9c4749ce777ed6bf2886228f2f
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8319628: DateFormat does not mention IllegalArgumentException for invalid style args

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Wed Nov 15 18:54:41 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 15 Nov 2023 18:54:41 GMT
Subject: <i18n dev> Integrated: 8319986: Invalid/inconsistent description
 and example for DateFormat
In-Reply-To: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
References: <fKGE3rVwv2d9Gl5qvMrISmvzkR0lGJd1SNESw0s7Ivo=.90d01877-ff6a-4f04-a747-d33274692185@github.com>
Message-ID: <I31TF5Bungb8la--vfkQtqpftsbMPqe2w_BuDYDXIMw=.7e108a0f-16fa-47c3-87af-a79d84c06928@github.com>

On Mon, 13 Nov 2023 23:35:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Correcting the explanation of the `DateFormat.SHORT` constant.

This pull request has now been integrated.

Changeset: 891d8cfa
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/891d8cfaf2fc0636bfe8f864cd010fb71266d723
Stats:     5 lines in 1 file changed: 2 ins; 0 del; 3 mod

8319986: Invalid/inconsistent description and example for DateFormat

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

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

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

From aturbanov at openjdk.org  Thu Nov 16 08:56:09 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Nov 2023 08:56:09 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <feIF4cRqXWoUrif0H9jOGuTbBmweQ5joSmBWSoqg1tA=.8af125cf-035c-453d-add8-78945701de38@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <feIF4cRqXWoUrif0H9jOGuTbBmweQ5joSmBWSoqg1tA=.8af125cf-035c-453d-add8-78945701de38@github.com>
Message-ID: <Dq4rVqxriN5mlpElQIW3-fweMG5ShYSLilsDjDKG5hA=.8f0bbdf8-f145-4f63-b031-2305ae61e01d@github.com>

On Mon, 13 Nov 2023 11:40:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316557: Make fields final in 'sun.util' package
>>   
>>   rename 'firstDay' to 'firstDays' to match 'minDays' naming
>
> src/java.base/share/classes/sun/util/cldr/CLDRCalendarDataProviderImpl.java line 48:
> 
>> 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl {
>> 47: 
>> 48:     private static final Map<String, Integer> firstDay = new ConcurrentHashMap<>();
> 
> We might rename these fields to FIRST_DAY etc.

Hm. Usually CAPS naming is used only on immutable constants, but here we have mutable field. (See google style guide for example - https://google.github.io/styleguide/javaguide.html#s5.2.4-constant-names).
I like old naming approach.

> src/java.base/share/classes/sun/util/locale/LocaleObjectCache.java line 102:
> 
>> 100:     }
>> 101: 
>> 102:     private static class CacheEntry<K, V> extends SoftReference<V> {
> 
> The class itself might be `final`

I think making classes `final` is out of scope of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1395350055
PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1395351993

From aturbanov at openjdk.org  Thu Nov 16 08:56:05 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Nov 2023 08:56:05 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8316557: Make fields final in 'sun.util' package
  
  rename 'firstDay' to 'firstDays' to match 'minDays' naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15736/files
  - new: https://git.openjdk.org/jdk/pull/15736/files/26d00dcb..5db74105

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

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

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

From naoto at openjdk.org  Thu Nov 16 17:11:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 16 Nov 2023 17:11:36 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>
Message-ID: <FHNsmvsjSiuX5Y-1qfnWwwxc43TXP90r41dX14calgE=.0ad19249-7e5a-4b4a-ab33-e338c44806a4@github.com>

On Thu, 16 Nov 2023 08:56:05 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316557: Make fields final in 'sun.util' package
>   
>   rename 'firstDay' to 'firstDays' to match 'minDays' naming

Changes requested by naoto (Reviewer).

src/java.base/share/classes/sun/util/cldr/CLDRCalendarDataProviderImpl.java line 48:

> 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl {
> 47: 
> 48:     private static final Map<String, Integer> firstDays = new ConcurrentHashMap<>();

I don't think this is correct. "First Day" is the first day of the week and should not be plural.

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

PR Review: https://git.openjdk.org/jdk/pull/15736#pullrequestreview-1734986993
PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1396065609

From aturbanov at openjdk.org  Thu Nov 16 18:11:48 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Nov 2023 18:11:48 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v3]
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <6BYQo_0wJ_3VbwbNNkRrbyAjXTa1lTKyp8Gbbwhospc=.b98239a4-c940-463b-bdd2-972837123bf9@github.com>

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:

  8316557: Make fields final in 'sun.util' package
  
  "First Day" is the first day of the week and should not be plural

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/15736/files
  - new: https://git.openjdk.org/jdk/pull/15736/files/5db74105..2c9b4edc

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

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

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

From jlaskey at openjdk.org  Thu Nov 16 19:09:57 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Thu, 16 Nov 2023 19:09:57 GMT
Subject: <i18n dev> RFR: JDK-8315457 Implementation of String Templates
 (Second Preview) [v7]
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <tNRC8M90OEzk0NTfaV1JKBFOF00xqoQMymh_ZfD5tOs=.a375c665-53ce-4fac-bdb5-81995a755ce0@github.com>

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

Jim Laskey 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 ten additional commits since the last revision:

 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Remove preview from JavaLangAccess
 - Merge remote-tracking branch 'upstream/master' into 8315457
 - Cache process method type in JCStringTemplate
 - Revert source
 - Revert @since 22
 - Accept qualified STR and RAW
 - String Templates (second preview)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16202/files
  - new: https://git.openjdk.org/jdk/pull/16202/files/c616f48e..c798e310

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

  Stats: 624014 lines in 1051 files changed: 85405 ins; 477079 del; 61530 mod
  Patch: https://git.openjdk.org/jdk/pull/16202.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16202/head:pull/16202

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

From duke at openjdk.org  Fri Nov 17 01:56:41 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Fri, 17 Nov 2023 01:56:41 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v6]
In-Reply-To: <UCCRUuk-_GQJYVZqQMAT-Ta_6tXHuFx8C4XgW-G31d4=.b2c84bb2-f1d2-4053-a0fe-61b523a1b2d2@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <ER5JOuQ_n5PmPeHgkBidaWtIGUv3_RVaxM8BTtoj9XI=.8495d993-9d16-496e-afcf-81e17be5f386@github.com>
 <UCCRUuk-_GQJYVZqQMAT-Ta_6tXHuFx8C4XgW-G31d4=.b2c84bb2-f1d2-4053-a0fe-61b523a1b2d2@github.com>
Message-ID: <PwJdcFFrcFc9AeTPeOWlK6fEwtZoCSPslSo3kM69c6s=.b3fd6af7-d2c6-4717-9062-d9aa372c10a2@github.com>

On Thu, 9 Nov 2023 17:15:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use minus sign from cached DecimalFormatSymbols and improved testcase
>
> Looks like your fix causes a regression test failure in test/jdk/java/time/test/java/util/TestFormatter.java
> 
> ----------System.out:(1097/72894)----------
> test test.java.util.TestFormatter.test("en_US"): success
> test test.java.util.TestFormatter.test("th_TH"): success
> ChronoZonedDateTimeImpl(Japanese)  actual: D:[04/19/05] F:[2023-04-19]
>                 FAILED; expected: D:[04/19/05] F:[0005-04-19]
> java.lang.RuntimeException
> 	at test.java.util.TestFormatter.test(TestFormatter.java:198)
> 	at test.java.util.TestFormatter.testDate(TestFormatter.java:216)
> 	at test.java.util.TestFormatter.test(TestFormatter.java:114)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:132)
> 	at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:599)
> 	at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:174)
> 	at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
> 	at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:822)
> 	at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:147)
> 	at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
> 	at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
> 	at java.base/java.util.ArrayList.forEach(ArrayList.java:1597)
> 	at org.testng.TestRunner.privateRun(TestRunner.java:764)
> 	at org.testng.TestRunner.run(TestRunner.java:585)
> 	at org.testng.SuiteRunner.runTest(SuiteRunner.java:384)
> 	at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:378)
> 	at org.testng.SuiteRunner.privateRun(SuiteRunner.java:337)
> 	at org.testng.SuiteRunner.run(SuiteRunner.java:286)
> 	at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
> 	at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
> 	at org.testng.TestNG.runSuitesSequentially(TestNG.java:1218)
> 	at org.testng.TestNG.runSuitesLocally(TestNG.java:1140)
> 	at org.testng.TestNG.runSuites(TestNG.java:1069)
> 	at org.testng.TestNG.run(TestNG.java:1037)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102)
> 	at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:58)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at com...

@naotoj  @RogerRiggs Can it be integrated?

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1815623419

From pminborg at openjdk.org  Fri Nov 17 08:15:38 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 17 Nov 2023 08:15:38 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <FHNsmvsjSiuX5Y-1qfnWwwxc43TXP90r41dX14calgE=.0ad19249-7e5a-4b4a-ab33-e338c44806a4@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>
 <FHNsmvsjSiuX5Y-1qfnWwwxc43TXP90r41dX14calgE=.0ad19249-7e5a-4b4a-ab33-e338c44806a4@github.com>
Message-ID: <k1ymgYRbUUL4HHc8qrUF30N0mlCM8JixxAz0QBXXNhY=.14b27b2d-bca3-40bb-ac9a-74bba4701449@github.com>

On Thu, 16 Nov 2023 17:08:58 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8316557: Make fields final in 'sun.util' package
>>   
>>   rename 'firstDay' to 'firstDays' to match 'minDays' naming
>
> src/java.base/share/classes/sun/util/cldr/CLDRCalendarDataProviderImpl.java line 48:
> 
>> 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl {
>> 47: 
>> 48:     private static final Map<String, Integer> firstDays = new ConcurrentHashMap<>();
> 
> I don't think this is correct. "First Day" is the first day of the week and should not be plural.

The map contains several entries so I think the plural form is appropriate here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1396844057

From aturbanov at openjdk.org  Fri Nov 17 08:41:35 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 17 Nov 2023 08:41:35 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <k1ymgYRbUUL4HHc8qrUF30N0mlCM8JixxAz0QBXXNhY=.14b27b2d-bca3-40bb-ac9a-74bba4701449@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>
 <FHNsmvsjSiuX5Y-1qfnWwwxc43TXP90r41dX14calgE=.0ad19249-7e5a-4b4a-ab33-e338c44806a4@github.com>
 <k1ymgYRbUUL4HHc8qrUF30N0mlCM8JixxAz0QBXXNhY=.14b27b2d-bca3-40bb-ac9a-74bba4701449@github.com>
Message-ID: <Aai-8L_DNE1yP0JoglLiFbqHD2RFDBI6p35y__AoTrM=.7f67613d-0198-432d-8d5f-250151e65ffb@github.com>

On Fri, 17 Nov 2023 08:13:05 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/sun/util/cldr/CLDRCalendarDataProviderImpl.java line 48:
>> 
>>> 46: public class CLDRCalendarDataProviderImpl extends CalendarDataProviderImpl {
>>> 47: 
>>> 48:     private static final Map<String, Integer> firstDays = new ConcurrentHashMap<>();
>> 
>> I don't think this is correct. "First Day" is the first day of the week and should not be plural.
>
> The map contains several entries so I think the plural form is appropriate here.

Current naming highlights the difference in values in this maps: `FIRST_DAY_OF_WEEK` vs `MINIMAL_DAYS_IN_FIRST_WEEK`.
I like this approach.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1396868339

From jlu at openjdk.org  Fri Nov 17 09:32:53 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Nov 2023 09:32:53 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags.
Message-ID: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>

Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,

This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.

_PropertiesTest.sh_ was updated with `@requires vm.flagless`.

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

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/16705/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16705&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319569
  Stats: 183 lines in 12 files changed: 25 ins; 41 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/16705.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16705/head:pull/16705

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

From jlaskey at openjdk.org  Fri Nov 17 12:56:43 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Fri, 17 Nov 2023 12:56:43 GMT
Subject: <i18n dev> Integrated: JDK-8315457 Implement JEP 459: String
 Templates (Second Preview)
In-Reply-To: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
References: <FnJQU5StZikm5yxmypr370X-UqYZ7zhCCuo-ekA-yPA=.0a9d732f-9198-43e9-9dba-9e8d52652284@github.com>
Message-ID: <AXuNMbf6szyhaTS6Lgj2s0vjAKrlKDACx3T8-D1SDOA=.57683ed1-04a6-4608-b0e2-a04ae49ad3b0@github.com>

On Mon, 16 Oct 2023 13:41:55 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Update String Templates for a second preview. With the addition of
> 
> - Expression type and throws are determined from the `process` method of the processor type and not the processor type.
> 
> - Qualified `STR` and `RAW` are treated the same as unqualified `STR` and `RAW` .
> 
> - Raw (generic) process types are no longer an error.

This pull request has now been integrated.

Changeset: 9902d2eb
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9902d2eb177072c108933056cba544cc5a34bb54
Stats:     69 lines in 16 files changed: 19 ins; 35 del; 15 mod

8315457: Implement JEP 459: String Templates (Second Preview)

Reviewed-by: jlahoda, alanb, vromero

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

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

From naoto at openjdk.org  Fri Nov 17 18:07:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 18:07:32 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v2]
In-Reply-To: <Aai-8L_DNE1yP0JoglLiFbqHD2RFDBI6p35y__AoTrM=.7f67613d-0198-432d-8d5f-250151e65ffb@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <Bz3oR_rxWbej1JlETwaT11ZKeA613X1D3K8HuSgL_CI=.2941fbd3-7cb2-44a4-a1b0-94fb0b1eda89@github.com>
 <FHNsmvsjSiuX5Y-1qfnWwwxc43TXP90r41dX14calgE=.0ad19249-7e5a-4b4a-ab33-e338c44806a4@github.com>
 <k1ymgYRbUUL4HHc8qrUF30N0mlCM8JixxAz0QBXXNhY=.14b27b2d-bca3-40bb-ac9a-74bba4701449@github.com>
 <Aai-8L_DNE1yP0JoglLiFbqHD2RFDBI6p35y__AoTrM=.7f67613d-0198-432d-8d5f-250151e65ffb@github.com>
Message-ID: <MjgBeAflqLzIBj2bWJw8ijGooAS0_AgUkItSplO9HtE=.589bc9b8-0072-4de8-a370-e18907316c83@github.com>

On Fri, 17 Nov 2023 08:38:37 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> The map contains several entries so I think the plural form is appropriate here.
>
> Current naming highlights the difference in values in this maps: `FIRST_DAY_OF_WEEK` vs `MINIMAL_DAYS_IN_FIRST_WEEK`.
> I like this approach.

Maybe `firstDayMap`/`minDaysMap` would clarify more, but either way is fine with me

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

PR Review Comment: https://git.openjdk.org/jdk/pull/15736#discussion_r1397697691

From naoto at openjdk.org  Fri Nov 17 19:49:33 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 19:49:33 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags.
In-Reply-To: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
Message-ID: <RLhBkfpuXAsuWj42oTgwIa-KOao-Wz5z8kiTHHqNxT0=.116c1b04-dbbd-4487-8d16-18b6b9a43c3f@github.com>

On Fri, 17 Nov 2023 09:25:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
> 
> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.
> 
> _PropertiesTest.sh_ was updated with `@requires vm.flagless`.

test/jdk/java/util/Currency/PropertiesTest.sh line 30:

> 28: # @summary tests the capability of replacing the currency data with user
> 29: #     specified currency properties file
> 30: # @requires vm.flagless

Does this actually do anything? Since it is a shell script, it does not call any `ProcessBuilder` methods. In fact, the script includes `${TESTVMOPTS}` on launching the test java process correctly.

test/jdk/java/util/logging/LoggingDeadlock2.java line 167:

> 165: 
> 166:    private static final List<String> javaChildArgs = Arrays.asList(
> 167:        "-classpath", classpath, "LoggingDeadlock2$JavaChild");

Could use `List.of()`

test/jdk/java/util/zip/EntryCount64k.java line 3:

> 1: /*
> 2:  * Copyright (c) 2013 Google Inc. All rights reserved.
> 3:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.

Is this OK? The header reads `DO NOT ALTER`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397786626
PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397796561
PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397797865

From jlu at openjdk.org  Fri Nov 17 20:20:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Nov 2023 20:20:43 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags. [v2]
In-Reply-To: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
Message-ID: <8rH8ig7VH--LUeng8Kxp1tyHaJ09F2clpU22hMkmXJQ=.ccca251a-60cf-49e6-8995-071412195ace@github.com>

> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
> 
> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.
> 
> _PropertiesTest.sh_ was updated with `@requires vm.flagless`.

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

  reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16705/files
  - new: https://git.openjdk.org/jdk/pull/16705/files/e6a72c4c..30c735d5

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

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

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

From jlu at openjdk.org  Fri Nov 17 20:20:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 17 Nov 2023 20:20:47 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags. [v2]
In-Reply-To: <RLhBkfpuXAsuWj42oTgwIa-KOao-Wz5z8kiTHHqNxT0=.116c1b04-dbbd-4487-8d16-18b6b9a43c3f@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
 <RLhBkfpuXAsuWj42oTgwIa-KOao-Wz5z8kiTHHqNxT0=.116c1b04-dbbd-4487-8d16-18b6b9a43c3f@github.com>
Message-ID: <3eJZlzFtYI1_j5l2ZCccMC-4iXFFBAKZZxRM3SR9YuE=.a5477211-fc86-420c-85b8-750718614b4d@github.com>

On Fri, 17 Nov 2023 19:36:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review comments
>
> test/jdk/java/util/Currency/PropertiesTest.sh line 30:
> 
>> 28: # @summary tests the capability of replacing the currency data with user
>> 29: #     specified currency properties file
>> 30: # @requires vm.flagless
> 
> Does this actually do anything? Since it is a shell script, it does not call any `ProcessBuilder` methods. In fact, the script includes `${TESTVMOPTS}` on launching the test java process correctly.

IIUC, using `@requires vm.flagless` simply signifies that any JVMs launched within the test do not support VM flags, (regardless if it was launched from ProcessBuilder).

However, it is odd that this test was flagged since it does pass `${TESTVMOPTS}` to `run()` like you stated. 

Perhaps @lmesnik has further understanding of what to do here?

> test/jdk/java/util/logging/LoggingDeadlock2.java line 167:
> 
>> 165: 
>> 166:    private static final List<String> javaChildArgs = Arrays.asList(
>> 167:        "-classpath", classpath, "LoggingDeadlock2$JavaChild");
> 
> Could use `List.of()`

Fixed here and in other instances.

> test/jdk/java/util/zip/EntryCount64k.java line 3:
> 
>> 1: /*
>> 2:  * Copyright (c) 2013 Google Inc. All rights reserved.
>> 3:  * Copyright (c) 2023, Oracle and/or its affiliates. All rights reserved.
> 
> Is this OK? The header reads `DO NOT ALTER`.

Yes, I think you're right. I based my decision off https://github.com/openjdk/jdk/pull/15454

But after reading the copyright guidelines, we do not modify third party copyright. It should probably be removed in that test as well.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397843189
PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397843173
PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1397843159

From naoto at openjdk.org  Fri Nov 17 20:33:32 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 20:33:32 GMT
Subject: <i18n dev> RFR: 8316557: Make fields final in 'sun.util'
 package [v3]
In-Reply-To: <6BYQo_0wJ_3VbwbNNkRrbyAjXTa1lTKyp8Gbbwhospc=.b98239a4-c940-463b-bdd2-972837123bf9@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
 <6BYQo_0wJ_3VbwbNNkRrbyAjXTa1lTKyp8Gbbwhospc=.b98239a4-c940-463b-bdd2-972837123bf9@github.com>
Message-ID: <E7OO2xG3zPSkEt4KL9D-YfUKuQd6t2wIIwAdECzO3A8=.97aecbc6-3d6c-484d-9140-3c7c7a49f0be@github.com>

On Thu, 16 Nov 2023 18:11:48 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8316557: Make fields final in 'sun.util' package
>   
>   "First Day" is the first day of the week and should not be plural

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15736#pullrequestreview-1737870814

From naoto at openjdk.org  Fri Nov 17 21:17:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 21:17:36 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
Message-ID: <SvBbu8IbruCXEPKDaIrrrZjM3zabj8N_VrcIYIIocaw=.da5ae6f1-23c2-4076-b445-e4489b6cc3ee@github.com>

On Fri, 10 Nov 2023 03:31:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix format 'ja-JP-u-ca-japanese' ChronoLocalDate

I'll take another look at your latest changes and tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/16033#issuecomment-1817114636

From rriggs at openjdk.org  Fri Nov 17 22:19:38 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 17 Nov 2023 22:19:38 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
Message-ID: <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>

On Fri, 10 Nov 2023 03:31:26 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix format 'ja-JP-u-ca-japanese' ChronoLocalDate

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

> 4505:                             || t instanceof LocalDateTime
> 4506:                             || t instanceof LocalDate) {
> 4507:                         yearField = ChronoField.YEAR;

This enumeration of type doesn't seem very principled and may not be correct for an arbitrary Temporal.
(But so far, I don't have a better suggestion).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1397946102

From naoto at openjdk.org  Fri Nov 17 23:01:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 23:01:34 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
Message-ID: <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>

On Fri, 17 Nov 2023 22:16:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix format 'ja-JP-u-ca-japanese' ChronoLocalDate
>
> src/java.base/share/classes/java/util/Formatter.java line 4507:
> 
>> 4505:                             || t instanceof LocalDateTime
>> 4506:                             || t instanceof LocalDate) {
>> 4507:                         yearField = ChronoField.YEAR;
> 
> This enumeration of type doesn't seem very principled and may not be correct for an arbitrary Temporal.
> (But so far, I don't have a better suggestion).

Haven't tried, but I think `t.getChronology() instanceof IsoChronology` should work

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1397972898

From naoto at openjdk.org  Fri Nov 17 23:38:35 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 17 Nov 2023 23:38:35 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
 <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
Message-ID: <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>

On Fri, 17 Nov 2023 22:58:00 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Formatter.java line 4507:
>> 
>>> 4505:                             || t instanceof LocalDateTime
>>> 4506:                             || t instanceof LocalDate) {
>>> 4507:                         yearField = ChronoField.YEAR;
>> 
>> This enumeration of type doesn't seem very principled and may not be correct for an arbitrary Temporal.
>> (But so far, I don't have a better suggestion).
>
> Haven't tried, but I think `t.getChronology() instanceof IsoChronology` should work

Now I tried and it didn't compile ? It should have been `t.query(TemporalQueries.chronology()) instanceof IsoChronology`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1397992697

From duke at openjdk.org  Sat Nov 18 14:13:46 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 18 Nov 2023 14:13:46 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v9]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <A6zW-hXBiTk009_gBzL0ZT1ajIUiwWEUdNhw5ojUb0k=.fa9ea186-2218-461c-bd61-05c798b08fee@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  use t.query(TemporalQueries.chronology()) instanceof IsoChronology

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/4e518b39..bacb6c2e

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

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

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

From rriggs at openjdk.org  Sat Nov 18 14:59:33 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 18 Nov 2023 14:59:33 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
 <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
 <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>
Message-ID: <SrxPUu1LjlIpk26kS-VcwULKKAl1fwmes_ci9LEOQy4=.3911cac3-02e6-4390-9788-4ac2c32870be@github.com>

On Fri, 17 Nov 2023 23:35:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Haven't tried, but I think `t.getChronology() instanceof IsoChronology` should work
>
> Now I tried and it didn't compile ? It should have been `t.query(TemporalQueries.chronology()) instanceof IsoChronology`

JapaneseChronology is an IsoChronology so run the test again (before committing) to make sure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1398222416

From duke at openjdk.org  Sat Nov 18 17:38:48 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sat, 18 Nov 2023 17:38:48 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v10]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <yvBky2yt2TiiNji-JpvkS7IpSiVIM9yvTdtNccBxITg=.39cfb33f-0e8c-4349-86ef-f2ca2792d5a0@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  add JapaneseChronology testcase

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/bacb6c2e..0fa1f882

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

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

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

From naoto at openjdk.org  Sun Nov 19 01:54:36 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sun, 19 Nov 2023 01:54:36 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <SrxPUu1LjlIpk26kS-VcwULKKAl1fwmes_ci9LEOQy4=.3911cac3-02e6-4390-9788-4ac2c32870be@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
 <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
 <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>
 <SrxPUu1LjlIpk26kS-VcwULKKAl1fwmes_ci9LEOQy4=.3911cac3-02e6-4390-9788-4ac2c32870be@github.com>
Message-ID: <JjKt40BR2oyH20WhS7zpOnD3iZUNWD6EE-ZsXc1pezI=.a53d6c3e-beaf-486a-97b0-5b33f9d494cb@github.com>

On Sat, 18 Nov 2023 14:56:47 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Now I tried and it didn't compile ? It should have been `t.query(TemporalQueries.chronology()) instanceof IsoChronology`
>
> JapaneseChronology is an IsoChronology so run the test again (before committing) to make sure.

`JapaneseChronology` is not extending `IsoChronology`, and that is the gist of the change I suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1398306647

From duke at openjdk.org  Sun Nov 19 02:22:37 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Sun, 19 Nov 2023 02:22:37 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <JjKt40BR2oyH20WhS7zpOnD3iZUNWD6EE-ZsXc1pezI=.a53d6c3e-beaf-486a-97b0-5b33f9d494cb@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
 <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
 <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>
 <SrxPUu1LjlIpk26kS-VcwULKKAl1fwmes_ci9LEOQy4=.3911cac3-02e6-4390-9788-4ac2c32870be@github.com>
 <JjKt40BR2oyH20WhS7zpOnD3iZUNWD6EE-ZsXc1pezI=.a53d6c3e-beaf-486a-97b0-5b33f9d494cb@github.com>
Message-ID: <hXDLSdpuGZQQnODDR5BTro9PiNfq4Sthd5fc9s94F1k=.8eff7e0d-8f55-4233-8601-3a2430439b34@github.com>

On Sun, 19 Nov 2023 01:52:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> JapaneseChronology is an IsoChronology so run the test again (before committing) to make sure.
>
> `JapaneseChronology` is not extending `IsoChronology`, and that is the gist of the change I suggested.

I added the testcase of IsoChronology and it also passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1398309517

From rriggs at openjdk.org  Mon Nov 20 03:24:39 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 20 Nov 2023 03:24:39 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v8]
In-Reply-To: <hXDLSdpuGZQQnODDR5BTro9PiNfq4Sthd5fc9s94F1k=.8eff7e0d-8f55-4233-8601-3a2430439b34@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <HcFtKFG3JXQlJT5trk_yfD7n-ZyI8CU1H7LQJKG7yl0=.9254120e-8dac-44e4-9700-fb5a4ea6ca30@github.com>
 <OaIKaVHg69YEJB8KbEHdHFXomg4Z1yM_QLJrPJog2tk=.1b8ba016-87f6-4b5f-9793-a552e47581ec@github.com>
 <CyRUYPpsbSsI4N-Y2_xuVkRYImHoA4Xab9GbL3qXTOA=.308ff56c-4680-4f6c-a1c4-924e47426b24@github.com>
 <Kws1vFCq2dIaQT4mTgqIQBNioiTbDXKgpB2MiHkkicg=.fbad8fd0-996b-4199-b3b6-b6ee9af6d659@github.com>
 <SrxPUu1LjlIpk26kS-VcwULKKAl1fwmes_ci9LEOQy4=.3911cac3-02e6-4390-9788-4ac2c32870be@github.com>
 <JjKt40BR2oyH20WhS7zpOnD3iZUNWD6EE-ZsXc1pezI=.a53d6c3e-beaf-486a-97b0-5b33f9d494cb@github.com>
 <hXDLSdpuGZQQnODDR5BTro9PiNfq4Sthd5fc9s94F1k=.8eff7e0d-8f55-4233-8601-3a2430439b34@github.com>
Message-ID: <Zl5c71Y5bh1LGRNU1AlmmdUp-CSKulBoa9ypL7fy5lM=.bbefdd0a-8438-4a77-bf0c-f40d72b05cbe@github.com>

On Sun, 19 Nov 2023 02:19:52 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> `JapaneseChronology` is not extending `IsoChronology`, and that is the gist of the change I suggested.
>
> I added the testcase of IsoChronology and it also passed.

The distinction is pretty subtle, I was referring to the `Chronology.isISOBased()` method. (True for JapaneseChronology).
IsoChronology is final, so there are no subclasses.
This does address the compatibility issue and is an improvement over the original proposal.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16033#discussion_r1398626377

From aturbanov at openjdk.org  Mon Nov 20 09:44:43 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 20 Nov 2023 09:44:43 GMT
Subject: <i18n dev> Integrated: 8316557: Make fields final in 'sun.util'
 package
In-Reply-To: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
References: <mWyB9U0G9mvH6aGPx_5VKY65kS6k6zzW_R_rkSM39OM=.485ec1f0-6c99-4f24-b68b-349d2aba5142@github.com>
Message-ID: <eLVob4PODDmHaqevAn9l-pbxXjJ3p6MvhQKUWszGtik=.190c8b25-ef65-43fa-ace8-a9ec92c9fb20@github.com>

On Thu, 14 Sep 2023 08:58:56 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> A few classes in `sun.util` package have non-final fields which could easily be marked `final`.

This pull request has now been integrated.

Changeset: 6c5e15c1
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6c5e15c1a291ca5ba1e4c3a90351bc71665ce988
Stats:     42 lines in 10 files changed: 2 ins; 13 del; 27 mod

8316557: Make fields final in 'sun.util' package

Reviewed-by: pminborg, naoto

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

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

From dfuchs at openjdk.org  Mon Nov 20 15:30:26 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 20 Nov 2023 15:30:26 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags [v2]
In-Reply-To: <8rH8ig7VH--LUeng8Kxp1tyHaJ09F2clpU22hMkmXJQ=.ccca251a-60cf-49e6-8995-071412195ace@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
 <8rH8ig7VH--LUeng8Kxp1tyHaJ09F2clpU22hMkmXJQ=.ccca251a-60cf-49e6-8995-071412195ace@github.com>
Message-ID: <QA4NDxh-XVL5q4EYXxyUWKpdsBxfbXpJJkLh8TjD4ig=.5ab0ca74-3da2-47d1-8b55-88d58cf1621d@github.com>

On Fri, 17 Nov 2023 20:20:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
>> 
>> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.
>> 
>> _PropertiesTest.sh_ was updated with `@requires vm.flagless`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Changes to the logging tests LGTM. Thanks for the update @justin-curtis-lu .

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

PR Comment: https://git.openjdk.org/jdk/pull/16705#issuecomment-1819284286

From naoto at openjdk.org  Mon Nov 20 18:24:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 Nov 2023 18:24:45 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v10]
In-Reply-To: <yvBky2yt2TiiNji-JpvkS7IpSiVIM9yvTdtNccBxITg=.39cfb33f-0e8c-4349-86ef-f2ca2792d5a0@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
 <yvBky2yt2TiiNji-JpvkS7IpSiVIM9yvTdtNccBxITg=.39cfb33f-0e8c-4349-86ef-f2ca2792d5a0@github.com>
Message-ID: <FYC8fgMfXbgZqwijVf58BnYjBVh-Vw6cQxlf9NBkolE=.77bc2e11-c989-4539-8a59-bd71d17cb912@github.com>

On Sat, 18 Nov 2023 17:38:48 GMT, Shaojin Wen <duke at openjdk.org> wrote:

>> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add JapaneseChronology testcase

Looks good. Thanks for fixing the issue. Please change the copyright year from 2022 to 2023 in the test before integrating.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16033#pullrequestreview-1740431565

From jlu at openjdk.org  Mon Nov 20 19:15:18 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 20 Nov 2023 19:15:18 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags [v3]
In-Reply-To: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
Message-ID: <J5dFrTdV0IER9uijGCDRM05NtxYRIWLlICEpdFDRGmc=.ab48d028-70ad-47ea-b00f-30a761785d38@github.com>

> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
> 
> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.

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

  Pass test.java.opts to PropertiesTest.sh

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16705/files
  - new: https://git.openjdk.org/jdk/pull/16705/files/30c735d5..cb144025

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

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

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

From jlu at openjdk.org  Mon Nov 20 19:15:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 20 Nov 2023 19:15:21 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags [v3]
In-Reply-To: <3eJZlzFtYI1_j5l2ZCccMC-4iXFFBAKZZxRM3SR9YuE=.a5477211-fc86-420c-85b8-750718614b4d@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
 <RLhBkfpuXAsuWj42oTgwIa-KOao-Wz5z8kiTHHqNxT0=.116c1b04-dbbd-4487-8d16-18b6b9a43c3f@github.com>
 <3eJZlzFtYI1_j5l2ZCccMC-4iXFFBAKZZxRM3SR9YuE=.a5477211-fc86-420c-85b8-750718614b4d@github.com>
Message-ID: <wVjr7DfbA5ZlMQB2K2zfSUK_SO9o4PpRNawM1jHKdIg=.cfd41be8-1ad5-4cb5-8499-1a441d3888fe@github.com>

On Fri, 17 Nov 2023 20:17:28 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Currency/PropertiesTest.sh line 30:
>> 
>>> 28: # @summary tests the capability of replacing the currency data with user
>>> 29: #     specified currency properties file
>>> 30: # @requires vm.flagless
>> 
>> Does this actually do anything? Since it is a shell script, it does not call any `ProcessBuilder` methods. In fact, the script includes `${TESTVMOPTS}` on launching the test java process correctly.
>
> IIUC, using `@requires vm.flagless` simply signifies that any JVMs launched within the test do not support VM flags, (regardless if it was launched from ProcessBuilder).
> 
> However, it is odd that this test was flagged since it does pass `${TESTVMOPTS}` to `run()` like you stated. 
> 
> Perhaps @lmesnik has further understanding of what to do here?

_PropertiesTest.sh_ needs to pass both test.vm.opts **and** test.java.opts. Added `${TESTJAVAOPTS}` and unmarked as `@requires vm.flagless`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16705#discussion_r1399629617

From duke at openjdk.org  Mon Nov 20 20:07:25 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Mon, 20 Nov 2023 20:07:25 GMT
Subject: <i18n dev> RFR: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format [v11]
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <KIs-Eze6wZz4BUjcakypjTvEFaqY7uoD6JfdyzKfDdo=.fd8f9ab1-60a7-4909-8669-a631bb8e1d06@github.com>

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

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

  update copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16033/files
  - new: https://git.openjdk.org/jdk/pull/16033/files/0fa1f882..fec8f5e8

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

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

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

From naoto at openjdk.org  Mon Nov 20 22:43:08 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 20 Nov 2023 22:43:08 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags [v3]
In-Reply-To: <J5dFrTdV0IER9uijGCDRM05NtxYRIWLlICEpdFDRGmc=.ab48d028-70ad-47ea-b00f-30a761785d38@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
 <J5dFrTdV0IER9uijGCDRM05NtxYRIWLlICEpdFDRGmc=.ab48d028-70ad-47ea-b00f-30a761785d38@github.com>
Message-ID: <-6v0PdQaHcIUYQS_usNrlAkFyUcW6mzyIakiGBGthk8=.ddeeb5ab-44bc-42cc-bd60-23337bf2b307@github.com>

On Mon, 20 Nov 2023 19:15:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
>> 
>> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass test.java.opts to PropertiesTest.sh

LGTM. It is out of this fix's scope, but `PropertiesTest.sh` may better be converted into a Java test case.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16705#pullrequestreview-1740822747

From duke at openjdk.org  Tue Nov 21 17:03:24 2023
From: duke at openjdk.org (Shaojin Wen)
Date: Tue, 21 Nov 2023 17:03:24 GMT
Subject: <i18n dev> Integrated: 8317742: ISO Standard Date Format
 implementation consistency on DateTimeFormatter and String.format
In-Reply-To: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
References: <R55hw3AwaQjgmwQoTOYEKA2pkK2BqJQuTL7OvcuzMx0=.9daf39be-d366-4f3a-b423-efba6fdbb9ce@github.com>
Message-ID: <CC3kR1FgjsRCN5355wSVvFk5mlRLW3rAz0K98EdFTFw=.ef9097b9-4a73-44af-86a2-141fe2e384c9@github.com>

On Tue, 3 Oct 2023 21:37:46 GMT, Shaojin Wen <duke at openjdk.org> wrote:

> j.u.Formatter now prints "%tF" (iso standard date) and the result is incorrect when processing year < 0 or year > 9999

This pull request has now been integrated.

Changeset: 61d81d64
Author:    Shaojin Wen <shaojin.wensj at alibaba-inc.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/61d81d6496a38e43a6039abc041b67626f06f5c9
Stats:     83 lines in 2 files changed: 81 ins; 0 del; 2 mod

8317742: ISO Standard Date Format implementation consistency on DateTimeFormatter and String.format

Reviewed-by: rriggs, naoto

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

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

From lancea at openjdk.org  Tue Nov 21 19:53:07 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 21 Nov 2023 19:53:07 GMT
Subject: <i18n dev> RFR: JDK-8319569: Several java/util tests should be
 updated to accept VM flags [v3]
In-Reply-To: <J5dFrTdV0IER9uijGCDRM05NtxYRIWLlICEpdFDRGmc=.ab48d028-70ad-47ea-b00f-30a761785d38@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
 <J5dFrTdV0IER9uijGCDRM05NtxYRIWLlICEpdFDRGmc=.ab48d028-70ad-47ea-b00f-30a761785d38@github.com>
Message-ID: <p37GIUrOSU80V7bquQfAaXD65xVqrTtH1JlO1FXgSgo=.21c087b5-0b8a-4ad8-8e9e-52686950c30a@github.com>

On Mon, 20 Nov 2023 19:15:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
>> 
>> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Pass test.java.opts to PropertiesTest.sh

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16705#pullrequestreview-1742959505

From jlu at openjdk.org  Thu Nov 23 00:30:16 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Nov 2023 00:30:16 GMT
Subject: <i18n dev> Integrated: JDK-8319569: Several java/util tests should
 be updated to accept VM flags
In-Reply-To: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
References: <jtukQvrOtL7w2K2zijm_YJLUMPTWMLiE79flBm78emU=.212c3281-d125-4ed9-93de-ceb192791b79@github.com>
Message-ID: <t4sNAnsjwzCoWzrngNaGcNzK4BY63uoLPkOCMYNB18w=.e69bd016-e5c5-4b48-b574-f4331076d66d@github.com>

On Fri, 17 Nov 2023 09:25:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which allows these _j.util_ tests to launch new JVM processes with VM flags,
> 
> This is primarily done using by switching to `ProcessTools::createTestJavaProcessBuilder`.

This pull request has now been integrated.

Changeset: 2bb4b939
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2bb4b9398d65e3f37f34e45476c969ff0afb1540
Stats:     185 lines in 12 files changed: 20 ins; 42 del; 123 mod

8319569: Several java/util tests should be updated to accept VM flags

Reviewed-by: naoto, lancea

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

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

From jlu at openjdk.org  Thu Nov 23 00:36:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 23 Nov 2023 00:36:36 GMT
Subject: <i18n dev> RFR: JDK-8210410: Refactor java.util.Currency:i18n shell
 tests to plain java tests
Message-ID: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>

Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.

This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.

In addition to the conversion, I have updated the test so that the `PropertiesTest` methods are ran by both the default test JDK and the newly created writable JDK, not just the writable JDK.

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

Commit messages:
 - resolve conflicts
 - init

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

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

From jlu at openjdk.org  Mon Nov 27 19:43:12 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Nov 2023 19:43:12 GMT
Subject: <i18n dev> RFR: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing
Message-ID: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>

Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.

These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.

Both have been updated to run without VM flags and marked as `vm.flagless`.

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

Commit messages:
 - init

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

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

From naoto at openjdk.org  Mon Nov 27 20:35:04 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 27 Nov 2023 20:35:04 GMT
Subject: <i18n dev> RFR: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing
In-Reply-To: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
References: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
Message-ID: <6ikNc3VJOr7vqied3hhob7LEfZ6Sz1A_Csiqjr0fT_E=.7b69daed-f970-4b6d-aadd-8f77b699c38f@github.com>

On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.
> 
> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.
> 
> Both have been updated to run without VM flags and marked as `vm.flagless`.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751305525

From bpb at openjdk.org  Mon Nov 27 21:06:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Nov 2023 21:06:06 GMT
Subject: <i18n dev> RFR: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing
In-Reply-To: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
References: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
Message-ID: <B2MBqte54X_MtlJr2dnPVm7IYumn0wEbePHsO5VYI3U=.7963eb0e-49c1-49e8-b03a-b8c6804daf6a@github.com>

On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.
> 
> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.
> 
> Both have been updated to run without VM flags and marked as `vm.flagless`.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751354324

From jlu at openjdk.org  Mon Nov 27 21:12:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 27 Nov 2023 21:12:17 GMT
Subject: <i18n dev> RFR: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing [v2]
In-Reply-To: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
References: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
Message-ID: <cLIYiZV_gNearpCv-1Wi7FmDHhIEMIMFoe04umWEIOk=.8bbd9d43-014b-4061-8dc1-314aee3b80d5@github.com>

> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.
> 
> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.
> 
> Both have been updated to run without VM flags and marked as `vm.flagless`.

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

  clarify comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16831/files
  - new: https://git.openjdk.org/jdk/pull/16831/files/f58cb4b5..5ecf4285

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

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

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

From lancea at openjdk.org  Mon Nov 27 21:18:05 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Nov 2023 21:18:05 GMT
Subject: <i18n dev> RFR: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing [v2]
In-Reply-To: <cLIYiZV_gNearpCv-1Wi7FmDHhIEMIMFoe04umWEIOk=.8bbd9d43-014b-4061-8dc1-314aee3b80d5@github.com>
References: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
 <cLIYiZV_gNearpCv-1Wi7FmDHhIEMIMFoe04umWEIOk=.8bbd9d43-014b-4061-8dc1-314aee3b80d5@github.com>
Message-ID: <0zq6gbSlNZVhlzQtB5zZiigwQOjINBw-ywMtRoHMsGY=.5e219f63-65c4-4467-b8f8-5e4a9b7540a1@github.com>

On Mon, 27 Nov 2023 21:12:17 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.
>> 
>> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.
>> 
>> Both have been updated to run without VM flags and marked as `vm.flagless`.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16831#pullrequestreview-1751388560

From ihse at openjdk.org  Tue Nov 28 17:07:20 2023
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 28 Nov 2023 17:07:20 GMT
Subject: <i18n dev> RFR: 8320915: Update copyright year in build files
Message-ID: <-4RrV3-LPfsh3BT-qwj3WtF1szg-_6Tt3RxnysPpNeo=.f2b0fee1-7d0c-4c43-bc4f-39ad9fec1150@github.com>

Over the year, even though we have tried to be diligent, there have been commits that modify files without updating the copyright year. Here is a mass update of the copyright years in the build system (`make/**`, `.github/**`). 

Feel free to verify that these files have indeed been modified in 2023 :-), or trust my tools + manual verification. Also, as far as I (and my tools) can tell, this is the only files modified in 2023 that have not had their header updated.

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

Commit messages:
 - 8320915: Update copyright year in build files

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

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

From jlu at openjdk.org  Tue Nov 28 17:26:13 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Nov 2023 17:26:13 GMT
Subject: <i18n dev> Integrated: JDK-8320714:
 java/util/Locale/LocaleProvidersRun.java and
 java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout
 after passing
In-Reply-To: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
References: <aRWLSsOxy_FYUq8XZMToPFCaFJv3tqOhAiRwSnwrSmQ=.3095f536-c6ec-4314-8cc2-77091f32d214@github.com>
Message-ID: <iEwRaRb1NUXeN96hr8n5WWG5ePGw9W38-sFGQCeOZhA=.8a964780-51d4-4027-9301-d7b50609492f@github.com>

On Mon, 27 Nov 2023 19:32:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which fixes timeouts for the two tests: _java/util/Locale/LocaleProvidersRun.java_ and _java/util/ResourceBundle/modules/visibility/VisibilityTest.java_.
> 
> These tests were updated to accept VM flags in [JDK-8319569](https://bugs.openjdk.org/browse/JDK-8319569), which is now causing timeouts in tiers 6 and 8. One set of VM flags causes _VisibilityTest.java_ to timeout with a duration of over 2 hours in tier6.
> 
> Both have been updated to run without VM flags and marked as `vm.flagless`.

This pull request has now been integrated.

Changeset: 69c0b243
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69c0b24386d0bcf2f2d623ccef0192a54753f916
Stats:     6 lines in 2 files changed: 2 ins; 0 del; 4 mod

8320714: java/util/Locale/LocaleProvidersRun.java and java/util/ResourceBundle/modules/visibility/VisibilityTest.java timeout after passing

Reviewed-by: naoto, bpb, lancea

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

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

From jlu at openjdk.org  Tue Nov 28 18:28:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Nov 2023 18:28:37 GMT
Subject: <i18n dev> RFR: JDK-8210410: Refactor java.util.Currency:i18n
 shell tests to plain java tests [v2]
In-Reply-To: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
References: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
Message-ID: <qfQ6AFAnuq61vpRGviAHBX61jxACyXBtIP4uS1XfwUE=.e9b97a51-77a2-4bb9-83cb-03bbfa416141@github.com>

> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.
> 
> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.

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

  cleanup + naming

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16787/files
  - new: https://git.openjdk.org/jdk/pull/16787/files/780c6fd1..efc6da98

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

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

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

From naoto at openjdk.org  Tue Nov 28 20:43:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 28 Nov 2023 20:43:06 GMT
Subject: <i18n dev> RFR: JDK-8210410: Refactor java.util.Currency:i18n
 shell tests to plain java tests [v2]
In-Reply-To: <qfQ6AFAnuq61vpRGviAHBX61jxACyXBtIP4uS1XfwUE=.e9b97a51-77a2-4bb9-83cb-03bbfa416141@github.com>
References: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
 <qfQ6AFAnuq61vpRGviAHBX61jxACyXBtIP4uS1XfwUE=.e9b97a51-77a2-4bb9-83cb-03bbfa416141@github.com>
Message-ID: <ApRx-jurHZKzK-jaHBX2t-a0vMu5MccI424ncM-p7XI=.ac76dc53-07ca-400b-b442-bd3ae1f19d33@github.com>

On Tue, 28 Nov 2023 18:28:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.
>> 
>> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup + naming

Looks good. Please retain the original copyright year (2007) with the refactored launcher file.

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16787#pullrequestreview-1753893945

From jlu at openjdk.org  Tue Nov 28 20:52:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 28 Nov 2023 20:52:25 GMT
Subject: <i18n dev> RFR: JDK-8210410: Refactor java.util.Currency:i18n
 shell tests to plain java tests [v3]
In-Reply-To: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
References: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
Message-ID: <U9DSnbW6IB9APPLuWx8O8R0XObQsCwLNyf0hr7c1U3Q=.59ad6fa9-22b9-47a8-a686-c960d44bddf1@github.com>

> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.
> 
> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.

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

  retain original copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16787/files
  - new: https://git.openjdk.org/jdk/pull/16787/files/efc6da98..105a6755

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

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

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

From lancea at openjdk.org  Tue Nov 28 20:52:25 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 28 Nov 2023 20:52:25 GMT
Subject: <i18n dev> RFR: JDK-8210410: Refactor java.util.Currency:i18n
 shell tests to plain java tests [v3]
In-Reply-To: <U9DSnbW6IB9APPLuWx8O8R0XObQsCwLNyf0hr7c1U3Q=.59ad6fa9-22b9-47a8-a686-c960d44bddf1@github.com>
References: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
 <U9DSnbW6IB9APPLuWx8O8R0XObQsCwLNyf0hr7c1U3Q=.59ad6fa9-22b9-47a8-a686-c960d44bddf1@github.com>
Message-ID: <ZEOHnJ-LLeXKUMEyZqx8aAj9T2nPh0u5msd0H-zysfU=.e7cc99dd-b8fa-4c73-b7d0-19da140d83fc@github.com>

On Tue, 28 Nov 2023 20:49:38 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.
>> 
>> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   retain original copyright year

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16787#pullrequestreview-1753905849

From jlu at openjdk.org  Wed Nov 29 19:14:20 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 29 Nov 2023 19:14:20 GMT
Subject: <i18n dev> Integrated: JDK-8210410: Refactor
 java.util.Currency:i18n shell tests to plain java tests
In-Reply-To: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
References: <C742upaT8vrdeWeWzpvUOf45ryAFEVVrrtuvWkwTjBU=.accfa358-5dae-4285-a8f8-d5b12faede04@github.com>
Message-ID: <qMyEmOKtsenrKN51Gm5qYR7HN4EMsYukz3JZc0kfeVw=.9ab1be10-1d84-4140-9cdd-8e1af64fbf75@github.com>

On Thu, 23 Nov 2023 00:26:43 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which converts the shell test, _java/util/currency/PropertiesTest.sh_ to a normal java test.
> 
> This test is a test runner that launches test methods from _PropertiesTest.java_. It tests both the ways to supersede the default currencies, that is, either using a custom properties file under the lib directory, or setting the path to a custom properties file via the system property.

This pull request has now been integrated.

Changeset: 2584bf87
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2584bf87aef66744a8e586805735cded0d2f98f1
Stats:     301 lines in 2 files changed: 157 ins; 144 del; 0 mod

8210410: Refactor java.util.Currency:i18n shell tests to plain java tests

Reviewed-by: naoto, lancea

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

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

From jlu at openjdk.org  Wed Nov 29 22:47:21 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 29 Nov 2023 22:47:21 GMT
Subject: <i18n dev> RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in
 ChoiceFormats ignore indicated subformats
Message-ID: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>

Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.

ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 

In the original example,
`Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
`Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.

This PR replaces the example with the one used in MessageFormat, which is correct. 

This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

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

Commit messages:
 - change var name in trailing example
 - replace '.' with ':'
 - init

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

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

From naoto at openjdk.org  Wed Nov 29 23:37:03 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 29 Nov 2023 23:37:03 GMT
Subject: <i18n dev> RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in
 ChoiceFormats ignore indicated subformats
In-Reply-To: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
Message-ID: <CT5p0635Qj7LAaFT3oPPkeL_wHLw18EzyoIqj6Tid4w=.e144abd6-b2fa-4def-9ae7-cc8bc4ab4f80@github.com>

On Wed, 29 Nov 2023 22:41:26 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates an incorrect code example in _java/text/ChoiceFormat_.
> 
> ChoiceFormat (and MessageFormat) provide an example of how to produce a pattern that supports singular and plural forms. The ChoiceFormat example is incorrect, as recursive MessageFormats produced by a ChoiceFormat subformat only recognize subformats defined through the MessageFormat pattern syntax, not through the subformats contained within the top level MessageFormat. 
> 
> In the original example,
> `Format[] testFormats = {fileform, null, NumberFormat.getInstance()};` could have been replaced with 
> `Format[] testFormats = {fileform, null, new ChoiceFormat("0#BROKEN")};` and the original output would have been the same.
> 
> This PR replaces the example with the one used in MessageFormat, which is correct. 
> 
> This PR also includes a drive-by fix to remove leftover `<blockquote>`s from a previous `@snippet` conversion.

Do you think it would be helpful if we describe that limitation so that such confusion will not arise?

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

PR Review: https://git.openjdk.org/jdk/pull/16891#pullrequestreview-1756397913

From jlu at openjdk.org  Thu Nov 30 00:23:04 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Nov 2023 00:23:04 GMT
Subject: <i18n dev> RFR: 6230751: [Fmt-Ch] Recursive MessageFormats in
 ChoiceFormats ignore indicated subformats
In-Reply-To: <CT5p0635Qj7LAaFT3oPPkeL_wHLw18EzyoIqj6Tid4w=.e144abd6-b2fa-4def-9ae7-cc8bc4ab4f80@github.com>
References: <7wIjtUukVVmPac0CLynJTK8zIx7Difi9122zthoFj_w=.8e65ff5d-816b-4383-b833-0df272efaede@github.com>
 <CT5p0635Qj7LAaFT3oPPkeL_wHLw18EzyoIqj6Tid4w=.e144abd6-b2fa-4def-9ae7-cc8bc4ab4f80@github.com>
Message-ID: <QtfivW2PWctAekSBadeesF-oPERGk2Vr_HCKNX6LsTY=.e5394231-9f5a-4517-86c7-424324aa74e8@github.com>

On Wed, 29 Nov 2023 23:34:14 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Do you think it would be helpful if we describe that limitation so that such confusion will not arise?

Yes, that's a good point. I didn't initially include one because I wanted to look into [JDK-4270867](https://bugs.openjdk.org/browse/JDK-4270867) (which would be the fix to the limitation) first.

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

PR Comment: https://git.openjdk.org/jdk/pull/16891#issuecomment-1832905952

From naoto at openjdk.org  Thu Nov 30 20:52:10 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Nov 2023 20:52:10 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray
Message-ID: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>

Removing the unnecessary array assignments.

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

Commit messages:
 - initial commit

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

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

From jlu at openjdk.org  Thu Nov 30 21:13:06 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 30 Nov 2023 21:13:06 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray
In-Reply-To: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
Message-ID: <W87J9zqNH5UgjWn27indebuPMA1jVLuoefGwgsVrhcM=.bbe567df-544e-4cee-a7d7-04f20c42096f@github.com>

On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the unnecessary array assignments.

Looks good

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758458649

From bpb at openjdk.org  Thu Nov 30 21:21:12 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Nov 2023 21:21:12 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray
In-Reply-To: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
Message-ID: <tiCoDrUCsU0WSlH0-vtPFHuD4GTr45x7YvAAGZp9szs=.4143e5e7-2394-4c87-a02f-428f8e764180@github.com>

On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the unnecessary array assignments.

Looks fine.

Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed?

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758469599

From duke at openjdk.org  Thu Nov 30 21:29:05 2023
From: duke at openjdk.org (Brett Okken)
Date: Thu, 30 Nov 2023 21:29:05 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray
In-Reply-To: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
Message-ID: <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com>

On Thu, 30 Nov 2023 20:46:12 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing the unnecessary array assignments.

src/java.base/share/classes/sun/text/CompactByteArray.java line 83:

> 81:             for (i = 0; i < UNICODECOUNT; ++i) {
> 82:                 values[i] = defaultValue;
> 83:             }

should this be `Arrays.fill(values, defaultValue);` ?

https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#fill(byte%5B%5D,byte)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16912#discussion_r1411279673

From naoto at openjdk.org  Thu Nov 30 21:51:19 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Nov 2023 21:51:19 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
Message-ID: <YyrWJ3dWQEzKHng307im4rK_lAzbPjT-Rfwj7J_dKlU=.8c440927-5649-41ab-9904-bbbf1dfa9a71@github.com>

> Removing the unnecessary array assignments.

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

  Use Arrays.fill()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16912/files
  - new: https://git.openjdk.org/jdk/pull/16912/files/4fd6e61b..b1708ddb

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

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

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

From naoto at openjdk.org  Thu Nov 30 21:51:21 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Nov 2023 21:51:21 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <tiCoDrUCsU0WSlH0-vtPFHuD4GTr45x7YvAAGZp9szs=.4143e5e7-2394-4c87-a02f-428f8e764180@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
 <tiCoDrUCsU0WSlH0-vtPFHuD4GTr45x7YvAAGZp9szs=.4143e5e7-2394-4c87-a02f-428f8e764180@github.com>
Message-ID: <RgXKBrcGp-OxiSlObaw0vpN2xFveVDX3AD1mB7hpXX0=.21051289-d374-41d6-beba-23bdb4ad84e3@github.com>

On Thu, 30 Nov 2023 21:17:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed?

Maybe, but not 100% sure, so I just left it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16912#issuecomment-1834615018

From naoto at openjdk.org  Thu Nov 30 21:51:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 30 Nov 2023 21:51:23 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
 <6Umy3nxhMKROX_8fgY7AqGqBkvX3EhRBF9tBo6L8BKE=.feac8b48-bc7f-41e9-b6b5-37111e8edbd8@github.com>
Message-ID: <a8euTFRzL-LJO8tnZhll2ucH5Y44lxnEDceau_DWBfA=.a7469267-de19-43bf-99d6-eddc0391d04a@github.com>

On Thu, 30 Nov 2023 21:26:20 GMT, Brett Okken <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use Arrays.fill()
>
> src/java.base/share/classes/sun/text/CompactByteArray.java line 83:
> 
>> 81:             for (i = 0; i < UNICODECOUNT; ++i) {
>> 82:                 values[i] = defaultValue;
>> 83:             }
> 
> should this be `Arrays.fill(values, defaultValue);` ?
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/Arrays.html#fill(byte%5B%5D,byte)

Thanks. Modernized.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16912#discussion_r1411299519

From bpb at openjdk.org  Thu Nov 30 22:12:06 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Nov 2023 22:12:06 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <YyrWJ3dWQEzKHng307im4rK_lAzbPjT-Rfwj7J_dKlU=.8c440927-5649-41ab-9904-bbbf1dfa9a71@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
 <YyrWJ3dWQEzKHng307im4rK_lAzbPjT-Rfwj7J_dKlU=.8c440927-5649-41ab-9904-bbbf1dfa9a71@github.com>
Message-ID: <93i4ohpMOEB7bUtMijikxjOKBB2DVRP9Z_rRyFh4YPI=.7077f21c-86a6-488d-87aa-f35d8b00e64b@github.com>

On Thu, 30 Nov 2023 21:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the unnecessary array assignments.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Arrays.fill()

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758547239

From bpb at openjdk.org  Thu Nov 30 22:12:08 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 30 Nov 2023 22:12:08 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <RgXKBrcGp-OxiSlObaw0vpN2xFveVDX3AD1mB7hpXX0=.21051289-d374-41d6-beba-23bdb4ad84e3@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
 <tiCoDrUCsU0WSlH0-vtPFHuD4GTr45x7YvAAGZp9szs=.4143e5e7-2394-4c87-a02f-428f8e764180@github.com>
 <RgXKBrcGp-OxiSlObaw0vpN2xFveVDX3AD1mB7hpXX0=.21051289-d374-41d6-beba-23bdb4ad84e3@github.com>
Message-ID: <JpmTgiYiKXMPelusUIQCSUwHxbsHJ9qiA17fglFmTY0=.c38ae555-a9ec-4805-83ee-3c45021f5ca3@github.com>

On Thu, 30 Nov 2023 21:47:27 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > Is that "XXX" reminder at line 58 in MergeCollation still pertinent or could it be removed?
> 
> Maybe, but not 100% sure, so I just left it.

If unsure, better to leave it.

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

PR Comment: https://git.openjdk.org/jdk/pull/16912#issuecomment-1834640272

From rriggs at openjdk.org  Thu Nov 30 22:56:06 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 30 Nov 2023 22:56:06 GMT
Subject: <i18n dev> RFR: 8321059: Unneeded array assignments in
 MergeCollation and CompactByteArray [v2]
In-Reply-To: <YyrWJ3dWQEzKHng307im4rK_lAzbPjT-Rfwj7J_dKlU=.8c440927-5649-41ab-9904-bbbf1dfa9a71@github.com>
References: <XvjkCvV-ouUN4AXiU4UR3LtXqBdseHUi-kVKE_7SAXw=.93a61370-5aac-4101-b944-dac5583c9313@github.com>
 <YyrWJ3dWQEzKHng307im4rK_lAzbPjT-Rfwj7J_dKlU=.8c440927-5649-41ab-9904-bbbf1dfa9a71@github.com>
Message-ID: <swy8W9LknipnHCM4jH9iwUhMbg0SxnrUcl35iaWSpXI=.2afeace3-dd91-40cd-bece-552900861e7d@github.com>

On Thu, 30 Nov 2023 21:51:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing the unnecessary array assignments.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use Arrays.fill()

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/16912#pullrequestreview-1758625426