From stsypanov at openjdk.org  Mon May  1 18:41:49 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Mon, 1 May 2023 18:41:49 GMT
Subject: <i18n dev> Integrated: 8300818: Reduce complexity of padding with
 DateTimeFormatter
In-Reply-To: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
References: <CZ46FduK_O48-65TQBqnw7fb4t1A207kOsjg5TqfcdA=.7d71e3df-d657-4054-8066-118525cf202e@github.com>
Message-ID: <vmBhZBCZsystY0HpWSr_90JiNpQJMUId-wHpeFGQoRE=.6819c403-e38c-4ccc-b422-170d8afc7a45@github.com>

On Sat, 21 Jan 2023 21:01:48 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

> Currently it's O(n) - we do `n` shifts of bytes within `StringBuilder`. This can be reduced to O(1) improving the code like:
> 
> DateTimeFormatter dtf = new DateTimeFormatterBuilder()
>   .appendLiteral("Date:")
>   .padNext(20, ' ')
>   .append(DateTimeFormatter.ISO_DATE)
>   .toFormatter();
> String text = dtf.format(LocalDateTime.now());

This pull request has now been integrated.

Changeset: 561ec9c5
Author:    Sergey Tsypanov <stsypanov at openjdk.org>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/561ec9c5a06e5baeb0cf72463d14d1d720facb13
Stats:     84 lines in 2 files changed: 83 ins; 0 del; 1 mod

8300818: Reduce complexity of padding with DateTimeFormatter

Reviewed-by: redestad, rriggs

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

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

From jlu at openjdk.org  Mon May  1 21:19:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 1 May 2023 21:19:25 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v2]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <1_a3GJ3Fkn4UK_ti_JjK1BFRu9ijs5-wHzqz-9WDCYU=.69a0e95e-1d87-4870-b2cf-ff56604e1640@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

 - Adjust specification to elaborate on JDK Variant special cases
 - Use ILE over IAE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/25be34d9..91e84efe

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

  Stats: 42 lines in 3 files changed: 19 ins; 7 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From ysatowse at openjdk.org  Tue May  2 12:45:49 2023
From: ysatowse at openjdk.org (Yoshiki Sato)
Date: Tue, 2 May 2023 12:45:49 GMT
Subject: <i18n dev> Integrated: 8305505: NPE in javazic compiler
In-Reply-To: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
References: <6FUIpCFegl9qCOsUz9Rk6q8XY3ZtwkLeBn_1ykLRzaI=.f97b2f21-d34a-4f69-bad7-c3bb2392472b@github.com>
Message-ID: <zXCUyO0j-zq_Mqlm8DmuX0lLKEja39A0HX8AoHvpxic=.e0c5d1a4-231a-4282-850e-117873821848@github.com>

On Tue, 18 Apr 2023 05:08:35 GMT, Yoshiki Sato <ysatowse at openjdk.org> wrote:

> Please review this PR.  
> With this minor change, the javazic compiler (Main.java) can produce the HTML files that display given time zone data correctly.

This pull request has now been integrated.

Changeset: 544bd260
Author:    Yoshiki Sato <ysatowse at openjdk.org>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/544bd260b6eb7bc7cf79a3739cc94bad658d7d15
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8305505: NPE in javazic compiler

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Tue May  2 18:34:11 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 18:34:11 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v3]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

  Add distinction between legacy and grandfathered to spec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/91e84efe..63fe500e

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

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

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

From naoto at openjdk.org  Tue May  2 20:28:22 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 May 2023 20:28:22 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v3]
In-Reply-To: <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
Message-ID: <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>

On Tue, 2 May 2023 18:34:11 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add distinction between legacy and grandfathered to spec

Looks good. Some minor comments follow:

src/java.base/share/classes/java/util/Locale.java line 1809:

> 1807:      * <p>Legacy tags with canonical replacements are as follows:
> 1808:      *
> 1809:      * <table class="striped" id="legacy_tags_replacement">

Maybe `id="legacy_tags` attribute added to the above paragraph that starts with "This implements..." is clearer.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 415:

> 413:         // Illegal tags
> 414:         if (!parse(tag, null).wellFormed) {
> 415:             throw new IllformedLocaleException("Ill formed tag");

May include additional information by providing `sts` and retrieving the info from it.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 48:

> 46:  * grandfathered, and irregular. For more info, see the following,
> 47:  * <a href="https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1">Tag Syntax</a>).
> 48:  * In addition, the method is tested to ensure that IllegalArgumentException and

`IllformedLocaleException`?

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 55:

> 53:     @ParameterizedTest
> 54:     @MethodSource("wellFormedTags")
> 55:     public void TestWellFormedTags(String tag, String foldedTag) {

Nit: method name should start with a lowercase char

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:

> 54:     @MethodSource("wellFormedTags")
> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));

Would it be helpful if both the expected and the result are recorded?

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 65:

> 63:             Locale.caseFoldLanguageTag(tag);
> 64:             throw new RuntimeException("$$$ Failure: ill formed tags should throw IAE");
> 65:         } catch (IllegalArgumentException ignored) {}

`IllformedLocaleException`? Or if the test passes with this version of impl, should the test throw an RuntimeException? Also instead of try-catch, `assertThrows()` can be used.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 72:

> 70:         try {
> 71:             Locale.caseFoldLanguageTag(null);
> 72:             throw new RuntimeException("$$$ Failure: NPE should be thrown when tag is null");

`assertThrows()` can be used here as well

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

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1409713684
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182938431
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182940287
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1182943088
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183004084
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183002010
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183006073
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183013804

From jlu at openjdk.org  Tue May  2 21:42:09 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 21:42:09 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v4]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

 - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
 - Review comment: Adjust method names
 - Review comment: Use assertThrows and correct IAE to ILE
 - Review comment: improve legacy_tags id

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/63fe500e..34ccd3be

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

  Stats: 27 lines in 3 files changed: 5 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlu at openjdk.org  Tue May  2 21:42:14 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 2 May 2023 21:42:14 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v3]
In-Reply-To: <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
 <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
Message-ID: <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>

On Tue, 2 May 2023 18:59:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add distinction between legacy and grandfathered to spec
>
> src/java.base/share/classes/java/util/Locale.java line 1809:
> 
>> 1807:      * <p>Legacy tags with canonical replacements are as follows:
>> 1808:      *
>> 1809:      * <table class="striped" id="legacy_tags_replacement">
> 
> Maybe `id="legacy_tags` attribute added to the above paragraph that starts with "This implements..." is clearer.

Thanks for the review and helpful comments, I have addressed this comment and the other ones you left.

> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 415:
> 
>> 413:         // Illegal tags
>> 414:         if (!parse(tag, null).wellFormed) {
>> 415:             throw new IllformedLocaleException("Ill formed tag");
> 
> May include additional information by providing `sts` and retrieving the info from it.

Good point, I have updated it so that it provides the sts error message with the exception.

For example,
`Ill formed tag: Invalid subtag: xabadadoo`

> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:
> 
>> 54:     @MethodSource("wellFormedTags")
>> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
>> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));
> 
> Would it be helpful if both the expected and the result are recorded?

Junit assertEquals provides the actual result in the failure, so no need to record it.

Example failure:
`org.opentest4j.AssertionFailedError: Folded ABC ==> expected: <ab> but was: <abc>`

> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 65:
> 
>> 63:             Locale.caseFoldLanguageTag(tag);
>> 64:             throw new RuntimeException("$$$ Failure: ill formed tags should throw IAE");
>> 65:         } catch (IllegalArgumentException ignored) {}
> 
> `IllformedLocaleException`? Or if the test passes with this version of impl, should the test throw an RuntimeException? Also instead of try-catch, `assertThrows()` can be used.

The test does not pass like this, I had forgotten to re run the test after originally switching IAE to IFE in the method itself. (and hence why I did not catch that it is not updated in the test). 

I have switched all the IAE to IFE in the test, and also used assertThrows() as recommended

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074736
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074304
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074241
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183074141

From naoto at openjdk.org  Wed May  3 17:01:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 May 2023 17:01:20 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v3]
In-Reply-To: <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <_KbXcqAr67ajBB1dGA4ers6_Sk9OhGk6O8uL3h_NzdE=.f6ba0b87-55b0-40e6-a4f8-8a025822244d@github.com>
 <uwvlNKFjdHtV7Ux6lQhlPZcFUzqWBDcZ6UxKRT87q5g=.2e5688be-dc4e-4115-b6f0-c5df3accbdb7@github.com>
 <JXDGHb8J5cPDu9NLp10-nWBGJTFCSJWVJP_Jk0OLZ_I=.1c4873cc-eb19-423c-8aa7-ee178c1ad1ea@github.com>
Message-ID: <a7Ue4tDB-6MoO6RrHhvaUbfYhn-1y_6kxltLrFPxshY=.507753fe-b680-4aeb-bdbf-242dd220bb63@github.com>

On Tue, 2 May 2023 21:36:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 56:
>> 
>>> 54:     @MethodSource("wellFormedTags")
>>> 55:     public void TestWellFormedTags(String tag, String foldedTag) {
>>> 56:         assertEquals(foldedTag, Locale.caseFoldLanguageTag(tag), String.format("Folded %s", tag));
>> 
>> Would it be helpful if both the expected and the result are recorded?
>
> Junit assertEquals provides the actual result in the failure, so no need to record it.
> 
> Example failure:
> `org.opentest4j.AssertionFailedError: Folded ABC ==> expected: <ab> but was: <abc>`

Ah, ok then

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183965230

From naoto at openjdk.org  Wed May  3 17:01:17 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 May 2023 17:01:17 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v4]
In-Reply-To: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
Message-ID: <KVUbTsPAXu01uVF6XAXA7yuds4o_2nOLQYO5m_9HzVk=.377a559f-750e-4e40-88a2-27e997d1e447@github.com>

On Tue, 2 May 2023 21:42:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>  - Review comment: Adjust method names
>  - Review comment: Use assertThrows and correct IAE to ILE
>  - Review comment: improve legacy_tags id

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 411:

> 409: 
> 410:     public static String caseFoldTag(String tag) {
> 411:         LanguageTag parsedTag = parse(tag, null);

I think we don't need to create a field `parseSts` but provide a local one here and use it in `parse(tag, sts), as that parse status is only referred to within this method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1183964205

From rriggs at openjdk.org  Wed May  3 19:28:20 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 3 May 2023 19:28:20 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v4]
In-Reply-To: <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
Message-ID: <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>

On Tue, 2 May 2023 21:42:09 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>  - Review comment: Adjust method names
>  - Review comment: Use assertThrows and correct IAE to ILE
>  - Review comment: improve legacy_tags id

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 34:

> 32: package sun.util.locale;
> 33: 
> 34: import java.util.*;

Wild card imports are discouraged. It may be useful to update your ide settings to avoid automatic conversions.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 423:

> 421:         }
> 422:         // Non-legacy tags
> 423:         StringBuilder bldr = new StringBuilder();

Presize the StringBuilder with the current length to avoid a reallocation.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 429:

> 427:         boolean privUseVarFound = false;
> 428:         for (int i = 0; i < subtags.length; i++) {
> 429:             if (privUseVarFound) {

The following block of code might be easier to read if subtags[i] was put in a local.

src/java.base/share/classes/sun/util/locale/LanguageTag.java line 446:

> 444:                 } else if (subtags[i].equals(PRIVUSE_VARIANT_PREFIX)) {
> 445:                     privUseVarFound = true;
> 446:                 }

These flags can become true but inside the loop cannot become false again.
Is that correct?  For example, I think there can be multiple extension singletons.

test/jdk/java/util/Locale/CaseFoldLanguageTagTest.java line 75:

> 73: 
> 74:     private static Stream<Arguments> wellFormedTags() {
> 75:         return Stream.of(

There are no test cases with multiple singleton extensions either as valid or invalid tests.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184028514
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184130544
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184133074
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184143730
PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184159147

From jlu at openjdk.org  Wed May  3 19:37:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 19:37:25 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v5]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

  Review comment: parseSts should be local

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/34ccd3be..f0762efe

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

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

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

From jlu at openjdk.org  Wed May  3 20:32:25 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:25 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v6]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

 - Review: SBldr should be pre allocated with input tag
 - Review: drop wwildcard import and replace subtags[i] with subtag
 - Review: Include multiple singleton extensions in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/f0762efe..96781281

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

  Stats: 34 lines in 2 files changed: 18 ins; 1 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlu at openjdk.org  Wed May  3 20:32:27 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:27 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v5]
In-Reply-To: <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <tiGqRoewK33MgQBMnudKX81qMCwdw3H_pkbg-UMM-as=.321267cf-9c03-431e-9ba7-8737ae6b417f@github.com>
Message-ID: <ikUettB9vhj_Ik3U0a_us4E5bikitH_-fhszLjH7szw=.e57a7f01-fc18-4b60-9d19-9f69b5bd96e4@github.com>

On Wed, 3 May 2023 19:37:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comment: parseSts should be local

Hi @RogerRiggs, thanks for the review. 

I have dropped the wildcard import (and disabled it on IntellJ for the future), made subtags[i] a local var, added tests with multiple extension singletons, and pre allocated the string builder.

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

PR Comment: https://git.openjdk.org/jdk/pull/13679#issuecomment-1533690524

From jlu at openjdk.org  Wed May  3 20:32:29 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 3 May 2023 20:32:29 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v4]
In-Reply-To: <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <JqYHi4dOGc0oRt20NEND3YoDlNQ8kL6lldvfwtSax5Y=.781701ae-d52c-44c4-88a0-8a075cfb7465@github.com>
 <aTioAsSNxFpiEeH7BxcNrw-v_pSQdlIHIX8BSoJPBk4=.efeab225-50b9-4be6-ae4b-46ae8e8f286b@github.com>
Message-ID: <wavaeHtsMoXxkI6OpTOMfaTpQwiEaSVdZBhYWhsUIFM=.a6a59919-5ca2-4375-b8d6-437ea54d1f6f@github.com>

On Wed, 3 May 2023 19:13:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
>>  - Review comment: Adjust method names
>>  - Review comment: Use assertThrows and correct IAE to ILE
>>  - Review comment: improve legacy_tags id
>
> src/java.base/share/classes/sun/util/locale/LanguageTag.java line 446:
> 
>> 444:                 } else if (subtags[i].equals(PRIVUSE_VARIANT_PREFIX)) {
>> 445:                     privUseVarFound = true;
>> 446:                 }
> 
> These flags can become true but inside the loop cannot become false again.
> Is that correct?  For example, I think there can be multiple extension singletons.

That was intentional as the booleans represent if a private prefix, singleton prefix, or "lvariant" has been found in general (not that the current position is the suffix of one of those prefixes).

Consider if there is a multiple extension singleton (eg: `a-BBB-CCC-DDD`)

Once singletonFound is set to `true`, it is assumed all further subtags should be lowercased unless it is a private use prefixed by "lvariant". Thus it would be folded to `a-bbb-ccc-ddd` as expected.

Did that address your point?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13679#discussion_r1184224520

From naoto at openjdk.org  Thu May  4 18:14:20 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 4 May 2023 18:14:20 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v6]
In-Reply-To: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
Message-ID: <eEFHECn-wQdg-Ypybbzc-kxYM-52dYylulWqhRKATTI=.a529b8f4-dbd4-4578-912c-07b63732a058@github.com>

On Wed, 3 May 2023 20:32:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: SBldr should be pre allocated with input tag
>  - Review: drop wwildcard import and replace subtags[i] with subtag
>  - Review: Include multiple singleton extensions in test

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1413649585

From rriggs at openjdk.org  Thu May  4 18:35:19 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 4 May 2023 18:35:19 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v6]
In-Reply-To: <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
 <Qxg9rAUPtzUYyt21mKIpZQfIiqvVnF-kadcA7PndHIM=.03290dc4-fe07-43cc-800f-0524cc67acc9@github.com>
Message-ID: <E0T1GNjpHVoNA58hrRoSrkoRlDXr2JnKOCEJ_o2R6ks=.3aada262-d316-4ca3-9b74-f55faf601f28@github.com>

On Wed, 3 May 2023 20:32:25 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
>> 
>> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
>> 
>> 
>> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
>> - Will not case fold variant subtags
>> - Will not case fold private use subtags prefixed by "lvariant"
>> 
>> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.
>
> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Review: SBldr should be pre allocated with input tag
>  - Review: drop wwildcard import and replace subtags[i] with subtag
>  - Review: Include multiple singleton extensions in test

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13679#pullrequestreview-1413697034

From alanb at openjdk.org  Fri May  5 06:04:24 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 May 2023 06:04:24 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
 <x8j-huGlphor_LDELRncZ2hwghZhBpli5S96RYQmy98=.04857585-5b8f-4e34-89c9-76a7aff1a120@github.com>
 <sIYV7T_b2c09kkNhHYWB6x_gAGpCFQi6KXl4VddE0zk=.5e5cae16-4c4c-4cde-99e6-9580fd641db1@github.com>
Message-ID: <U2Z51rEV30UFhHU52hcSS6FqZGM8_zyzp8_9DN0bdpM=.6ac433ce-0edc-45c8-8d77-59cf647b36ec@github.com>

On Thu, 27 Apr 2023 12:32:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?
>
>> The rule was changed in 2006, the year Jave SE 6 was released. Though it looks like very much a corner case, it goes all the way back. I wonder if a CSR is needed?
> 
> We don't file a CSR for such a locale data change. These sorts of changes happen in the CLDR upgrade all the time, as well as other i18n-related data changes (currency, timezone, etc.)

@naotoj I know we don't usually create CSRs for changes to locale data but changing the sorting order looks significant, it might need further discussion.

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1535743951

From naoto at openjdk.org  Fri May  5 16:55:30 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 May 2023 16:55:30 GMT
Subject: <i18n dev> RFR: 8306927: Collator treats "v" and "w" as the
 same letter for Swedish language locale.
In-Reply-To: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
References: <_pDZ_dtKjp8GRSdFY8MS1wHOJt8HioAApEiSXkhPaUk=.d29bd978-7265-4a01-a6d5-a464e91cedc9@github.com>
Message-ID: <H0aWZy8oYIqAbd9UD8PLn1uUxEAPq0oxhnVbQolT8hE=.4a0e70ae-2a97-439e-8e49-6511eb274f29@github.com>

On Wed, 26 Apr 2023 20:42:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updating the collation rules for Swedish to the modern one, which is aligned with the CLDR's default collation rules. Since it is changing the existing behavior, a release note has also been drafted: https://bugs.openjdk.org/browse/JDK-8306948

I created an enhancement for Collator to support multiple tables: [JDK-8307547](https://bugs.openjdk.org/browse/JDK-8307547) that would require a CSR where we can discuss the default

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

PR Comment: https://git.openjdk.org/jdk/pull/13677#issuecomment-1536525383

From darcy at openjdk.org  Sat May  6 02:44:30 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:44:30 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:

> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }

I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186599844

From darcy at openjdk.org  Sat May  6 02:57:20 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 6 May 2023 02:57:20 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v65]
In-Reply-To: <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
Message-ID: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>

On Thu, 27 Apr 2023 17:21:23 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR recommendations

src/java.base/share/classes/java/lang/StringTemplate.java line 427:

> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
> 426:      * as if invoking {@link String#valueOf(Object)}.
> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every

IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.

Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1186601013

From jlaskey at openjdk.org  Mon May  8 12:51:08 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:51:08 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v65]
In-Reply-To: <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <nAe_DBQxds8A45LkLzTNlflVBLc09_E1Dnhtj4cUjZ4=.2d01b306-25a5-4217-91dc-b64c439f1bef@github.com>
Message-ID: <YJrw2TYcIl3YSbBUhC8lZkj80rjtMCCRbdxd9wK8sqM=.2b8176bd-a66d-4256-b407-9b9ea7529f01@github.com>

On Sat, 6 May 2023 02:42:14 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/invoke/StringConcatFactory.java line 123:
> 
>> 121:     @PreviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES)
>> 122:     public static final int MAX_INDY_CONCAT_ARG_SLOTS;
>> 123:     static { MAX_INDY_CONCAT_ARG_SLOTS = 200; }
> 
> I think this deserve a comment such as "use static initialize block to avoid MAX_INDY_CONCAT_ARG_SLOTS being treating as a constant for constant folding," assuming that is the intention here.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187407224

From jlaskey at openjdk.org  Mon May  8 12:53:16 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 12:53:16 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v65]
In-Reply-To: <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <MO9fOyqaeyudnk0FP4X1BjFQkhKTwBdqimUxl68iulc=.19f1303d-f095-4cf3-b052-29b46135e6c0@github.com>
 <0lyLXXpOtSz0C8DvkpexUAyj3IPrqUkP4WuLHrw_30c=.512031ec-bacb-4918-a4be-6054a684fddb@github.com>
Message-ID: <u3aYXVcsp34hfkaxT-GO3Q5czUxnrxeSis416oflJQI=.8685258b-3c9d-404f-a98d-c6a512c044a0@github.com>

On Sat, 6 May 2023 02:53:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   CSR recommendations
>
> src/java.base/share/classes/java/lang/StringTemplate.java line 427:
> 
>> 425:      * {@link StringTemplate}. To accommodate concatenation, values are converted to strings
>> 426:      * as if invoking {@link String#valueOf(Object)}.
>> 427:      * @implNote {@link StringTemplate#STR} is statically imported implicitly into every
> 
> IMO the remark regarding  STR being auto-imported works better as an apiNote rather than an implNote.
> 
> Regarding interning, I think an implSpec of "may or may not be interned" provides maximum flexibility to the implementation.

Changed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/10889#discussion_r1187409617

From jlaskey at openjdk.org  Mon May  8 19:13:47 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Mon, 8 May 2023 19:13:47 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v66]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <q4SwaaWMYKvgNUafmFVdnuH4ZbvRWQ6sUBbiccMQ6ag=.18c6b403-544a-417b-ad05-a7901ecf97df@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/fb406d23..53f6280d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=64-65

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

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

From jlu at openjdk.org  Mon May  8 19:44:36 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 8 May 2023 19:44:36 GMT
Subject: <i18n dev> RFR: 8159337: Introduce a method in Locale class to
 return the language tags as per RFC 5646 convention [v7]
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <7qqZaTSP8VtDTWDH8EmulPNC6VZBW1_-dQNT1eMd8D0=.23d1342d-6df9-4a8f-bfc0-a24cf700c738@github.com>

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

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

 - Adjust file name to match class name
 - Merge branch 'master' into JDK-8159337-Langtags-RFC5646
 - Review: SBldr should be pre allocated with input tag
 - Review: drop wwildcard import and replace subtags[i] with subtag
 - Review: Include multiple singleton extensions in test
 - Review comment: parseSts should be local
 - Review comment: Replace wellFormed with parseSts to pass errorMsg to exception
 - Review comment: Adjust method names
 - Review comment: Use assertThrows and correct IAE to ILE
 - Review comment: improve legacy_tags id
 - ... and 14 more: https://git.openjdk.org/jdk/compare/23ccc4b0...4795fb77

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13679/files
  - new: https://git.openjdk.org/jdk/pull/13679/files/96781281..4795fb77

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

  Stats: 341635 lines in 3619 files changed: 284475 ins; 34553 del; 22607 mod
  Patch: https://git.openjdk.org/jdk/pull/13679.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13679/head:pull/13679

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

From jlaskey at openjdk.org  Tue May  9 12:54:50 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:54:50 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v67]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <l7J5wI3ZLIVlZLDWAOSqMm43O9LPr7wZMEAlXpAz3ek=.15f31874-1c70-45ac-b63b-97a262b0fd51@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Recommended changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/53f6280d..8e83e10d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=65-66

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

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

From jlaskey at openjdk.org  Tue May  9 12:58:27 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 12:58:27 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v68]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Dangling <p>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/8e83e10d..2ac6252b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=67
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=66-67

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

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

From darcy at openjdk.org  Tue May  9 16:04:48 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 9 May 2023 16:04:48 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <FZfpnNgeSWv_zBF2Zi_t9N__2HRiPM9om-prQVYkQPo=.0f6bb954-3f1e-499d-9967-cad643fb6548@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/10889#pullrequestreview-1418983197

From jlaskey at openjdk.org  Tue May  9 16:24:24 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:24:24 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v69]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:

 - Merge branch 'master' into 8285932
 - Dangling <p>
 - Recommended changes
 - Requested changes
 - CSR recommendations
 - Merge branch 'master' into 8285932
 - Spacing
 - Tidy up
 - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
 - Typo
 - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

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

Changes: https://git.openjdk.org/jdk/pull/10889/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68
  Stats: 9330 lines in 73 files changed: 9233 ins; 23 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/10889.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/10889/head:pull/10889

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

From liach at openjdk.org  Tue May  9 16:26:08 2023
From: liach at openjdk.org (Chen Liang)
Date: Tue, 9 May 2023 16:26:08 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v68]
In-Reply-To: <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <-604u-rNn9gRrC9Q6UVQOjKKmfhlKoNzyTZnhrnv2lw=.448fc7f3-6aea-4352-abc7-2a4a252565da@github.com>
Message-ID: <cC6vWaC5XidjKv1fz6EfLtnEJSwFegkRZE_RKgc07VI=.2b746469-a931-4895-bb79-60871bb91afd@github.com>

On Tue, 9 May 2023 12:58:27 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Dangling <p>

TestJavacTaskScanner is failing because of the new `setPrevToken` added that changes the total element count. Just need to update the count to take the changes to `Scanner` into account.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540490098

From jlaskey at openjdk.org  Tue May  9 16:37:07 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:37:07 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v69]
In-Reply-To: <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
 <gSSu4Qochcw-uAqANO3_VCC5shkeMFjeyyqUZU3wPPI=.cd287eb8-87bf-4378-90c7-ed395fe164c5@github.com>
Message-ID: <VpUv5E3jOqLwYbNZ1xOWJ66XkPl27KYKeoIZBXIaoh0=.ee44084f-cdb4-4808-befb-5b0d7fabe20e@github.com>

On Tue, 9 May 2023 16:24:24 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

>> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).
>
> Jim Laskey has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits:
> 
>  - Merge branch 'master' into 8285932
>  - Dangling <p>
>  - Recommended changes
>  - Requested changes
>  - CSR recommendations
>  - Merge branch 'master' into 8285932
>  - Spacing
>  - Tidy up
>  - Remove @PeviewFeature(feature=PreviewFeature.Feature.STRING_TEMPLATES) from non-public classes
>  - Typo
>  - ... and 78 more: https://git.openjdk.org/jdk/compare/44fa12e7...f4f26611

Thanks for the heads up.

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

PR Comment: https://git.openjdk.org/jdk/pull/10889#issuecomment-1540506421

From jlaskey at openjdk.org  Tue May  9 16:43:15 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Tue, 9 May 2023 16:43:15 GMT
Subject: <i18n dev> RFR: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview) [v70]
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <9L5IuWB-IyF4NqldYaPlYKVt-29_ykeIwOu8z-x9jbk=.bb0ecc60-87aa-4a92-a6a0-d67cdf61050c@github.com>

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

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

  Update TestJavacTaskScanner.java

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10889/files
  - new: https://git.openjdk.org/jdk/pull/10889/files/f4f26611..6b09d2e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=69
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=10889&range=68-69

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

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

From jlu at openjdk.org  Tue May  9 17:18:31 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 May 2023 17:18:31 GMT
Subject: <i18n dev> Integrated: 8159337: Introduce a method in Locale class
 to return the language tags as per RFC 5646 convention
In-Reply-To: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
References: <pMHzofdwJyeZ2Pcr9aacOKo87TP39nYnbhvTchx6qc0=.f644211b-8ba3-4223-9cc2-bfe7f8fd8136@github.com>
Message-ID: <5t6PS3dY3e-ZuSF0U6AVF8pbmynoAwHR59Xpeg7QIQU=.53872529-75aa-4d8e-89f8-179624233526@github.com>

On Wed, 26 Apr 2023 22:20:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds the method `caseFoldLanguageTag(String languageTag)` to java.util.Locale.
> 
> This method case folds a language tag to adhere to _[section 2.1.1. Formatting of Language Tags of RFC5646](https://www.rfc-editor.org/rfc/rfc5646.html#section-2.1)_. This format is defined as _"All subtags, including extension and private use subtags, use lowercase letters with two exceptions: two-letter and four-letter subtags that neither appear at the start of the tag nor occur after singletons.  Such two-letter subtags are all uppercase ... and four-letter subtags are titlecase."_.
> 
> 
> In order to match the behavior of existing language tag related Locale methods, this method matches the 2.1.1 RFC5646 specification with the following **exceptions**:
> - Will not case fold variant subtags
> - Will not case fold private use subtags prefixed by "lvariant"
> 
> As an example, `caseFoldLanguageTag("ja-kana-jp-x-lvariant-Oracle-JDK-Standard-Edition")` returns _"ja-Kana-JP-x-lvariant-Oracle-JDK-Standard-Edition"_. Further examples can be seen in the test file.

This pull request has now been integrated.

Changeset: 82bcee76
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/82bcee76ea6f5a0624c3ed1d7e4a262d59bfbe37
Stats:     279 lines in 3 files changed: 274 ins; 3 del; 2 mod

8159337: Introduce a method in Locale class to return the language tags as per RFC 5646 convention

Reviewed-by: naoto, rriggs

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

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

From jlu at openjdk.org  Tue May  9 20:47:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 9 May 2023 20:47:51 GMT
Subject: <i18n dev> RFR: 8281103: Give example for Locale that is English
 and follows the ISO standards
Message-ID: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>

Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`

The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 

This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

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

Commit messages:
 - Correct param in example
 - Copyright year
 - JDK-8281103

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

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

From rriggs at openjdk.org  Tue May  9 20:57:18 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 9 May 2023 20:57:18 GMT
Subject: <i18n dev> RFR: 8281103: Give example for Locale that is
 English and follows the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <fWZWfwGK_9CS91zVL6JLyIImwv62fi95J9dTe5Z8D5o=.1b004d4c-d7f8-4a03-8e3e-bee5c7e1da09@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419440879

From lancea at openjdk.org  Tue May  9 21:03:24 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 9 May 2023 21:03:24 GMT
Subject: <i18n dev> RFR: 8281103: Give example for Locale that is
 English and follows the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <f3uLD_eHAILXkN4jhUE2QGi2u88xsogyUdiqw_2Y4SI=.1707d87d-3198-4216-90a8-17f57b0de645@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419448467

From naoto at openjdk.org  Tue May  9 21:12:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 May 2023 21:12:18 GMT
Subject: <i18n dev> RFR: 8281103: Give example for Locale that is
 English and follows the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <Qj0NeP2sipC3XrYfzmXX6lzUjX6w2IAlmN2Jq6tz70U=.618ed9e4-071b-4f4f-9819-313b4a7d63c4@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13893#pullrequestreview-1419459581

From duke at openjdk.org  Tue May  9 23:22:28 2023
From: duke at openjdk.org (duke)
Date: Tue, 9 May 2023 23:22:28 GMT
Subject: <i18n dev> Withdrawn: 8302872: Speed up
 StringLatin1.regionMatchesCI_UTF16
In-Reply-To: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
References: <4SMUYcB8RTO3-nB444DCUHNcdDCmcO7WtCBCf7Gc9KM=.c8f2ab0b-1b72-461b-88e8-135318e092cc@github.com>
Message-ID: <ZH6kjU9CDlYQoOzFe20uLjXz4eb4Q25c4MelLiKPi5M=.09fe67c7-1947-4c3f-b53a-94a1e3f4eb09@github.com>

On Sat, 18 Feb 2023 18:22:49 GMT, Eirik Bjorsnos <duke at openjdk.org> wrote:

> This PR continues the efforts from #12632 to speed up case-insensitive string matching.
> 
> We now tackle case-insensitive comparison of mixed-coder strings, implemented in `StringLatin1.regionMatchesCI_UTF16`
> 
> Key insights:
> 
> - If the UTF16 code point is also in latin1 range, we can leverage improvements from 12632 directly by calling `CharacterDataLatin1.equalsIgnoreCase`
> - There are exactly 7 non-latin1 Unicode code points which case fold into the latin1 range. We can special-case our comparison of these code points by adding the method `CharacterDataLatin1.latin1CaseFold`.
> - To avoid checking of `a == b` twice, this check is lifted out of `CharacterDataLatin1.equalsIgnoreCase` and the two callers are updated to check that `a != b` before calling the method. 
>  
> For completeness, the RegionMatches test is updated to also compare Turkic dotted/dotless 'i's against the uppercase ASCII 'I', not just the lowercase one.  Not stricktly related to the purpose of this PR, but it did help catch a regression introduced in an earlier iteration of the PR.   
> 
> To guard against regressions caused by future changes to the set of Unicode code points folding into latin1, a new test is added to `EqualsIgnoreCase` which identifies all such code points and verifies they are compared correcty.
> 
> Performance is tested for matching and mismatching cases of selected code point pairs picked from the ASCII letter, ASCII number, latin1 letter and non-latin Unicode letter ranges. Results in the first comment below.

This pull request has been closed without being integrated.

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

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

From jlaskey at openjdk.org  Wed May 10 11:38:34 2023
From: jlaskey at openjdk.org (Jim Laskey)
Date: Wed, 10 May 2023 11:38:34 GMT
Subject: <i18n dev> Integrated: JDK-8285932 Implementation of JEP 430 String
 Templates (Preview)
In-Reply-To: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
References: <c0VDSJWAZWXjtGzKp9kbTyYifNOC07f0yxd9ifp8DgQ=.4ab9b5a5-fe2f-4caa-8a7f-f4c8b7e64001@github.com>
Message-ID: <BRO6F0Nwun-KAL86AIlKg6QjPxW-8E4_-wWH8VpPu0M=.e092c60c-021c-455d-b85e-f1265fd65082@github.com>

On Thu, 27 Oct 2022 20:16:14 GMT, Jim Laskey <jlaskey at openjdk.org> wrote:

> Enhance the Java programming language with string templates, which are similar to string literals but contain embedded expressions. A string template is interpreted at run time by replacing each expression with the result of evaluating that expression, possibly after further validation and transformation. This is a [preview language feature and API](http://openjdk.java.net/jeps/12).

This pull request has now been integrated.

Changeset: 4aa65cbe
Author:    Jim Laskey <jlaskey at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4aa65cbeefe44f29fbe6ea013809dcee579df9ff
Stats:     9331 lines in 74 files changed: 9233 ins; 23 del; 75 mod

8285932: Implementation of JEP 430 String Templates (Preview)

Reviewed-by: mcimadamore, rriggs, darcy

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

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

From naoto at openjdk.org  Wed May 10 20:19:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 20:19:59 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale
Message-ID: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>

The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

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

Commit messages:
 - Test refinement
 - Clean-up
 - javadoc
 - 8307547: Support for multiple collation tables

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

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

From naoto at openjdk.org  Wed May 10 20:28:11 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 20:28:11 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v2]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

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

  http -> https

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/276178f8..9f0eb048

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

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

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

From jlu at openjdk.org  Wed May 10 21:27:42 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 10 May 2023 21:27:42 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <0a7KCg13e-0wh_Tu_sTWJOARq4DevBCS3c5TMSfDZ-g=.85110b0c-af3f-47c8-b9cb-85eae3cf4fef@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

LGTM, does it make sense to add some other locale's collation variants?

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1542828520

From naoto at openjdk.org  Wed May 10 21:54:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 10 May 2023 21:54:45 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <mHaErUp79h0hStQhWoN-c4sfoPXifLKYc999SUbIp3M=.afcc16f5-6e14-46c3-b1de-d18f05524770@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

Thanks, Justin

> does it make sense to add some other locale's collation variants?

Maybe, but I am not seeing any requests for adding more collation variants. This enhancement is mainly for those who need the old Swedish collation as a workaround

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1542854951

From jlu at openjdk.org  Thu May 11 00:00:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 00:00:49 GMT
Subject: <i18n dev> Integrated: 8281103: Give example for Locale that is
 English and follows the ISO standards
In-Reply-To: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
References: <xz4PW5BhD1OQ2gWjtwln73jnYwkGxmmwFWOkk6Cuw5U=.b5b6b9da-1bfb-436e-9f7c-8edf7b4eeaba@github.com>
Message-ID: <t42IBmNQFSz16RW8CTYyzhIHExuNRM7kxlLR3pzeoWM=.366393c1-e8e3-4ab3-a4e5-d442856cea93@github.com>

On Tue, 9 May 2023 20:39:19 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which adds an example snippet to `java.time.temporal.WeekFields.of(Locale locale)`
> 
> The snippet demonstrates how to create a Locale that has English Locale qualities with an ISO-8601 first day of the week. 
> 
> This snippet was added as there was a desire for an English/ISO-8601 Locale constant to be added, but the existing methods in the JDK are better suited for accomplishing this.

This pull request has now been integrated.

Changeset: 4795c395
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4795c395e9799719dfcdd947fe8905f25f3a11a2
Stats:     9 lines in 1 file changed: 8 ins; 0 del; 1 mod

8281103: Give example for Locale that is English and follows the ISO standards

Reviewed-by: rriggs, lancea, naoto

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

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

From jlu at openjdk.org  Thu May 11 00:02:43 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 00:02:43 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n
Message-ID: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>

Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

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

Commit messages:
 - copyright years
 - property resource bundle changes
 - list resource bundle changes
 - resource bundle changes
 - currency changes
 - locale changes

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

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

From alanb at openjdk.org  Thu May 11 09:47:45 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 May 2023 09:47:45 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v2]
In-Reply-To: <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
Message-ID: <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>

On Wed, 10 May 2023 20:28:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   http -> https

src/java.base/share/classes/java/text/Collator.java line 131:

> 129:  * </blockquote>
> 130:  * may return a {@code Collator} instance with the traditional sorting, which
> 131:  * gives 'v' and 'w' the same sorting order.

The overall intent and wording looks okay but I wonder if it should be in the getInstance methods instead. Also wondering whether impNote is right because it's both informational for developers using the API and useful to implementors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1190915577

From jlu at openjdk.org  Thu May 11 15:48:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 15:48:40 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java
Message-ID: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>

Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).

The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same.

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

Commit messages:
 - Replace ws with escaped newline
 - get rid of ws
 - Reduce duplication
 - Merge master and resolve conflicts
 - Reorder methods / text variables
 - Use Java text blocks and String format

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

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

From naoto at openjdk.org  Thu May 11 18:06:34 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 18:06:34 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v2]
In-Reply-To: <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <9J6oNgHT4551IurySPLQIdHl-3WC9cuAtmUcImwWk4o=.6db770ec-ff27-4b37-8791-8c6a4c14d414@github.com>
 <B1v_fYstfh9PyopYCIaBvIgPTmuPDycG35Wb6bxF2K8=.184ecc72-a3b4-471e-bba4-6556b3cee582@github.com>
Message-ID: <yJSz4AgUfl5hVlfgZwdnmn5h10js29Z6KlQrzzgLlGs=.51a9e9ce-1b0e-4a9a-a3df-31f186512584@github.com>

On Thu, 11 May 2023 09:44:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   http -> https
>
> src/java.base/share/classes/java/text/Collator.java line 131:
> 
>> 129:  * </blockquote>
>> 130:  * may return a {@code Collator} instance with the traditional sorting, which
>> 131:  * gives 'v' and 'w' the same sorting order.
> 
> The overall intent and wording looks okay but I wonder if it should be in the getInstance methods instead. Also wondering whether impNote is right because it's both informational for developers using the API and useful to implementors.

Thanks. Will move it out of the class description into each `getInstance()` method, changing @implNote to @apiNote

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1191526144

From naoto at openjdk.org  Thu May 11 18:35:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 18:35:50 GMT
Subject: <i18n dev> RFR: 8307547: Support for multiple collations for a
 locale [v3]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <Yb213i_JoiQcTzX08Tj6OehSfDsOHrcMrq44FrQ_fZY=.5aac62a5-02d2-4f11-a8b7-aac9d9beacb6@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

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

  Review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/9f0eb048..29b1c8c4

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

  Stats: 29 lines in 1 file changed: 12 ins; 16 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

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

From jlu at openjdk.org  Thu May 11 20:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:21:57 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v6]
In-Reply-To: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
Message-ID: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>

> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
> 
> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Convert the merged master changes to UTF-8
 - Merge master and fix conflicts
 - Close streams when finished loading into props
 - Adjust CF test to read in with UTF-8 to fix failing test
 - Reconvert CS.properties to UTF-8
 - Revert all changes to CurrencySymbols.properties
 - Bug6204853 should not be converted
 - Copyright year for CompileProperties
 - Redo translation for CS.properties
 - Spot convert CurrencySymbols.properties
 - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

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

Changes: https://git.openjdk.org/jdk/pull/12726/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12726&range=05
  Stats: 28877 lines in 493 files changed: 14 ins; 1 del; 28862 mod
  Patch: https://git.openjdk.org/jdk/pull/12726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/12726/head:pull/12726

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

From naoto at openjdk.org  Thu May 11 20:25:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:25:37 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>

On Wed, 10 May 2023 23:54:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

Looks good overall. Some minor comments follow.

src/java.base/share/classes/java/util/Currency.java line 517:

> 515:      * If the default {@link Locale.Category#DISPLAY DISPLAY} locale
> 516:      * contains "rg" (region override)
> 517:      * {@linkplain Locale##def_locale_extension Unicode extensions},

Good catch on plurals

src/java.base/share/classes/java/util/PropertyResourceBundle.java line 85:

> 83:  * {@snippet lang=properties :
> 84:  *     # MessageFormat pattern
> 85:  *     s1=Die Platte \"{1}\" enth\u00E4lt {0}.

I was wondering if the Unicode escape would convert correctly or not, so I tried and found it fine.

src/java.base/share/classes/java/util/ResourceBundle.java line 334:

> 332:  *         if (key.equals("cancelKey")) {
> 333:  *            return "Cancel";
> 334:  *         }

Indentation is inconsistent

src/java.base/share/classes/java/util/ResourceBundle.java line 354:

> 352:  *         // don't need okKey, since parent level handles it.
> 353:  *         if (key.equals("cancelKey")) {
> 354:  *            return "Abbrechen";

Same here

src/java.base/share/classes/java/util/ResourceBundle.java line 512:

> 510:      * Calling this method is equivalent to calling
> 511:      * {@snippet lang=java :
> 512:      *     (String[]) getObject(key); // @link substring="getObject" target="#getObject(java.lang.String)"

`// @link` can be a separate line, placed on top of the target text

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

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1423359717
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191640956
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191642383
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191642638
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191643088
PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191652752

From jlu at openjdk.org  Thu May 11 20:39:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:39:57 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

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

  Review: Move links on top, fix indentation in example

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13920/files
  - new: https://git.openjdk.org/jdk/pull/13920/files/179671e3..e56955e1

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

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

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

From naoto at openjdk.org  Thu May 11 20:37:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:37:40 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>

On Thu, 11 May 2023 15:40:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, `EquivMapsGenerator.java` builds the same.

Looks good, with some cosmetic suggestions

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 269:

> 267:              * or visit www.oracle.com if you need additional information or have any
> 268:              * questions.
> 269:             */\n

Can be a simple new line instead of `\n`. Also holds for other text blocks.

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 272:

> 270:             """;
> 271: 
> 272:     private static final String headerText =

Not your change, but I'd capitalize those static final Strings

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 295:

> 293:     }
> 294: 
> 295:     private static final String getlsrText(){

getLSRText?

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

PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1423387718
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191658464
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191661027
PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1191663140

From jlu at openjdk.org  Thu May 11 20:39:58 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 20:39:58 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <c2-mW9V9c-k788lDgDKCx9wvZ0J0JAqmeSHViSHp1e4=.1149b02f-eb65-46ec-9158-7054eda5c25a@github.com>
Message-ID: <PlfFNmidSzX_UU1fxR59DFpHkCOw7NJGT1hrunpjEDM=.0c7d87e2-4efc-41de-b15b-5563b5e9224b@github.com>

On Thu, 11 May 2023 20:21:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Move links on top, fix indentation in example
>
> src/java.base/share/classes/java/util/ResourceBundle.java line 512:
> 
>> 510:      * Calling this method is equivalent to calling
>> 511:      * {@snippet lang=java :
>> 512:      *     (String[]) getObject(key); // @link substring="getObject" target="#getObject(java.lang.String)"
> 
> `// @link` can be a separate line, placed on top of the target text

Thanks for the review, moved the links on top, and fixed the indentation in the example snippet.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13920#discussion_r1191663234

From naoto at openjdk.org  Thu May 11 20:51:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 20:51:37 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

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

  Added "reformed" tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/29b1c8c4..4ab39664

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

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

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

From jlu at openjdk.org  Thu May 11 21:39:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:39:50 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <w-aBr-h4WVCyWPDEHHatqoQcdQJp6dN4eld2Y-85Ak4=.558819ae-881a-42fb-8b67-7a6b5618e323@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

Wondering if anyone has any thoughts on the consequences of this PR, in relation to Intellj's (and other IDEs) default encoding for .properties files. Intellj sets the default encoding for .properties files to ISO-8859-1, which would be the wrong encoding if the .properties files are converted to UTF-8 native. This would cause certain key,values to be skewed when represented in the file. 

Although the default file-encoding for .properties can be switched to UTF-8, it is not the default.

Wondering what some solutions/thoughts to this are.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544708830

From naoto at openjdk.org  Thu May 11 21:51:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 11 May 2023 21:51:13 GMT
Subject: <i18n dev> RFR: 8301991: Convert l10n properties resource
 bundles to UTF-8 native [v6]
In-Reply-To: <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
References: <0MB7FLFNfaGEWssr9X54UJ_iZNFWBJkxQ1yusP7fsuY=.3f9f3de5-fe84-48e6-9449-626cac42da0b@github.com>
 <cqbVzCGKX2oiVnvlF5eU47L-vXRpPXyuI7DK6Eu9Nf0=.7375f607-3413-4171-a51b-b841908e0684@github.com>
Message-ID: <2apKDcin5cwY53zz5jOIPhqm7cCWhyYMdsXGU4TauEk=.781d695e-39fe-46f7-bd03-be514ca0b85c@github.com>

On Thu, 11 May 2023 20:21:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> This PR converts Unicode sequences to UTF-8 native in .properties file. (Excluding the Unicode space and tab sequence). The conversion was done using native2ascii.
>> 
>> In addition, the build logic is adjusted to support reading in the .properties files as UTF-8 during the conversion from .properties file to .java ListResourceBundle file.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
> 
>  - Convert the merged master changes to UTF-8
>  - Merge master and fix conflicts
>  - Close streams when finished loading into props
>  - Adjust CF test to read in with UTF-8 to fix failing test
>  - Reconvert CS.properties to UTF-8
>  - Revert all changes to CurrencySymbols.properties
>  - Bug6204853 should not be converted
>  - Copyright year for CompileProperties
>  - Redo translation for CS.properties
>  - Spot convert CurrencySymbols.properties
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/4386d42d...f15b373a

I think this is fine, as those properties files are JDK's own. I believe the benefit of moving to UTF-8 outweighs the issue you wrote, which can be remedied by changing the encoding in the IDEs.

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

PR Comment: https://git.openjdk.org/jdk/pull/12726#issuecomment-1544722480

From jlu at openjdk.org  Thu May 11 21:53:19 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:53:19 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v2]
In-Reply-To: <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <J_ab01vZ5eZ85t1DKECQ6etN0z_b4y1JczKyGT5knWA=.924d127b-91ed-4c6b-9a25-e833fc419eaf@github.com>
Message-ID: <ssCHX7JLudsKjU-KVtpJfKwf7se9mUdBl7rLlEzTVFw=.d412f622-1a8a-4110-a454-13fe33083fcf@github.com>

On Thu, 11 May 2023 20:34:48 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Adjust new lines to appease jcheck?
>>  - Review: remove new line literals for new lines
>>  - Review: fix method / var names
>
> Looks good, with some cosmetic suggestions

Thanks for the review @naotoj , implemented the suggestions.

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

PR Comment: https://git.openjdk.org/jdk/pull/13935#issuecomment-1544713696

From jlu at openjdk.org  Thu May 11 21:53:17 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 21:53:17 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v2]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <t_inA_q2NYETRaP3nslz2Vv4qKJJdAqJuJS5-0qQcOw=.44f9dab0-bdcb-4c44-a966-e365b13d77c3@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

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

 - Adjust new lines to appease jcheck?
 - Review: remove new line literals for new lines
 - Review: fix method / var names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/7a43ab93..9574a984

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

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

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

From jlu at openjdk.org  Thu May 11 22:23:47 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 11 May 2023 22:23:47 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v3]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

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

  Remove more ws in text block

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/9574a984..33fd7993

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

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

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

From alanb at openjdk.org  Fri May 12 08:48:46 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 May 2023 08:48:46 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

The update, and API note in Collator.getInstance(Locale), looks okay to me. I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1545395782

From naoto at openjdk.org  Fri May 12 16:35:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:35:46 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
Message-ID: <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>

On Fri, 12 May 2023 08:45:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.

I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546003990

From naoto at openjdk.org  Fri May 12 16:41:48 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:41:48 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
Message-ID: <H2i9kVLWIMvXhO43PTAT8N5srOYGLnqIFu_2QJhcF2o=.5b3cd0d3-dc4f-4723-a25d-c78f1c8a0147@github.com>

On Thu, 11 May 2023 20:39:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move links on top, fix indentation in example

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1424841206

From naoto at openjdk.org  Fri May 12 16:43:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 16:43:55 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v3]
In-Reply-To: <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
Message-ID: <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>

On Thu, 11 May 2023 22:23:47 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
>> 
>> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove more ws in text block

make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344:

> 342:     }
> 343: 
> 344:     private static final String footerText = "    }\n\n}";

I'd prefer this one also be uppercased (and moved to a more suitable location).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192593829

From srl at openjdk.org  Fri May 12 16:43:52 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 16:43:52 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <KoDGaq-MGrIEores-XK4J_BSLNYYfc-z4YIY37VGfPA=.508baaea-00bb-4269-8046-02f76046d308@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by srl (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1424842005

From srl at openjdk.org  Fri May 12 16:43:56 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 16:43:56 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
Message-ID: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>

On Fri, 12 May 2023 16:32:57 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
> 
> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)

`-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546013166

From lancea at openjdk.org  Fri May 12 17:02:44 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 17:02:44 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n [v2]
In-Reply-To: <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
 <aQtLPpIumIPaSdmeDnWJ3stq4wePpCq4V1YU0B6sO2I=.2b3ab5f1-1fa9-48a6-9628-6a8e0bc7b196@github.com>
Message-ID: <yMrAU7r0vU-D9V8C2-Bt6tif8m8B2JIc34Zf1JocL9s=.41411806-17c5-404f-a794-2e43a4002375@github.com>

On Thu, 11 May 2023 20:39:57 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Move links on top, fix indentation in example

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13920#pullrequestreview-1424868788

From naoto at openjdk.org  Fri May 12 17:11:45 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 17:11:45 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <NomFKC6d8uS3CoRupgiwZwQYqOAzeZWY0r7zrDiwcLA=.ceb8d7f2-97a1-4088-8c35-0187cf2db221@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

>>> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>
>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
> 
> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
> 
> @AlanBateman 
>> Locale.forLanguageTag supports more than BCP 47 language tag strings
> 
> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
> 
>> so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> - https://www.rfc-editor.org/info/bcp47
> - https://www.rfc-editor.org/rfc/rfc6067

Thanks @srl295 
I am just curious how CLDR handles the default switch of Swedish collation. Now the `traditional` collation used to be `standard`, and `standard` used to be `reformed`. How do apps specify their desired collation in Swedish, regardless of CLDR versions?

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546042805

From srl at openjdk.org  Fri May 12 17:18:46 2023
From: srl at openjdk.org (Steven Loomis)
Date: Fri, 12 May 2023 17:18:46 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <JGk3tO3V-lmArLwxd9EIJeMSpIXHz3pMa_ZK7_B2jv0=.f29801b0-0c9f-4ec8-a5a1-d4d1834adcd5@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

>>> I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>
>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>> 
>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
> 
> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
> 
> @AlanBateman 
>> Locale.forLanguageTag supports more than BCP 47 language tag strings
> 
> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
> 
>> so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> - https://www.rfc-editor.org/info/bcp47
> - https://www.rfc-editor.org/rfc/rfc6067

> Thanks @srl295
> I am just curious how CLDR handles the default switch of Swedish collation. Now the `traditional` collation used to be `standard`, and `standard` used to be `reformed`. How do apps specify their desired collation in Swedish, regardless of CLDR versions?

I don't know off the top of my head but digging around I found https://unicode-org.atlassian.net/browse/CLDR-7088 and cross linked some tickets. Can you ask around on those?

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546050297

From jlu at openjdk.org  Fri May 12 17:25:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:25:45 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v4]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

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

  Review: capitalize and move footer text. Add comments to main

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/33fd7993..b4e6e683

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

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

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

From jlu at openjdk.org  Fri May 12 17:25:49 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:25:49 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v3]
In-Reply-To: <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <CMZz36yOM2DwaXQC9GGqPkwT0W3ZMobKnZf8-YVjE4Q=.4b23cc07-dea5-41b3-9927-211eeca5bf8a@github.com>
 <HMEPBdpLW0t6cMHhZrfadFg3UH6ci9HP5j5aJOuHaUI=.57791e5d-2ab9-4305-b158-6b2df3d2e3c5@github.com>
Message-ID: <Qcw3TKCW56u8Ymjm6bbRXA5RUNHuKm1X0B0r0P6R4jM=.41241fd2-6b3c-48ce-90ef-3423e5fbc161@github.com>

On Fri, 12 May 2023 16:41: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:
>> 
>>   Remove more ws in text block
>
> make/jdk/src/classes/build/tools/generatelsrequivmaps/EquivMapsGenerator.java line 344:
> 
>> 342:     }
>> 343: 
>> 344:     private static final String footerText = "    }\n\n}";
> 
> I'd prefer this one also be uppercased (and moved to a more suitable location).

ah, missed that one, probably because of it's location too. Made uppercased and moved closer to the rest of the static text variables.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13935#discussion_r1192626527

From naoto at openjdk.org  Fri May 12 17:32:49 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 17:32:49 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v4]
In-Reply-To: <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
 <kNboTkeQjR_04uuXfv6HXD2b-WUDciv4wQjb3M12JcM=.f74b819a-78f9-4934-8e48-2efc76f6d8cd@github.com>
Message-ID: <2WPO1cEA46g85vIgS3teOTHpeiLRbG0ee7iWQSfazfM=.a7646928-a374-49e9-b488-656483af9ff1@github.com>

On Fri, 12 May 2023 17:25:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
>> 
>> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: capitalize and move footer text. Add comments to main

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13935#pullrequestreview-1424907858

From jlu at openjdk.org  Fri May 12 17:40:46 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 17:40:46 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <qkG0chvl8TtS_j5_SjQQ7z4LBqRmek36WArmxkm3izc=.dbea81be-d218-452a-98eb-4e007ed9fd41@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by jlu (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1424917959

From jlu at openjdk.org  Fri May 12 18:02:59 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 12 May 2023 18:02:59 GMT
Subject: <i18n dev> RFR: 8308021: Update IANA Language Subtag Registry to
 Version 2023-05-11
Message-ID: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>

Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

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

Commit messages:
 - Update LSRTest.java
 - Update registry.txt

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

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

From lancea at openjdk.org  Fri May 12 18:08:42 2023
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 12 May 2023 18:08:42 GMT
Subject: <i18n dev> RFR: 8308021: Update IANA Language Subtag Registry
 to Version 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <3ACKBswT4rjdq9JYYK_ASVFNsUrsdqRLelkwPvMD1CA=.18ffc1d2-5215-41c7-beb8-b59221532c39@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13962#pullrequestreview-1424952709

From naoto at openjdk.org  Fri May 12 18:28:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 12 May 2023 18:28:46 GMT
Subject: <i18n dev> RFR: 8308021: Update IANA Language Subtag Registry
 to Version 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <PQCQ1-gxLgk9aezNKZcWJdCFeQUdgUjTQFvuJ0t9G7E=.3160a03a-b57d-48e8-a4e6-0e1228af7b8a@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13962#pullrequestreview-1424976281

From xuelei at openjdk.org  Fri May 12 19:51:57 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Fri, 12 May 2023 19:51:57 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for java.base
Message-ID: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>

Hi,

May I have this update reviewed?

The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.

Thanks,
Xuelei

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

Commit messages:
 - update copyright year
 - 8308022: update for deprecated sprintf for java.base

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

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

From alanb at openjdk.org  Sun May 14 06:39:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:39:55 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <o-gceMnFNNkSKKU-jp3B7uNhUDJHcFIXErjMWNhoSgc=.1c8f778a-201c-4652-9498-bd06cd1d5396@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/13917#pullrequestreview-1425494382

From alanb at openjdk.org  Sun May 14 06:39:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 14 May 2023 06:39:56 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
Message-ID: <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>

On Fri, 12 May 2023 16:41:20 GMT, Steven Loomis <srl at openjdk.org> wrote:

> > so is this considered a private use language tag
> 
> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
> 
> * https://www.rfc-editor.org/info/bcp47
> * https://www.rfc-editor.org/rfc/rfc6067

Good, I don't think I have any other questions on this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1546821026

From itakiguchi at openjdk.org  Mon May 15 02:55:46 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 15 May 2023 02:55:46 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module
Message-ID: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>

According to "JDK 20 Internationalization Guide"
https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.

- PCK (x-PCK)
- EUC_JP_Solaris (x-eucJP-Open)

These are not supported by Linux platform, so they should not be in java.base module.

Note:
GHA Linux x86 builds were failed.
I think it's not related by my modified code.
I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

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

Commit messages:
 - 8308046: [Linux] Move Solaris related Japanese charsets from java.base to jdk.charsets module

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

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

From naoto at openjdk.org  Mon May 15 16:31:47 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 16:31:47 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
 <3-yGsDHmBcL6MdVuyS3HWK5a9-sSfkXsBHVEOUcW1W0=.8ff7083a-9c4c-4529-a0d9-9d0ba49303a8@github.com>
 <x1shHzMm-4SWbRgVw08cjsCFtBHmu7e6ogs3Rp2Ha1U=.ac71b8ab-835e-4fc6-b327-4911f44d52b8@github.com>
 <584rhxgv-lrG4qPkucfzUMuge8xUZh-vth1MH1HFg7Q=.f114ed3e-48d7-4f85-b358-9ed3d997fefb@github.com>
 <o4wDF2ZONPiqzKZLDKUegFu2zBoGv0tswAfiVpX9BLo=.222e305e-bbf5-4fdb-a9ee-3458ae3919d8@github.com>
Message-ID: <QWBoHymJtt20dBc3eiDjiBn-WlmWKKl9iqVyp2xmoks=.b9342e6c-d7de-4283-87bf-7b0290dfd868@github.com>

On Sun, 14 May 2023 06:37:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > I'm just wondering where a developer might go to get a definitive list, i.e. aside from this API note, how would they know that "-trad" or "-traditional" can be used to configure the ordering. Locale.forLanguageTag supports more than BCP 47 language tag strings so is this considered a private use language tag.
>>> 
>>> I think those should go into Oracle JDK's `Supported Locales` document. Created a task to include them (https://bugs.openjdk.org/browse/JDK-8308018)
>> 
>> `-u-co` is defined [here](https://www.unicode.org/reports/tr35/#UnicodeCollationIdentifier) (UTS#35) and the keys are in the datafile [here (link to `main` branch!)](https://github.com/unicode-org/cldr/blob/main/common/bcp47/collation.xml) - note the `since=` attribute, these are very stable.
>> 
>> @AlanBateman 
>>> Locale.forLanguageTag supports more than BCP 47 language tag strings
>> 
>> It should still be all valid BCP47 including extensions and private use (such as x-lvalue). 
>> 
>>> so is this considered a private use language tag
>> 
>> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
>> - https://www.rfc-editor.org/info/bcp47
>> - https://www.rfc-editor.org/rfc/rfc6067
>
>> > so is this considered a private use language tag
>> 
>> Not private use at all. The `-u-` subtag is registered, and the links above are from the registrar, see
>> 
>> * https://www.rfc-editor.org/info/bcp47
>> * https://www.rfc-editor.org/rfc/rfc6067
> 
> Good, I don't think I have any other questions on this now.

Thanks, @AlanBateman for the review.
@srl295 thanks. I found CLDR's collation documents are a bit outdated. Filed an issue here: https://unicode-org.atlassian.net/jira/software/c/projects/CLDR/issues/CLDR-16638

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

PR Comment: https://git.openjdk.org/jdk/pull/13917#issuecomment-1548178251

From naoto at openjdk.org  Mon May 15 17:09:59 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 17:09:59 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <Y8JiTAzeyM2YEjbGf5pMkBRc3Uom1xUBtJtUi_8dMw8=.8b8a8d67-0792-4aa9-a06a-71636102736c@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

Looked at TimeZone_md.c and Console_md.c, and the changes look reasonable.

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

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427001957

From dfuchs at openjdk.org  Mon May 15 17:23:46 2023
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 15 May 2023 17:23:46 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

The libnet changes look reasonable to me.

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

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1427023621

From jlu at openjdk.org  Mon May 15 18:59:45 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 18:59:45 GMT
Subject: <i18n dev> RFR: 8300794: Use @snippet in java.util:i18n [v3]
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <pDRk7Ri8s1v-idMcHBCKyoLyruL4ci99De3ct5nntvg=.00a6ccfb-abf3-4e08-bb0a-7d500e34b257@github.com>

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

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

  Use elipsis replacement in snippet tag recommended in JDK PR #13957

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13920/files
  - new: https://git.openjdk.org/jdk/pull/13920/files/e56955e1..e15cacb3

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

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

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

From jlu at openjdk.org  Mon May 15 19:49:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 19:49:55 GMT
Subject: <i18n dev> RFR: 8306597: Improve string formatting in
 EquivMapsGenerator.java [v5]
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <GhUOBOA6D-6LUWw6XTl1xx8mppzvvhpxwDSVJeP_JjY=.e4a17098-61a4-4945-a30f-2a80dc06ab96@github.com>

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

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

  Align spacing of the maps to original

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13935/files
  - new: https://git.openjdk.org/jdk/pull/13935/files/b4e6e683..bc04b3d9

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

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

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

From naoto at openjdk.org  Mon May 15 19:52:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 15 May 2023 19:52:46 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <j4VdguGYWH3mSBWO7OXh0QcUDdikfRX66rkEAh7ZwdM=.6ff80446-67a3-48cb-a67e-0e766c6cbd23@github.com>

On Mon, 15 May 2023 00:28:41 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

Hi @takiguc,
I'd expect this change not specific to Japanese, but to all such as `Big-5`. BTW, I am thinking of removing Charsets for Solaris ([8308117](https://bugs.openjdk.org/browse/JDK-8308117))

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1548479096

From darcy at openjdk.org  Mon May 15 22:20:46 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Mon, 15 May 2023 22:20:46 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v4]
In-Reply-To: <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
 <e11-5E_j05by9vycmDItIe2keLvz3mNZb1a1ymOkY_U=.87076c45-cf27-4477-bf04-a672d041ba50@github.com>
Message-ID: <UKmZcsoyyPpP8SR6NVBdzxRGc9nyU2yICgNBA3TsHWY=.6c477050-bd4e-46b4-8ca2-984e67276b3d@github.com>

On Thu, 11 May 2023 20:51:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added "reformed" tests

src/java.base/share/classes/java/text/Collator.java line 230:

> 228:     /**
> 229:      * Gets the Collator for the desired locale.
> 230:      * @apiNote Implementations of {@code Collator} class may produce

For less l10n savvy readers, I suggest providing a bit more context in the apiNote, such as by explicitly mentioning Swedish and showing what getting the default collator would look like.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13917#discussion_r1194416496

From jlu at openjdk.org  Mon May 15 23:21:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 15 May 2023 23:21:57 GMT
Subject: <i18n dev> Integrated: 8306597: Improve string formatting in
 EquivMapsGenerator.java
In-Reply-To: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
References: <unLPWF0_s62XVp6vsBQ_7EUGpyTR5ghSAM48zzSni4E=.6011d31d-ca9a-4511-8f4c-7728052cb872@github.com>
Message-ID: <eU792pSRCTve1pt3YQMDWX8YrdMaC2S5uCP6Xpm223g=.6e0fd122-39e4-46a9-a8e5-88decfb97324@github.com>

On Thu, 11 May 2023 15:40:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review changes to `EquivMapsGenerator.java` (which is used to generate the Locale equivalencies for the JDK).
> 
> The file previously used large concatenated Strings, which are now replaced with text blocks, in addition to some cleanup. No functionality is changed, the Locale equivalencies builds the same.

This pull request has now been integrated.

Changeset: 31683722
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/316837226ecceb4daa14e2bc1be8ce120edbfdc9
Stats:     185 lines in 1 file changed: 94 ins; 70 del; 21 mod

8306597: Improve string formatting in EquivMapsGenerator.java

Reviewed-by: naoto

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

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

From itakiguchi at openjdk.org  Tue May 16 15:14:03 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 16 May 2023 15:14:03 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module [v2]
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13973/files
  - new: https://git.openjdk.org/jdk/pull/13973/files/192db59c..6fd12fcd

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

  Stats: 29 lines in 3 files changed: 22 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/13973.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13973/head:pull/13973

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

From naoto at openjdk.org  Tue May 16 16:24:13 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 16:24:13 GMT
Subject: <i18n dev> RFR: 8307547: Support variant collations [v5]
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <nIoWE4hN_63eeK9yH2FJ3JL1IYDqqo1Vq-ew9UD2K60=.baf89647-af31-4867-9e11-240ca3db159a@github.com>

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

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

 - Explicitly mention `Swedish` in the example.
 - Merge branch 'master' into JDK-8307547-multiple-collation
 - Added "reformed" tests
 - Review comments
 - http -> https
 - Test refinement
 - Clean-up
 - javadoc
 - 8307547: Support for multiple collation tables

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13917/files
  - new: https://git.openjdk.org/jdk/pull/13917/files/4ab39664..bfb19576

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

  Stats: 74851 lines in 982 files changed: 63014 ins; 5060 del; 6777 mod
  Patch: https://git.openjdk.org/jdk/pull/13917.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/13917/head:pull/13917

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

From jlu at openjdk.org  Tue May 16 17:13:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 16 May 2023 17:13:55 GMT
Subject: <i18n dev> Integrated: 8300794: Use @snippet in java.util:i18n
In-Reply-To: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
References: <UTz-wu8JfMmseNuTp3zWVpc1ZT_garY3v6f97BCWhI0=.b98d9ae4-b35f-4e35-88ab-0d95174b54df@github.com>
Message-ID: <u3DDR206bm3juimKufmuC5QY_Wm-Mecwzd9103ir60I=.2b3da974-2907-42d1-88a3-48a649be1699@github.com>

On Wed, 10 May 2023 23:54:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this javadoc only change which uses `@snippet` and `@linkplain` in i18n related util packages.

This pull request has now been integrated.

Changeset: 4e929918
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4e92991809aa62cf98543a58bec352ab8a2c7b3d
Stats:     131 lines in 5 files changed: 9 ins; 24 del; 98 mod

8300794: Use @snippet in java.util:i18n

Reviewed-by: naoto, lancea

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

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

From naoto at openjdk.org  Tue May 16 17:15:46 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 17:15:46 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module [v2]
In-Reply-To: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
Message-ID: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>

On Tue, 16 May 2023 15:14:03 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1550062543

From naoto at openjdk.org  Tue May 16 18:03:56 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 16 May 2023 18:03:56 GMT
Subject: <i18n dev> Integrated: 8307547: Support variant collations
In-Reply-To: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
References: <u7u4TqKc5ePOqUyQy5V9DorKhNbQ7rnxibNDCIpSqJE=.b9128c9d-9172-491f-8b34-5d5f2dcad2af@github.com>
Message-ID: <czWB0_KwhsYOovbrkSzFlbur6ZSxiRqmtl6GY9K40qE=.afa73ad6-130a-4e4f-b1b9-e6a1edb8b1ae@github.com>

On Wed, 10 May 2023 20:11:09 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The fix to https://bugs.openjdk.org/browse/JDK-8306927 switched the default collation for Swedish to the modern one. In order to provide a means for users who need the old collation, this PR intends to make `Collator` recognize the `co` Unicode locale extension so that multiple implementations for a locale can be provided. I would also like reviews for the corresponding CSR.

This pull request has now been integrated.

Changeset: f9a785e8
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9a785e855287ff6746ac8dc8f8f2e2f90c5be07
Stats:     80 lines in 4 files changed: 61 ins; 8 del; 11 mod

8307547: Support variant collations

Reviewed-by: srl, jlu, alanb

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

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

From itakiguchi at openjdk.org  Wed May 17 11:47:51 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 17 May 2023 11:47:51 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module [v2]
In-Reply-To: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
Message-ID: <JmbJq4nk9oiDPl36qbxWQnxiKB1YHpvs6J8JOD7MmCc=.0d17f96a-2ea6-49ae-9c78-ad13b6cb3398@github.com>

On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module
>
> I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

Hello @naotoj .
I'm not sure we can remove Solaris related charsets.
Somebody may use them for text communication between Solaris.
The latest change can move Big5_Solaris from java.base to jdk.charsets module.

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1551244863

From naoto at openjdk.org  Wed May 17 19:48:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 19:48:00 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for collation
 settings
Message-ID: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>

This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

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

Commit messages:
 - 8308108: Support Unicode extension for collation settings

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

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

From naoto at openjdk.org  Wed May 17 23:33:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 23:33:53 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module [v2]
In-Reply-To: <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
Message-ID: <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>

On Tue, 16 May 2023 17:13:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module
>
> I now think it is better simply removing Solaris-related charsets, as moving them from java.base to jdk.charsets would require unnecessary code changes in non-Solaris code.

> Hello @naotoj . I'm not sure we can remove Solaris related charsets. Somebody may use them for text communication between Solaris.

OK, maybe not now.

I think the fix may be simplified by changing access for those `DoubleByte-X.java.template` internals, such as `DecodeHolder` to `public`, instead of introducing those access methods. You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)

Also, please drop `Japanese` from the issue/PR title

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1552210567

From naoto at openjdk.org  Wed May 17 23:34:00 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 17 May 2023 23:34:00 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related Japanese charsets
 from java.base to jdk.charsets module [v2]
In-Reply-To: <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
Message-ID: <NawIfrkfWF6jn8-_zTybWLOQda6czGdr7r7NQ6X4ijo=.8dd1c828-b5b2-48b4-9b22-79f439707447@github.com>

On Tue, 16 May 2023 15:14:03 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related Japanese charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related Japanese charsets from java.base to jdk.charsets module

src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP_Open.java.template line 71:

> 69:         private static final DoubleByte.Decoder DEC0208 =
> 70:             (DoubleByte.Decoder)new JIS_X_0208().newDecoder();
> 71: 

Can these also be removed, by making those original ones in `EUC_JP` public?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13973#discussion_r1197162002

From naoto at openjdk.org  Thu May 18 00:52:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 00:52:55 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
Message-ID: <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>

On Wed, 17 May 2023 23:29:40 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)

Scratch that, you've already did it. Then you can remove these: 

import sun.nio.cs.DoubleByte;
import sun.nio.cs.HistoricallyNamedCharset;

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1552259703

From aturbanov at openjdk.org  Thu May 18 09:42:49 2023
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 May 2023 09:42:49 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <pCIEkF6tO7zBED3NtovGxm8ZVIBv1rry_9mZtajlAYQ=.74cd348c-e3e9-42b2-bedd-e717b43e9b81@github.com>

On Wed, 17 May 2023 19:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

test/jdk/sun/text/resources/Collator/CollationSettingsTests.java line 43:

> 41: 
> 42: public class CollationSettingsTests {
> 43:     private static final Collator ENG_DEF =  Collator.getInstance(Locale.ENGLISH);

nit
Suggestion:

    private static final Collator ENG_DEF = Collator.getInstance(Locale.ENGLISH);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1197616430

From naoto at openjdk.org  Thu May 18 16:42:23 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 16:42:23 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v2]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

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

  Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/c0c34bab..88a93839

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

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

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

From iris at openjdk.org  Thu May 18 17:03:51 2023
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 May 2023 17:03:51 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v2]
In-Reply-To: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
Message-ID: <SCQe4m4WmpTkYWgWthtVaAXxb1oiWnA-eSTwygKRZoI=.ccdaf1d0-eecc-4283-b5e1-357ff496aa79@github.com>

On Thu, 18 May 2023 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Looks good.

Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1433091642

From rriggs at openjdk.org  Thu May 18 18:23:55 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 18:23:55 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v2]
In-Reply-To: <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <38pDLy8zk4Ln68q9I07Lyjwdo6uVaVX27Ox4sHnjAZY=.19a7edf4-6e19-48ef-a186-32c6d03a27df@github.com>
Message-ID: <0UrJan8HJvt8arbtR0sKYixpvoY7m-rBsImek3Pmg_o=.c622654f-2c30-41d7-93c0-62ef24650b2b@github.com>

On Thu, 18 May 2023 16:42:23 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/sun/text/resources/Collator/CollationSettingsTests.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

src/java.base/share/classes/java/text/Collator.java line 236:

> 234:      * setting value is not recognized, strength and/or decomposition will not be
> 235:      * overridden.
> 236:      * @apiNote Implementations of {@code Collator} class may produce

The API should identify the valid values for ks and kk and the corresponding values as passed to setStrength and setDecomposition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1198141303

From naoto at openjdk.org  Thu May 18 19:44:01 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 18 May 2023 19:44:01 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

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

  Added a table for possible BCP47 values and their mappings

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/88a93839..627b78b3

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

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

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

From rriggs at openjdk.org  Thu May 18 19:58:49 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 18 May 2023 19:58:49 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <PcF-iRMWB2Wk4SfZBlL77iR9k5C4inGjqYaxdMAyHR0=.47a85bce-e2f3-486d-a569-34288ac19f08@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

Looks good

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1433363782

From alanb at openjdk.org  Fri May 19 08:02:49 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 08:02:49 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

src/java.base/share/classes/java/text/Collator.java line 264:

> 262:      * </table>
> 263:      * If the specified setting value is not recognized, strength and/or
> 264:      * decomposition will not be overridden.

The proposed update looks okay except for the last part "If the specified setting value is not recognized, strength and/or decomposition will not be overridden". I thin this could be clearer.
If I understand correctly, if the Unicode locale type for the given Locale might have a strength level and decomposition mode and this method makes a best effort to return a Collator with the expected level and mode. If so, then I think the javadoc needs to make this a bit clearer. Also, if the factory method returns a Collator that doesn't do what I asked, can I call setStrength/setDecomposition to change it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1198665295

From naoto at openjdk.org  Fri May 19 16:46:55 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 May 2023 16:46:55 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
Message-ID: <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>

On Fri, 19 May 2023 07:59:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added a table for possible BCP47 values and their mappings
>
> src/java.base/share/classes/java/text/Collator.java line 264:
> 
>> 262:      * </table>
>> 263:      * If the specified setting value is not recognized, strength and/or
>> 264:      * decomposition will not be overridden.
> 
> The proposed update looks okay except for the last part "If the specified setting value is not recognized, strength and/or decomposition will not be overridden". I thin this could be clearer.
> If I understand correctly, if the Unicode locale type for the given Locale might have a strength level and decomposition mode and this method makes a best effort to return a Collator with the expected level and mode. If so, then I think the javadoc needs to make this a bit clearer. Also, if the factory method returns a Collator that doesn't do what I asked, can I call setStrength/setDecomposition to change it?

I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199167454

From alanb at openjdk.org  Fri May 19 17:14:51 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 May 2023 17:14:51 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
 <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
Message-ID: <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>

On Fri, 19 May 2023 16:44:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?

It's the last sentence that bothers me. I understand the setters can't fail but the last sentence of the proposed text makes it sound like invalid settings will be just ignored. So I think this sentence needs to be re-examined as I don't think I understand what it is trying to say now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199193045

From jlu at openjdk.org  Fri May 19 18:25:56 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:25:56 GMT
Subject: <i18n dev> Integrated: 8308021: Update IANA Language Subtag
 Registry to Version 2023-05-11
In-Reply-To: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
References: <iIPuwaKdPI_0zXeGnvClUFB-k1jB8BHmDv6hpi7Lwys=.de585532-b094-46b0-acb9-204ae53617f3@github.com>
Message-ID: <rFhbBCBkTF36HlX-9dzcyBro9e_0Akw7GfJU1IfFBHY=.485e3b82-c6ca-4803-b906-59f8f7d8d36d@github.com>

On Fri, 12 May 2023 17:56:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this trivial fix which updates the IANA data to version 5/11/2023. As the update only includes variant sub-tags, there is no impact to JDK tests. The update can be found [here](https://mm.icann.org/pipermail/ietf-languages-announcements/2023-May/000087.html).

This pull request has now been integrated.

Changeset: 34468e1c
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/34468e1c916890d09e83d06094e225435c4642ba
Stats:     20 lines in 2 files changed: 17 ins; 0 del; 3 mod

8308021: Update IANA Language Subtag Registry to Version 2023-05-11

Reviewed-by: lancea, naoto

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

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

From jlu at openjdk.org  Fri May 19 18:41:50 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:41:50 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
 <hif0_x1Xsly3QcpMBMxoD69Yc5IX2G6aZvATHgQBYOw=.43b003ac-4d64-4764-862a-22a8cc675b46@github.com>
 <X0aaL2rnAUGysmk2250BMQLHeG3lyJOZQlPFWZ0Hwcg=.e177be42-6827-4018-8d4e-f27aeb1c7ef3@github.com>
 <jPdpWcGFCqT_sU_dBhfkMIK9t5J-B-a8TJJH9BMcPss=.c282c784-c798-43f7-af8d-1e400380ac68@github.com>
Message-ID: <1dcFgCXvaxngBZS7E6TkCmFEKAi26eDgmlJA82qJxZE=.31ebb4c3-c183-446a-b3c6-0817afb9c951@github.com>

On Fri, 19 May 2023 17:11:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?
>
>> I don't think there is any chance that the factory method returns a Collator that fails to meet the settings in the locale, because setStrength()/setDecompositon() with valid values never fail. So the returned instance will always have the requested strength/decomposition. Does this answer your question?
> 
> It's the last sentence that bothers me. I understand the setters can't fail but the last sentence of the proposed text makes it sound like invalid settings will be just ignored. So I think this sentence needs to be re-examined as I don't think I understand what it is trying to say now.

IIUC that's already the existing behavior for any Unicode extension.

Example,


Locale enIsoLoc = Locale.forLanguageTag("en-u-fw-mon");
WeekFields.of(enIsoLoc).getFirstDayOfWeek(); // MONDAY
Locale badExtension = Locale.forLanguageTag("en-u-fw-zzz");
WeekFields.of(badExtension).getFirstDayOfWeek(); // SUNDAY


If the value for a Unicode extension is invalid, they are simply ignored. In this case 'zzz' is not recognized and thus can not overhaul the first day of the week.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14040#discussion_r1199266617

From jlu at openjdk.org  Fri May 19 18:50:52 2023
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 19 May 2023 18:50:52 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v3]
In-Reply-To: <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <kEse0NBufUJ3oMWcLYJLQXngMlVD-iV0nrQydbnd6Mk=.850974bf-6e8a-4326-931f-61e82b022c07@github.com>
Message-ID: <53fIv3Ebti14_cWhqDoCJb5fvo2KVwKOa4wQM18VBt4=.c8479c8f-3016-4a48-9812-8868683ab5d4@github.com>

On Thu, 18 May 2023 19:44:01 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Added a table for possible BCP47 values and their mappings

LGTM

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1434931594

From naoto at openjdk.org  Fri May 19 21:13:37 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 May 2023 21:13:37 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v4]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

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

  A bit of clarification

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/627b78b3..1cfc09b6

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

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

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

From jlu at openjdk.org  Sat May 20 00:06:57 2023
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 20 May 2023 00:06:57 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat does
 not work as documented
Message-ID: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>

Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).

**Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._

Both the definition and example are incorrect, as the actual result is "12.E345". 

The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.

123 formatted by ##0.#E0 is 123E0
1234 formatted by ##0.#E0 is 1.234E3
12345 formatted by ##0.#E0 is 12.34E3
123456 formatted by ##0.#E0 is 123.5E3
1234567 formatted by ##0.#E0 is 1.235E6
12345678 formatted by ##0.#E0 is 12.35E6
123456789 formatted by ##0.#E0 is 123.5E6 


The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

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

Commit messages:
 - Remove comments if they serve no purpose in the code
 - Add test for new definition
 - Add Specification

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

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

From itakiguchi at openjdk.org  Sat May 20 01:06:59 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Sat, 20 May 2023 01:06:59 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
Message-ID: <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>

On Thu, 18 May 2023 00:50:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>>> Hello @naotoj . I'm not sure we can remove Solaris related charsets. Somebody may use them for text communication between Solaris.
>> 
>> OK, maybe not now.
>> 
>> I think the fix may be simplified by changing access for those `DoubleByte-X.java.template` internals, such as `DecodeHolder` to `public`, instead of introducing those access methods. You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)
>> 
>> Also, please drop `Japanese` from the issue/PR title
>
>>You can import classes in `java.base/sun.nio.cs` with the wild card so that it would work on all platforms (`Big5` either in `java.base` or `jdk.charsets`)
> 
> Scratch that, you've already did it. Then you can remove these: 
> 
> import sun.nio.cs.DoubleByte;
> import sun.nio.cs.HistoricallyNamedCharset;

Hello @naotoj .
I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
I think the values are package-private.
Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
I may be misunderstanding your suggestion, could you tell me more ?

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1555405480

From naoto at openjdk.org  Sat May 20 17:29:50 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 20 May 2023 17:29:50 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
Message-ID: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>

On Sat, 20 May 2023 01:03:52 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 

I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1555957029

From alanb at openjdk.org  Sun May 21 09:40:00 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 May 2023 09:40:00 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v4]
In-Reply-To: <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <LTwn7xI9M_cxurZCiO0K-wWavrfoHJM-Vw7lvH9iXWk=.d8363cd4-e4b8-416e-97b8-906758fe5369@github.com>
Message-ID: <Hn-BV4fggEKc8pgb2NTUF0DDk2Lz99zpFsnH1HBvMLg=.570e3ee2-5bb8-4ece-b5b1-1396d33cb45c@github.com>

On Fri, 19 May 2023 21:13:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   A bit of clarification

I went through the latest javadoc but the last sentence is still confusing. I think the part that is missing is the method doesn't make it clear up front that it gets requested locale and then attempts to set its strength and decomposition if recognized. If this were clear in the first part of the method description then it is okay to say that the returned Collator might not have the expected strength and decomposition.

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

PR Comment: https://git.openjdk.org/jdk/pull/14040#issuecomment-1556131544

From pminborg at openjdk.org  Mon May 22 07:29:53 2023
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 22 May 2023 07:29:53 GMT
Subject: <i18n dev> RFR: 8301552: Use AtomicReferenceArray for caching
 instead of CHM in ZoneOffset [v8]
In-Reply-To: <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
References: <b228oWPoEJf0lfGgIVXwmo1mATeKWRTivuJ2PbgwAmI=.465a4f9b-7a4b-4bbb-9f94-66d1d889a072@github.com>
 <ESUpuSgjM_9ocUr1O_7tjY-Pf2sps17BX69XpDtwoEg=.c93d0dbb-372f-4827-8239-cca058a8bf48@github.com>
Message-ID: <1AX3LgL7iwg56xqgzV3I6wE5QxI4wgkp2VVncRNqRFM=.a9f3a52c-f928-42d1-948f-e4b64a6f2c4b@github.com>

On Thu, 9 Feb 2023 13:46:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> `ZoneOffset` instances are cached by the `ZoneOffset` class itself for values in the range [-18h, 18h] for each second that is on an even quarter of an hour (i.e. at most 2*18*4+1 = 145 values). 
>> 
>> Instead of using a `ConcurrentHashMap` for caching instanced, we could instead use an `AtomicReferenceArray` with direct slot value access for said even seconds. This will improve performance and reduce the number of object even though the backing array will go from an initial 32 in the CHM to an initial/final 145 in the ARA. The CHM will contain much more objects and array slots for typical numbers of entries in the cache and will compute hash/bucket/collision on the hot code path for each cache access.
>
> Per Minborg has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Remove unused setup method
>  - Rename method in test
>  - Add copyright header

Keep alive. We might use another construct.

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

PR Comment: https://git.openjdk.org/jdk/pull/12346#issuecomment-1556683570

From TOSHIONA at jp.ibm.com  Mon May 22 08:58:17 2023
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Mon, 22 May 2023 08:58:17 +0000
Subject: <i18n dev> Query about JDK-8301119 Support for GB18030-2022
Message-ID: <DM6PR15MB392584B797FF90E07C81CBB9EE439@DM6PR15MB3925.namprd15.prod.outlook.com>

Hi,



Can we expect JDK-8301119 ?Support for GB18030-2022? will be ported to OpenJDK-11.0.20 and 17.0.8? It?s already back-ported to 11.0.20-oralce and 17.0.8-oracle, but not OpenJDK update repositories yet. If yes, may I ask timeline as well?



https://bugs.openjdk.org/browse/JDK-8301119



Sorry for bothering you, but this enhancement is received a lot of attention.

Best regards,

Toshio Nakamura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20230522/83bd42a4/attachment-0001.htm>

From itakiguchi at openjdk.org  Mon May 22 10:22:20 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 22 May 2023 10:22:20 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v3]
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> - Big5_Solaris (x-Big5-Solaris)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:

  8308046: Move Solaris related charsets from java.base to jdk.charsets module

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13973/files
  - new: https://git.openjdk.org/jdk/pull/13973/files/6fd12fcd..1c10b107

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

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

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

From itakiguchi at openjdk.org  Mon May 22 14:21:56 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 22 May 2023 14:21:56 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
 <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
Message-ID: <5wQGcZRhWrV_goUQTe5OSychMbzEE8oO5vphXyPSmH8=.4005b3d4-9034-4759-8d1d-e353b913c8a9@github.com>

On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
>> I may be misunderstanding your suggestion, could you tell me more ?
>
>> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 
> 
> I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

Thanks @naotoj .
I changed related fields to `public`.

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1557308396

From naoto at openjdk.org  Mon May 22 17:12:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 17:12:51 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v3]
In-Reply-To: <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <J8vcvL_IR3Q_Gcf-mN_TN8iVC8vvYkK85Rb3e-XwmzU=.d7039bdd-8d20-4681-bd55-54344eb6ac1a@github.com>
Message-ID: <bruRq4_rndaaAGQ20uFof_oRIKzcwENRgORd4JYHbek=.74cf4bd6-b37f-4418-8739-2ca06d63c05d@github.com>

On Mon, 22 May 2023 10:22:20 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

>> According to "JDK 20 Internationalization Guide"
>> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
>> Following Solaris related charsets are in "contained in jdk.charsets module" list.
>> 
>> - PCK (x-PCK)
>> - EUC_JP_Solaris (x-eucJP-Open)
>> - Big5_Solaris (x-Big5-Solaris)
>> 
>> These are not supported by Linux platform, so they should not be in java.base module.
>> 
>> Note:
>> GHA Linux x86 builds were failed.
>> I think it's not related by my modified code.
>> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure
>
> Ichiroh Takiguchi has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8308046: Move Solaris related charsets from java.base to jdk.charsets module

Looks good. I think you may want to change `stdcs-aix` as well.
As to the JBS issue, please change the title to match the PR title, and add `noreg-cleanup` label

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13973#pullrequestreview-1437077458

From naoto at openjdk.org  Mon May 22 17:59:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 17:59:18 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v5]
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

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

  Further clarifying the method description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14040/files
  - new: https://git.openjdk.org/jdk/pull/14040/files/1cfc09b6..83cfe984

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

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

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

From naoto at openjdk.org  Mon May 22 18:04:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 18:04:52 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v5]
In-Reply-To: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
Message-ID: <uLO774ItDztVTaRqnBWqk4v4PEBKrRFK61rKT6Z9KU8=.f4c35968-f5e2-4b03-8eb5-d10890a5797e@github.com>

On Mon, 22 May 2023 17:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarifying the method description

Thanks, Alan. Clarified the method doc based on your suggestion.

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

PR Comment: https://git.openjdk.org/jdk/pull/14040#issuecomment-1557663088

From naoto at openjdk.org  Mon May 22 20:49:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 20:49:52 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>

On Sat, 20 May 2023 00:00:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

(a bit of background to others) We did some archaeological work to dig into the history of this spec, and found that the spec was retrofitted to the implementation. (https://bugs.openjdk.org/browse/JDK-4241670). We suspect that this wording was incorrectly interpreted from the impl at that time.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 56:

> 54:     public void testMantissaDefinition(String pattern) {
> 55:         Locale.setDefault(Locale.ENGLISH);
> 56:         DecimalFormat df = new DecimalFormat(pattern);

Instead of setting the default locale, you could get the explicit format by

new DecimalFormat(pattern, new DecimalFormatSymbols(Locale.US)); // DFS can be a static instance

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 89:

> 87:             // Test the new definition of the Mantissa
> 88:             Integer calculatedDigits = Math
> 89:                     .min(Math.max(zeroes, originalNumDigits), (hashes+zeroes));

Could we make those expected numbers into the `Arguments` so that there is no need to calculate in the test case at runtime? I think that would be more readable.

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

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1437505357
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201067500
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201062733

From jlu at openjdk.org  Mon May 22 23:03:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 May 2023 23:03:10 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v2]
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

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

  Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14066/files
  - new: https://git.openjdk.org/jdk/pull/14066/files/e6cbbeea..faa32ec6

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

  Stats: 35 lines in 1 file changed: 6 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/14066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14066/head:pull/14066

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

From jlu at openjdk.org  Mon May 22 23:07:51 2023
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 22 May 2023 23:07:51 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v2]
In-Reply-To: <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <cvtKeIeeZO6zK9hC043WnymHg7x1OdYDqoxCD_hedIo=.73707abd-2ada-4705-b9a6-c765652d50a7@github.com>
Message-ID: <QSBPanDVt2KM8MyRdLo9EwjLp69p1MtWGvEKAjg9E0g=.f019b00e-cb44-4991-bb1e-2875267269a9@github.com>

On Mon, 22 May 2023 20:41:29 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime
>
> test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 89:
> 
>> 87:             // Test the new definition of the Mantissa
>> 88:             Integer calculatedDigits = Math
>> 89:                     .min(Math.max(zeroes, originalNumDigits), (hashes+zeroes));
> 
> Could we make those expected numbers into the `Arguments` so that there is no need to calculate in the test case at runtime? I think that would be more readable.

Thanks for the review, addressed both suggestions in the most recent commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201272651

From naoto at openjdk.org  Mon May 22 23:34:51 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 May 2023 23:34:51 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v2]
In-Reply-To: <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
Message-ID: <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>

On Mon, 22 May 2023 23:03:10 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
>> 
>> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
>> 
>> Both the definition and example are incorrect, as the actual result is "12.E345". 
>> 
>> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
>> 
>> 123 formatted by ##0.#E0 is 123E0
>> 1234 formatted by ##0.#E0 is 1.234E3
>> 12345 formatted by ##0.#E0 is 12.34E3
>> 123456 formatted by ##0.#E0 is 123.5E3
>> 1234567 formatted by ##0.#E0 is 1.235E6
>> 12345678 formatted by ##0.#E0 is 12.35E6
>> 123456789 formatted by ##0.#E0 is 123.5E6 
>> 
>> 
>> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime

Thanks, Justin. Left some super-nits.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 52:

> 50:             1.1234, 1.1111, 1.412, 222.333, -771.2222
> 51:             };
> 52:     private static final DecimalFormatSymbols dfs = new DecimalFormatSymbols(Locale.US);

The `static final` field is better uppercased.

test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 64:

> 62:         for (double number : numbers) {
> 63:             // Count the significant digits in the pre-formatted number
> 64:             int originalNumDigits = String.valueOf(number)

It's OK as it stands, but you could write:

str.chars().filter(Character::isDigit).count()

which might be more readable

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

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1437867369
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201295121
PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201295601

From TOSHIONA at jp.ibm.com  Tue May 23 00:01:59 2023
From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura)
Date: Tue, 23 May 2023 00:01:59 +0000
Subject: <i18n dev> Query about JDK-8301119 Support for GB18030-2022
In-Reply-To: <3ec36d2267146221f3cfdf64ba9a253121d5defe.camel@redhat.com>
References: <DM6PR15MB392584B797FF90E07C81CBB9EE439@DM6PR15MB3925.namprd15.prod.outlook.com>
 <3ec36d2267146221f3cfdf64ba9a253121d5defe.camel@redhat.com>
Message-ID: <DM6PR15MB3925325A135BD118321AD16BEE439@DM6PR15MB3925.namprd15.prod.outlook.com>

Thank you, Severin. Relieved.

Best regards,

Toshio Nakamura

???: Severin Gehwolf <sgehwolf at redhat.com>
??: ???, 2023?5?23? 1:34
??: Toshio 5 Nakamura <TOSHIONA at jp.ibm.com>, jdk-updates-dev at openjdk.org <jdk-updates-dev at openjdk.org>
CC: i18n-dev at openjdk.org <i18n-dev at openjdk.org>
??: [EXTERNAL] Re: Query about JDK-8301119 Support for GB18030-2022
Hi,

On Mon, 2023-05-22 at 08:58 +0000, Toshio 5 Nakamura wrote:
> Can we expect JDK-8301119 ?Support for GB18030-2022? will be ported
> to OpenJDK-11.0.20 and 17.0.8?

After consultation with other maintainers we think it should go in yes.

> It?s already back-ported to 11.0.20-oralce and 17.0.8-oracle, but not
> OpenJDK update repositories yet. If yes, may I ask timeline as well?

The plan would be to get it into 11.0.20 and 17.0.8 respectively.

Hope this helps.

Thanks,
Severin

> https://bugs.openjdk.org/browse/JDK-8301119
>
> Sorry for bothering you, but this enhancement is received a lot of
> attention.
>
> Best regards,
>
> Toshio Nakamura
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/i18n-dev/attachments/20230523/bc8db0b5/attachment-0001.htm>

From itakiguchi at openjdk.org  Tue May 23 00:12:50 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 23 May 2023 00:12:50 GMT
Subject: <i18n dev> RFR: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module [v2]
In-Reply-To: <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
 <YBIz1uoHLulnyO1_r7pnY-h_vGyoeRowBG4TOb-PPvs=.4e895c36-49a3-4675-a417-07d67599e547@github.com>
 <dlwEnN0WBW6sxfKSkv2cFNzaPKV5cMCX8XMvk13s-qU=.13134317-37df-4f67-aeee-89b83b6b7f79@github.com>
 <4yFGg-CgLRvNAEB7tpVH9Bi13fdlyAAdVniQnYoZcX4=.32f55011-db19-4c15-adc1-7cfc4cd564a6@github.com>
 <URWJaXXaEzUAWnM0t0t_VFs-eSpBxYhrWKpHL1Dd1b4=.456a44fc-ce38-46ee-ba17-48fd37df65f5@github.com>
 <Of7--k3lQYJdoaAusVAhJB6XzmAoxuYD5FMm7P448P8=.2e742cdb-d7f5-4f38-87de-ff5725fec96b@github.com>
 <txZ17bmXVyokeDGUg0Nv7coyls0P9nd4s95qyxFY3rA=.4fe47161-b45c-436f-9074-1aa6df738958@github.com>
Message-ID: <JenWk-CIZLt9lCH1cxKtXbNisFd1BQDtN2L6BNVtErY=.889d5a9a-5dc9-453f-a329-a54c95d88019@github.com>

On Sat, 20 May 2023 17:26:53 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Hello @naotoj .
>> I'd like to confirm about DoubleByte-X.java.template and EUC_JP.java.template.
>> I think the values are package-private.
>> Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package...
>> I may be misunderstanding your suggestion, could you tell me more ?
>
>> I think the values are package-private. Even if class is changed to `public`, the classes in`sun.nio.cs.ext` package could not access to these values in `sun.nio.cs` package... 
> 
> I meant making those package-private fields public. I believe it's OK because java.base/sun.nio.cs package is only exported to jdk.charsets module.

Hello @naotoj .
I appreciate your attention about JBS side.
I changed title and description, add noreg-cleanup label.

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

PR Comment: https://git.openjdk.org/jdk/pull/13973#issuecomment-1558228901

From itakiguchi at openjdk.org  Tue May 23 00:45:10 2023
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Tue, 23 May 2023 00:45:10 GMT
Subject: <i18n dev> Integrated: 8308046: Move Solaris related charsets from
 java.base to jdk.charsets module
In-Reply-To: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
References: <Nf22UAo6580-a48GWtCRFk0IZUL6dJ9ogfpk6R7c5tQ=.70911dc8-5cb4-4b9e-adde-39cd42b99771@github.com>
Message-ID: <x6CNq7R3ck3jDBMCDX1v6f5f3YZSHaHARE77ebQvmgw=.a11a0f65-bf34-4d15-8f54-f4219d26c0a4@github.com>

On Mon, 15 May 2023 00:28:41 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> According to "JDK 20 Internationalization Guide"
> https://docs.oracle.com/en/java/javase/20/intl/supported-encodings.html
> Following Solaris related charsets are in "contained in jdk.charsets module" list.
> 
> - PCK (x-PCK)
> - EUC_JP_Solaris (x-eucJP-Open)
> - Big5_Solaris (x-Big5-Solaris)
> 
> These are not supported by Linux platform, so they should not be in java.base module.
> 
> Note:
> GHA Linux x86 builds were failed.
> I think it's not related by my modified code.
> I opened [JDK-8308051](https://bugs.openjdk.org/browse/JDK-8308051) GHA: Linux x86 builds failure

This pull request has now been integrated.

Changeset: 5d8ba938
Author:    Ichiroh Takiguchi <itakiguchi at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5d8ba938bef162b74816147eb1002a0620a419ba
Stats:     21 lines in 4 files changed: 0 ins; 6 del; 15 mod

8308046: Move Solaris related charsets from java.base to jdk.charsets module

Reviewed-by: naoto

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

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

From jlu at openjdk.org  Tue May 23 05:31:37 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 05:31:37 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v3]
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

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

  Review: replace counting with isDigit, use all caps static final vars

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14066/files
  - new: https://git.openjdk.org/jdk/pull/14066/files/faa32ec6..dd516b63

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

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

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

From jlu at openjdk.org  Tue May 23 05:31:40 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 05:31:40 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v2]
In-Reply-To: <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <G6ys5jd53ugGSFPMdFoC-Qho1r8pxEwoeMVwUhASpRI=.8c9ac6db-878a-45a2-b4f8-a3372e69e9d0@github.com>
 <w8IYWaF82fbUMBOM6Ucr7JrZGTiCrR3nEF-h96SZPy0=.56f7313b-bdbc-4e7e-ae50-e118a6ba4f99@github.com>
Message-ID: <ERWp6zdBqMjamrbKH70udCEUGKI2bg8DfyFSuifc3-o=.dffb9d6f-b15d-4939-b326-699e0ef4bdb7@github.com>

On Mon, 22 May 2023 23:31:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review: Use Static dfs, error message, and exponent digit. Hard code min and max digits instead of calculating at runtime
>
> test/jdk/java/text/Format/DecimalFormat/MantissaDigits.java line 64:
> 
>> 62:         for (double number : numbers) {
>> 63:             // Count the significant digits in the pre-formatted number
>> 64:             int originalNumDigits = String.valueOf(number)
> 
> It's OK as it stands, but you could write:
> 
> str.chars().filter(Character::isDigit).count()
> 
> which might be more readable

Like this much better, incorporated!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14066#discussion_r1201538926

From naoto at openjdk.org  Tue May 23 16:22:52 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 May 2023 16:22:52 GMT
Subject: <i18n dev> RFR: 8159023: Engineering notation of DecimalFormat
 does not work as documented [v3]
In-Reply-To: <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
 <CAoRwOaYvLyvcwX__-iBVtN2BX6hw_smDC53OmKc5Ks=.668e2637-7a68-4aa7-a4c4-ca1a457999d1@github.com>
Message-ID: <nk16hshcam19YEE4T_DpEXCDlWXXdA6ieTxvngeSkYY=.3c488e65-19a3-40a6-906c-9239b0f9587f@github.com>

On Tue, 23 May 2023 05:31:37 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
>> 
>> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
>> 
>> Both the definition and example are incorrect, as the actual result is "12.E345". 
>> 
>> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
>> 
>> 123 formatted by ##0.#E0 is 123E0
>> 1234 formatted by ##0.#E0 is 1.234E3
>> 12345 formatted by ##0.#E0 is 12.34E3
>> 123456 formatted by ##0.#E0 is 123.5E3
>> 1234567 formatted by ##0.#E0 is 1.235E6
>> 12345678 formatted by ##0.#E0 is 12.35E6
>> 123456789 formatted by ##0.#E0 is 123.5E6 
>> 
>> 
>> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review: replace counting with isDigit, use all caps static final vars

Looks good

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14066#pullrequestreview-1440125960

From jlu at openjdk.org  Tue May 23 23:24:01 2023
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 23 May 2023 23:24:01 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
Message-ID: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>

Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.

For example,


DecimalFormat df = new DecimalFormat();
df.setRoundingMode(RoundingMode.UP);
double small = 0.0001;
double big = 1.0001;
df.applyPattern("0.00");
df.format(small); // returns 0.00, which violates UP
df.format(big); // returns 1.01, which does not violate UP


In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."

This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).

The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.

The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

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

Commit messages:
 - Clarify test comment
 - Missing period
 - Add Impl
 - Use RoundingMode.values() instead of hard coding a static array
 - Add test

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

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

From darcy at openjdk.org  Tue May 23 23:32:54 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 May 2023 23:32:54 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

Note there are some hazards here with respect to the numerical values of double and the decimal string used to represent the double; in exact terms:


jshell> new BigDecimal(1.0001)
$2 ==> 1.0000999999999999889865875957184471189975738525390625

jshell> new BigDecimal(0.0001)
$3 ==> 0.000100000000000000004792173602385929598312941379845142364501953125

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1560254680

From jlu at openjdk.org  Wed May 24 00:38:10 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 00:38:10 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <m3Jb8l0DUHcjimtBoafHR2fng3_JHz6RpviDtKcl47k=.a8a2c222-aee8-4a95-a040-8ce90fb98f03@github.com>
Message-ID: <j2Wi1WfGlqgNbZwviFtIkHFoNLM5cn1ufZD75R3c3aw=.eda3df62-d347-4078-b1f6-d16a2a19507b@github.com>

On Tue, 23 May 2023 23:30:11 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Note there are some hazards here with respect to the numerical values of double and the decimal string used to represent the double; in exact terms:
> 
> ```
> jshell> new BigDecimal(1.0001)
> $2 ==> 1.0000999999999999889865875957184471189975738525390625
> 
> jshell> new BigDecimal(0.0001)
> $3 ==> 0.000100000000000000004792173602385929598312941379845142364501953125
> ```

Thanks for bringing that to my attention Joe. I will re-evaluate how I test the changes then.

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1560295694

From alanb at openjdk.org  Wed May 24 06:45:56 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 May 2023 06:45:56 GMT
Subject: <i18n dev> RFR: 8308108: Support Unicode extension for
 collation settings [v5]
In-Reply-To: <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
 <EodPecDgFYPgwrX60SZVYwbAk5uflaH4yZmEXVpBCQ4=.109c0fa1-06a1-405b-88fb-d889b3258309@github.com>
Message-ID: <hVkdpipH9tNKxbPjz7kmJNAUI5c9EeXll9mTHHGlSUg=.70f33703-342b-4a0f-8ecb-aa06cd3c1fd0@github.com>

On Mon, 22 May 2023 17:59:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Further clarifying the method description

Thanks for persisting with this to get the wording clear, the latest version looks good.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14040#pullrequestreview-1441043457

From naoto at openjdk.org  Wed May 24 17:41:57 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 17:41:57 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>

On Tue, 23 May 2023 23:16:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561676671

From jlu at openjdk.org  Wed May 24 18:39:55 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 18:39:55 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
Message-ID: <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>

On Wed, 24 May 2023 17:36:50 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.

The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider

`1.0000009` formatted to `0.0` with `RoundingMode.UP`

DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`

Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561752907

From darcy at openjdk.org  Wed May 24 18:51:03 2023
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 24 May 2023 18:51:03 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
 <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
Message-ID: <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>

On Wed, 24 May 2023 18:36:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> > I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
> 
> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
> 
> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
> 
> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
> 
> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.

A quick comment without diving into the particular issues here, for each finite floating-point value, there is a range of the real number line that will round to that floating-point value. Under the default rounding policy, some of those real numbers will be less than the floating-point value and other of those real numbers will be greater than the floating-point value.

So there are decimal strings corresponding to those numbers greater than and less than the floating-point value, all of which will get rounded to the same double value on string conversion.

If the operation is phrased in terms of *the floating-point value* and not *the real number value of what happened to be the input string*, then the actual real value of the floating-point number should be the reference point for rounding up/down on double -> String conversion.

This may give "surprising" results, but is numerically better. Without finding the bug ids, some previous changes were made to decimal format when rounding to nearest along those lines. HTH

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1561765426

From xuelei at openjdk.org  Wed May 24 19:20:09 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 24 May 2023 19:20:09 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base [v2]
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:

  exclude update for libnet

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/13963/files
  - new: https://git.openjdk.org/jdk/pull/13963/files/363555b6..2247a56d

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

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

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

From xuelei at openjdk.org  Wed May 24 19:20:10 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 24 May 2023 19:20:10 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base [v2]
In-Reply-To: <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <5gmranDThlQlFLXa2i6t9E-z5tQrClncgNOErGSrfT8=.679ad5b9-ac56-418d-896f-1052fc6c4020@github.com>
Message-ID: <z3H0q2y-ajS2GdTssGp5LkgHZl3GKVjHnEvnDZj6PmY=.348a0219-cdf7-498c-b6de-e7321a1f642a@github.com>

On Mon, 15 May 2023 17:21:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The libnet changes look reasonable to me.

@dfuch Thank you for the review.  This patch may be still too big as a few components were involved.  To easy to review process, I opened a new PR for libnet update, and will reverse the libnet changes in this PR.  Please review the [new PR](https://github.com/openjdk/jdk/pull/14132).

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

PR Comment: https://git.openjdk.org/jdk/pull/13963#issuecomment-1561796288

From jlu at openjdk.org  Wed May 24 20:37:33 2023
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 24 May 2023 20:37:33 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case [v2]
In-Reply-To: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
Message-ID: <gEcsserbD9lHyTCJefQyCy2P9Z1Xhn2A7Nm68pu2BvE=.c09ef670-58ef-48ab-ba38-2f4982a9bad8@github.com>

> Please review this PR, which addresses a case where Decimal Format would violate certain RoundingMode contracts given the right pattern and double.
> 
> For example,
> 
> 
> DecimalFormat df = new DecimalFormat();
> df.setRoundingMode(RoundingMode.UP);
> double small = 0.0001;
> double big = 1.0001;
> df.applyPattern("0.00");
> df.format(small); // returns 0.00, which violates UP
> df.format(big); // returns 1.01, which does not violate UP
> 
> 
> In this example `0.0001` becomes `0.00`, a decrease in magnitude. This violates the RoundingMode.UP contract as RoundingMode.UP states "Note that this rounding mode never decreases the magnitude of the calculated value."
> 
> This edge case is a result of when values smaller than the absolute value of `.1` have more leading zeros between the decimal and the first non-zero digit (_0.0001 -> **3**_) than maximum fractional digits in the pattern (_0.00 -> **2**_).
> 
> The change to Decimal Format ensures that during this case, the rounding mode is considered before truncation, which dictates if the formatted number should insert a 1 in the least significant digit location.
> 
> The test validates the change by using data from larger counterparts. For example, If we are testing `0.0009`, we can format `1.0009` with the same pattern and mode that we use on `0.0009`, then compare the fractional portions to each other and ensure they are equal.

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

  Review: RAdjust test to not depend on a larger number counterpart

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14110/files
  - new: https://git.openjdk.org/jdk/pull/14110/files/5fbc601d..a8e1a81b

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

  Stats: 74 lines in 1 file changed: 40 ins; 1 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/14110.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14110/head:pull/14110

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

From naoto at openjdk.org  Wed May 24 22:48:53 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 22:48:53 GMT
Subject: <i18n dev> RFR: 8174722: Wrong behavior of DecimalFormat with
 RoundingMode.UP in special case
In-Reply-To: <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>
References: <I2n6nYjuUUUQZAejrJAMDJUsTrUzL95IkN8Ra9FavAI=.2df1a5c8-9250-4186-81b1-ffdfbb70aa77@github.com>
 <Yx9RVsgO0XR7-qtJoJ6jJ-uI6n6Np2zU4T1_-PG9bGI=.0a2a9cbe-95c1-43ca-8f5e-1b70f370bea0@github.com>
 <tc2WNaKDU6pGMiSlWQlh_Hfv3kY7xlIEzC_1m4qsJXI=.93a9520a-5161-4b9b-b60e-f05e2fc96dbc@github.com>
 <Ih7pe5C2S0z0sfzlx6g2L6XHb-JkTRa643CkUG1zRuM=.83acdc49-7b98-44dc-b50c-78dc820600f8@github.com>
Message-ID: <Sdnhed6W7Dnu8SRsTFGl76Dr6-F5Mis40kZp5l9johA=.04c3e743-8d85-4e12-9d18-087b54321d2c@github.com>

On Wed, 24 May 2023 18:47:45 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>>> I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
>> 
>> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
>> 
>> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
>> 
>> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
>> 
>> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.
>
>> > I just wonder if it is ok to reverse the rounding/truncation only in this special case. If the truncation always comes first, then 0.00 would be correct (then 1.01 may be something wrong). Looks to me that the original comment suggests it tries to truncate those cases. I suggest filing a CSR for further behavioral consideration.
>> 
>> The normal behavior of DecimalFormat (DigitList) "rounds" before truncation. For example, consider
>> 
>> `1.0000009` formatted to `0.0` with `RoundingMode.UP`
>> 
>> DigitList will search past the maximum digits allowed to decide if the formatted value should be rounded. '9' will be found, and as such the value will be "rounded", by incrementing the value by 1 at the max digit location -> `1.1000009`, then DigitList will truncate -> `1.1`
>> 
>> Thus I believe that this change is aligning this special case to be consistent with the existing behavior of rounding before truncation. I will follow-up in the CSR.
> 
> A quick comment without diving into the particular issues here, for each finite floating-point value, there is a range of the real number line that will round to that floating-point value. Under the default rounding policy, some of those real numbers will be less than the floating-point value and other of those real numbers will be greater than the floating-point value.
> 
> So there are decimal strings corresponding to those numbers greater than and less than the floating-point value, all of which will get rounded to the same double value on string conversion.
> 
> If the operation is phrased in terms of *the floating-point value* and not *the real number value of what happened to be the input string*, then the actual real value of the floating-point number should be the reference point for rounding up/down on double -> String conversion.
> 
> This may give "surprising" results, but is numerically better. Without finding the bug ids, some previous changes were made to decimal format when rounding to nearest along those lines. HTH

Hi @jddarcy , are you referring to the cases like this:https://bugs.openjdk.org/browse/JDK-8062756 ? I understand the binary representation of real number could be below the real number, then the rounding may look strange, but in this particular case, I believe it won't affect the result, as the fix is to the following specific condition (excerpt of the comment there):

                // Handle an underflow to zero when we round something like
                // 0.0009 to 2 fractional digits.

So even if the number `0.0001` is represented by `0.00009999999something` it should round up to `0.01`.

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

PR Comment: https://git.openjdk.org/jdk/pull/14110#issuecomment-1562021619

From prappo at openjdk.org  Wed May 24 23:40:08 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Wed, 24 May 2023 23:40:08 GMT
Subject: <i18n dev> RFR: 8308735: Typos in parameter names
Message-ID: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>

Please review this simple fix.

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

Commit messages:
 - Fix typos

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

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

From naoto at openjdk.org  Wed May 24 23:48:54 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 24 May 2023 23:48:54 GMT
Subject: <i18n dev> RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <GCXNO-3PD2aiPHTt0ED85Ar-t5AzjuY6K-iH55zFjkY=.a90ad455-9f10-422b-9388-7512de40e1fe@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442893076

From iris at openjdk.org  Wed May 24 23:51:58 2023
From: iris at openjdk.org (Iris Clark)
Date: Wed, 24 May 2023 23:51:58 GMT
Subject: <i18n dev> RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <uuBk1h6H98pDt4Yg5krFLuaoh_Rw_SmKMkYju0kWD4Y=.4b6f346a-e457-47b5-b6e9-00cbe226244a@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

Looks good.  (I'm not sure I'd characterize this as a "typo", more like a failure to adjust "cut and paste" replication.  Regardless you're fixing an error.)

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442894523

From bpb at openjdk.org  Thu May 25 00:44:04 2023
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 May 2023 00:44:04 GMT
Subject: <i18n dev> RFR: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <ocwU73Dwx6Mp5t1yDJTzlB5kZu1fXFMihCZfxNOX9VY=.bca2c00f-df12-4548-93ba-3c6e03f078db@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

+1

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14136#pullrequestreview-1442923610

From prappo at openjdk.org  Thu May 25 10:26:04 2023
From: prappo at openjdk.org (Pavel Rappo)
Date: Thu, 25 May 2023 10:26:04 GMT
Subject: <i18n dev> Integrated: 8308735: Typos in parameter names
In-Reply-To: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
References: <shUo5uwfGa3TPYdSrxiJx_IYcr1rUNanbtrbvG3QzLQ=.e178ac8a-9268-40ae-babe-841b8906e472@github.com>
Message-ID: <odvywRgvz9xbSlXVY8F3cqOYsi0hqRsfDqnK7fhGNJk=.f72ecc9b-3cd8-43b3-bef2-9d77fcefac95@github.com>

On Wed, 24 May 2023 23:32:18 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> Please review this simple fix.

This pull request has now been integrated.

Changeset: 38367d3c
Author:    Pavel Rappo <prappo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/38367d3c3ad9292b7c581917c89e9f07fac3dd31
Stats:     9 lines in 3 files changed: 0 ins; 0 del; 9 mod

8308735: Typos in parameter names

Reviewed-by: naoto, iris, bpb

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

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

From stsypanov at openjdk.org  Thu May 25 11:30:58 2023
From: stsypanov at openjdk.org (Sergey Tsypanov)
Date: Thu, 25 May 2023 11:30:58 GMT
Subject: <i18n dev> RFR: 8301492: Modernize equals() method of
 ResourceBundle.CacheKey and Bundles.CacheKey [v3]
In-Reply-To: <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
References: <5xdnQZ8wLrkyB6U2miAOizqpvHGTFzy7OF_a24CUabc=.db6a65d7-9a29-44dc-94aa-692fbbfc82c7@github.com>
 <fvmMrOWZG6N-QjWdqH5lfMzKqEdvDPmkh6ccV8anLvQ=.b7591ed2-0275-4ee8-a013-dbd65ec68cfd@github.com>
Message-ID: <WiGTYwVTe9M7657nrA2pcDLgcV5TTLZ2eGlfZdDIw7k=.188e48c6-bd57-4963-9b21-b6be72ffa175@github.com>

On Wed, 1 Feb 2023 10:36:12 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> `ResourceBundle.CacheKey.equals()` and `Bundles.CacheKey.equals()` are quire outdated. This simple clean-up modernizes them.
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore logic

Not now

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

PR Comment: https://git.openjdk.org/jdk/pull/12328#issuecomment-1562739064

From naoto at openjdk.org  Thu May 25 17:23:06 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 17:23:06 GMT
Subject: <i18n dev> Integrated: 8308108: Support Unicode extension for
 collation settings
In-Reply-To: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
References: <yNyDsmkidnSPlzcqSoLJo67hjqseU1SKN9Tgt-VkGdE=.48c42d57-1990-492c-b031-12025368bebd@github.com>
Message-ID: <Zzi5zCfH9XXtAHLjlmoejrUW5N15QffKHKomRWzAZkI=.7ebbacaf-f62b-4d82-8245-233925342b6e@github.com>

On Wed, 17 May 2023 19:40:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This change intends to interpret the BCP47 U extension wrt collation settings in the given `Locale`, then applies them to the created instances in the 1-arg factory method in `Collator`. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 27ba8bd4
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/27ba8bd4edf0c6f6d747579534262c223047a645
Stats:     143 lines in 2 files changed: 142 ins; 0 del; 1 mod

8308108: Support Unicode extension for collation settings

Reviewed-by: iris, rriggs, jlu, alanb

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

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

From naoto at openjdk.org  Thu May 25 21:39:40 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 21:39:40 GMT
Subject: <i18n dev> RFR: 8308316: Default decomposition mode in Collator
 [v2]
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <8XsjlRBeuKqluDnEEMHmVYCK7-tEFb2wHGrPlkFZ5do=.531520c9-730f-4370-9219-838a1e759a1a@github.com>

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

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:

 - Default values
 - Merge branch 'master' into JDK-8308316-default-decomposition
 - Merge branch 'master' into JDK-8308316-default-decomposition
 - 8308369: Default decomposition mode in Collator

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14049/files
  - new: https://git.openjdk.org/jdk/pull/14049/files/90eb68f7..304c5a6b

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

  Stats: 50356 lines in 1201 files changed: 34222 ins; 9623 del; 6511 mod
  Patch: https://git.openjdk.org/jdk/pull/14049.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14049/head:pull/14049

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

From jlu at openjdk.org  Thu May 25 21:58:08 2023
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 25 May 2023 21:58:08 GMT
Subject: <i18n dev> Integrated: 8159023: Engineering notation of
 DecimalFormat does not work as documented
In-Reply-To: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
References: <rPsJeZSzPOmRoSsE7cdTs-iWWzDKae8rgS4mXUBjpl0=.15664cc8-8479-4f81-b230-fc51c1c21f21@github.com>
Message-ID: <V1E6zUYU2ZTWuPe1zcozoIVGYSrfwtICN44YgfVFlUg=.08c33ab1-318f-495b-ad9c-9314a75cd91d@github.com>

On Sat, 20 May 2023 00:00:42 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which updates the Scientific Notation section of Decimal Format. It aims to resolve [JDK-8159023](https://bugs.openjdk.org/browse/JDK-8159023) as well as [JDK-6282188](https://bugs.openjdk.org/browse/JDK-6282188).
> 
> **Scientific Notation** in Decimal Format contains the definition for a scientific notation formatted number's mantissa as such: _The number of significant digits in the mantissa is the sum of the minimum integer and maximum fraction digits, and is unaffected by the maximum integer digits. For example, 12345 formatted with "##0.##E0" is "12.3E3"._
> 
> Both the definition and example are incorrect, as the actual result is "12.E345". 
> 
> The following example data show that scientific notation formatted numbers do not adhere to that definition. As, according to the definition, the following numbers should have 3 significant digits, but in reality, they have up to 5.
> 
> 123 formatted by ##0.#E0 is 123E0
> 1234 formatted by ##0.#E0 is 1.234E3
> 12345 formatted by ##0.#E0 is 12.34E3
> 123456 formatted by ##0.#E0 is 123.5E3
> 1234567 formatted by ##0.#E0 is 1.235E6
> 12345678 formatted by ##0.#E0 is 12.35E6
> 123456789 formatted by ##0.#E0 is 123.5E6 
> 
> 
> The actual definition of the mantissa, as well as examples and further context are included in this change. In addition, a test has been added that tests various patterns to numbers and ensures the format follows the new definition's mathematical expression.

This pull request has now been integrated.

Changeset: 46c4da7f
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/46c4da7fddb8103934f2a90b4456a5ce6ed3467c
Stats:     147 lines in 2 files changed: 140 ins; 0 del; 7 mod

8159023: Engineering notation of DecimalFormat does not work as documented

Reviewed-by: naoto

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

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

From naoto at openjdk.org  Thu May 25 22:19:18 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 May 2023 22:19:18 GMT
Subject: <i18n dev> RFR: 8308316: Default decomposition mode in Collator
 [v3]
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

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

  use present tense

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14049/files
  - new: https://git.openjdk.org/jdk/pull/14049/files/304c5a6b..717f4c92

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

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

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

From duke at openjdk.org  Tue May 30 08:39:11 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 30 May 2023 08:39:11 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays fails
 intermittently
Message-ID: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>

command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
error info: 

Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
... 24 more

Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).

Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:

	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)

in LocaleObjectCache.java:64

	 62             if (key == null || newVal == null) {                                
	 63                 // subclass must return non-null key/value object               
	 64                 return null; // run here
	 65             }

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

Commit messages:
 - 8289220: [Shenandoah] TestAllocObjectArrays fails intermittently

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

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

From alanb at openjdk.org  Tue May 30 08:51:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 08:51:55 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

I think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568027455

From shade at openjdk.org  Tue May 30 09:13:56 2023
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 30 May 2023 09:13:56 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <Khf56sSw3JSe8EOUBKrt9XozqF-hmHvegBsryx1zwi0=.7f8ee15a-73e6-42dc-9478-c7d9adc3c539@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

This also likely has little to do with Shenandoah itself, and it "only" reproduces because Shenandoah has the aggressively cleaning mode. So the synopsis should reflect the exact issue in `Locale`, once found.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568070554

From duke at openjdk.org  Tue May 30 09:35:53 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Tue, 30 May 2023 09:35:53 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
Message-ID: <KD9NeUlu0sYga1s4cKWCLyiM7Qg7k7I3j_bgwhyqyiw=.db670ab3-6db7-4d82-acd4-e4d1c3daeb35@github.com>

On Tue, 30 May 2023 08:49:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> I don't think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

as @AlanBateman said, this patch may not be the radical solution.  But once executed here, the ` return null` should be handled.

 62             if (key == null || newVal == null) {                                
 63                 // subclass must return non-null key/value object               
 64                 return null; // then what we can do?
 65             }

-XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot can trigger frequent GC without caring if the memory is really low. So the problem of soft references can be exposed. I suspect that this code is not executed under normal circumstances, so there is no exposure problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568109270

From alanb at openjdk.org  Tue May 30 10:27:57 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 May 2023 10:27:57 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <za3HlzGMKW5o7NUboUPHhEsyMeNaefos55IFuaeTueA=.a3fe492f-82b8-4ada-8cb6-07835fed56cb@github.com>
Message-ID: <fnimS7A_RdcattPNtIS1y0I5SZ5ERVlAjmPM-6kkqUE=.7c2a3636-19b5-4047-a079-373c74b59093@github.com>

On Tue, 30 May 2023 08:49:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
>> error info: 
>> 
>> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
>> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
>> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
>> ... 24 more
>> 
>> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
>> 
>> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
>> 
>> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
>> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
>> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
>> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
>> 
>> in LocaleObjectCache.java:64
>> 
>> 	 62             if (key == null || newVal == null) {                                
>> 	 63                 // subclass must return non-null key/value object               
>> 	 64                 return null; // run here
>> 	 65             }
>
> I don't think Locale.forLanguageTag is specified to return null so you might have to do a bit more analysis to see what this issue is about. There are soft refs usages in the locale and it could be that there is some that doesn't handle cases where the ref is cleared.

> as @AlanBateman said, this patch may not be the radical solution. But once executed here, the ` return null` should be handled.

No, we can't return null if the API isn't already specified to return null. I think you'll need to dig into soft ref usages in this code as I assume there is clearing happening at a time that the code doesn't expect. It's unlikely to be specific to ShenandoahGC.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1568186424

From xuelei at openjdk.org  Tue May 30 17:32:02 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Tue, 30 May 2023 17:32:02 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base [v2]
In-Reply-To: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
Message-ID: <iil-LcffCXH_5m0NkgDeOYUH5IrULucc34oHX96Jyq4=.d3e682db-6065-4079-ba6b-7e0b123fa8fc@github.com>

On Wed, 24 May 2023 19:20:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude update for libnet

ping ...

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

PR Comment: https://git.openjdk.org/jdk/pull/13963#issuecomment-1568809395

From naoto at openjdk.org  Tue May 30 18:03:05 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 30 May 2023 18:03:05 GMT
Subject: <i18n dev> RFR: 8308022: update for deprecated sprintf for
 java.base [v2]
In-Reply-To: <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
 <KoGd_keDUhRHvaB5YVqBVtzbuXxlaTdWdbrc1dylFK8=.6c7411d0-6c71-431f-8968-03e823774ca6@github.com>
Message-ID: <QQsFnUhNexYPsZhaq6z5PobdU2odJU_giEMq_Myh4ko=.3ba677c9-bdae-4a91-959c-615d778ebb65@github.com>

On Wed, 24 May 2023 19:20:09 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> Hi,
>> 
>> May I have this update reviewed?
>> 
>> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
>> 
>> Thanks,
>> Xuelei
>
> Xue-Lei Andrew Fan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   exclude update for libnet

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/13963#pullrequestreview-1451523287

From rriggs at openjdk.org  Tue May 30 18:32:57 2023
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 30 May 2023 18:32:57 GMT
Subject: <i18n dev> RFR: 8308316: Default decomposition mode in Collator
 [v3]
In-Reply-To: <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
 <uLvdxZ39JHYsB9F1t_qaLnWA7ckhC3wDeZ3y2KYPjUo=.824c2878-9566-49c1-876c-ace94217e03d@github.com>
Message-ID: <Ic3G6GnvLGbK6ywuhDIIMOTGFkB1_eZSFm9pRQRcfoY=.42c7a653-a2a6-4d08-b4e2-52e67332c1c2@github.com>

On Thu, 25 May 2023 22:19:18 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use present tense

Looks good.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14049#pullrequestreview-1451577005

From duke at openjdk.org  Wed May 31 10:04:59 2023
From: duke at openjdk.org (SUN Guoyun)
Date: Wed, 31 May 2023 10:04:59 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
Message-ID: <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>

On Tue, 30 May 2023 08:31:08 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> command: make test CONF=fastdebug JTREG="VM_OPTIONS=-Xcomp" TEST=gc/TestAllocHumongousFragment.java
> error info: 
> 
> Caused by: java.lang.NullPointerException: Cannot invoke "sun.util.locale.BaseLocale.getVariant()" because "base" is null
> at java.base/java.util.Locale.forLanguageTag(Locale.java:1802)
> at java.base/sun.util.cldr.CLDRBaseLocaleDataMetaInfo.<clinit>(CLDRBaseLocaleDataMetaInfo.java:41)
> ... 24 more
> 
> Note that the test runs with -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot and SoftReferences are involved (LocaleObjectCache uses SoftReferences, used by printf method called in getRandomInstance(Utils.java:511)).
> 
> Maybe we have to deal with the case where the getBaseLocale() return value is null. the call stack is:
> 
> 	at java.base/sun.util.locale.LocaleObjectCache.get(LocaleObjectCache.java:64)
> 	at java.base/sun.util.locale.BaseLocale.getInstance(BaseLocale.java:169)
> 	at java.base/sun.util.locale.InternalLocaleBuilder.getBaseLocale(InternalLocaleBuilder.java:524)
> 	at java.base/java.util.Locale.forLanguageTag(Locale.java:1874)
> 
> in LocaleObjectCache.java:64
> 
> 	 62             if (key == null || newVal == null) {                                
> 	 63                 // subclass must return non-null key/value object               
> 	 64                 return null; // run here
> 	 65             }

Jtreg tier1 can trigger the same error with vmoptions:"-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot
I found the GC occurs between when the soft reference is assigned and when it is used.
<pre><code class="shell">
         private BaseLocale getBaseLocale() {
-            return (holder == null) ? holderRef.get() : holder;
+//            return (holder == null) ? holderRef.get() : holder;
+            if (holder == null) {
+              System.out.println("getBaseLocale this=" + this + "  SoftReference=" + holderRef.get()); // null
+              return holderRef.get();
+            } else {
+              System.out.println("getBaseLocale return holder");
+              return holder;
+            }
         }
</code></pre>

The following modification verifies this.
<pre><code class="shell">
--- a/src/java.base/share/classes/sun/util/locale/BaseLocale.java
+++ b/src/java.base/share/classes/sun/util/locale/BaseLocale.java

@@ -257,19 +261,21 @@ public final class BaseLocale {

         private final boolean normalized;
         private final int hash;
-
+        private BaseLocale locale;    // make locale to a member variable
         private Key(String language, String script, String region,
                     String variant, boolean normalize) {
-            BaseLocale locale = new BaseLocale(language, script, region, variant, normalize);
+            locale = new BaseLocale(language, script, region, variant, normalize);
             this.normalized = normalize;
</code></pre>
But this should not be a reasonable solution. I think I should to find a better solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1569881913

From naoto at openjdk.org  Wed May 31 16:00:15 2023
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 May 2023 16:00:15 GMT
Subject: <i18n dev> Integrated: 8308316: Default decomposition mode in
 Collator
In-Reply-To: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
References: <mpGlYyLW43VJzXYmah306JnBjYqprlv1PgaDIEHPwJo=.dbd09895-2d91-447c-a86e-2575791f5598@github.com>
Message-ID: <CHFd3WpcoLkajx9Gzd-x0PkXx1RBloRYlGyhyQirarA=.ba2bc889-5402-43d5-8221-452d40be2add@github.com>

On Thu, 18 May 2023 18:02:32 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Amending the description about the default decomposition mode in `Collator.NO_DECOMPOSITION` javadoc.

This pull request has now been integrated.

Changeset: 12649025
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/126490251721d131098a0bc2def8fd02f97cd5af
Stats:     5 lines in 1 file changed: 1 ins; 0 del; 4 mod

8308316: Default decomposition mode in Collator

Reviewed-by: rriggs

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

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

From alanb at openjdk.org  Wed May 31 16:20:55 2023
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 May 2023 16:20:55 GMT
Subject: <i18n dev> RFR: 8289220: [Shenandoah] TestAllocObjectArrays
 fails intermittently
In-Reply-To: <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>
References: <I0e3B292B81tFSWRWHlUDFbH3cBAaM9mrha5DTTDAjs=.e79d600a-2469-4ff8-9fdf-a4852a5f50b9@github.com>
 <GOxbhP3BXGBlNsKCAmnVF6hl0xg5oXpItR7WLtLJwOY=.1c8bbd73-8708-47e5-bdbb-3ce34cda7697@github.com>
Message-ID: <My4tRq39smbhtJgChhGkmDaLZ0ARSG8MKOtdsf4eqkA=.9d68b39b-252e-4a79-9f94-4265edc1ac7f@github.com>

On Wed, 31 May 2023 10:00:18 GMT, SUN Guoyun <duke at openjdk.org> wrote:

> Jtreg tier1 can trigger the same error with vmoptions:"-Xcomp -XX:+UseShenandoahGC -XX:ShenandoahGCHeuristics=aggressive -XX:+ShenandoahOOMDuringEvacALot I found the GC occurs between when the soft reference is assigned and when it is used.

Yes, this seems to be a bug here so I think move the issue to core-libs/java.util:i18n as it looks like the caching done by BaseLocale needs to be re-examined.

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

PR Comment: https://git.openjdk.org/jdk/pull/14211#issuecomment-1570534648

From xuelei at openjdk.org  Wed May 31 16:30:12 2023
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Wed, 31 May 2023 16:30:12 GMT
Subject: <i18n dev> Integrated: 8308022: update for deprecated sprintf for
 java.base
In-Reply-To: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
References: <JjahVxNt8fk-ztxZOYhe7ejapBwV45evEUVg4wMEbQ8=.171b6823-593f-4f71-b964-c6e3d427eac1@github.com>
Message-ID: <rCdBonJOna_uEXj1KxzrDtAXDbLejGQXDRvZQKxABUQ=.f47b45c6-0e49-4fe7-bbd8-b17f20b95a6d@github.com>

On Fri, 12 May 2023 17:57:43 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

> Hi,
> 
> May I have this update reviewed?
> 
> The sprintf is deprecated in Xcode 14, and Microsoft Virtual Studio, because of security concerns. The issue was addressed in [JDK-8296812](https://bugs.openjdk.org/browse/JDK-8296812) for building failure, and [JDK-8299378](https://bugs.openjdk.org/browse/JDK-8299378)/[JDK-8299635](https://bugs.openjdk.org/browse/JDK-8299635)/[JDK-8301132](https://bugs.openjdk.org/browse/JDK-8301132) for testing issues . This is a break-down update for sprintf uses in the java.base module.
> 
> Thanks,
> Xuelei

This pull request has now been integrated.

Changeset: 42ca6e69
Author:    Xue-Lei Andrew Fan <xuelei at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/42ca6e69420e090cdec16f3bd1e5c70506511663
Stats:     37 lines in 6 files changed: 5 ins; 0 del; 32 mod

8308022: update for deprecated sprintf for java.base

Reviewed-by: naoto

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

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