From rriggs at openjdk.org  Mon Aug  1 14:04:46 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 14:04:46 GMT
Subject: <i18n dev> RFR: 8289227: Support for BCP 47 Extension T -
 Transformed Content [v3]
In-Reply-To: <giGrookyHaGPl3emN1hHJNvgMBnKV1l7e_8xIYOc59s=.a4990eba-71a5-45e7-bca1-36625025ce41@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <yk2lTbFAA26vSWBxuuCELVYufd33slJ4P_8DZN6PdAo=.63e231f1-4ef3-4c3b-aa7c-467888b00894@github.com>
 <iKt-_Hy_pqoALXJBZnBeyGyiFpNUVTmZ0kWQW7DqAfo=.afb348a4-c072-4bd0-b844-5064b5cea254@github.com>
 <giGrookyHaGPl3emN1hHJNvgMBnKV1l7e_8xIYOc59s=.a4990eba-71a5-45e7-bca1-36625025ce41@github.com>
Message-ID: <JXFG6k1E4GqJ64dQyEhyBhNvDrcfyGZ5q6ByEJ0uD7k=.234b5033-7522-4e64-badc-5bc3194a09d3@github.com>

On Tue, 26 Jul 2022 20:52:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> > I would suggest deferring the APIs for `getTransformedContentFields()` and `getTransformedContentSource()`.
> 
> OK, removed those two convenient APIs.

I expected much of the complexity of parsing and storing content transformed extension strings would be unnecessary without the APIs. The original string form of the extension should be sufficient for `Locale.getExtension`. It also adds quite a bit of complexity and overhead to getDisplayName to reconstruct the strings.  The correct syntax of the string can be checked with a RegEx in the builder. If a simpler implementation is sufficient, there is less code to maintain.

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

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

From naoto at openjdk.org  Mon Aug  1 16:46:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Aug 2022 16:46:01 GMT
Subject: <i18n dev> [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource
 files update - msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <O9yRN6jY9EjtvHp7fHIG81kU_uHr4nFmFs2tviKvJ5k=.a3ff6f40-de36-4f0c-af35-e1adf2c4bf55@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/154

From naoto at openjdk.org  Mon Aug  1 21:11:48 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 1 Aug 2022 21:11:48 GMT
Subject: <i18n dev> RFR: 8289227: Support for BCP 47 Extension T -
 Transformed Content [v6]
In-Reply-To: <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
Message-ID: <Tgy4speKY6VBTUWMIAvdTMYv2IEx8XmkKKgvbNqZEgk=.9f4c26da-57ad-421e-ab3e-fed56e4d1581@github.com>

On Sat, 30 Jul 2022 20:52:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `assertThrows`

Looks like it is not much of an additional benefit without APIs. Decided not to implement it at this time.

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

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

From duke at openjdk.org  Mon Aug  1 21:33:19 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Mon, 1 Aug 2022 21:33:19 GMT
Subject: <i18n dev> RFR: 8289227: Support for BCP 47 Extension T -
 Transformed Content [v6]
In-Reply-To: <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
Message-ID: <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>

On Sat, 30 Jul 2022 20:52:49 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use `assertThrows`

lgtm

hi! by the way if you want to see some more `-t-` names in the wild, I recently merged https://github.com/unicode-org/cldr/pull/1755

test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 80:

> 78:         return new Object[][] {
> 79:                 {L1, Locale.US,
> 80:                         "Cyrillic (Transform: Latin, Transform Rules: UN GEGN Transliteration 2007)"},

? I like these display names!

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

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

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

From duke at openjdk.org  Mon Aug  1 21:33:19 2022
From: duke at openjdk.org (Steven R. Loomis)
Date: Mon, 1 Aug 2022 21:33:19 GMT
Subject: <i18n dev> RFR: 8289227: Support for BCP 47 Extension T -
 Transformed Content [v6]
In-Reply-To: <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
 <faQQwKs-rMsZgiNG_TK-939cvRYvUh9TUUr69rVy3iE=.777828d6-40c2-4cb2-b044-ee1847509f32@github.com>
 <eHuk3dluSo_vg7rFkkJm-i8GDQg19_v5mlIIpTWFVS0=.7222edc6-801d-45c0-bd1d-0bdac52c4fd9@github.com>
Message-ID: <ZxQDyKQJf3OkCrAx1dPPfcRKm3x6RUF6k7I78Vxs_iU=.c8d2ae70-3530-418c-8a15-5dd85e06d4e1@github.com>

On Mon, 1 Aug 2022 21:27:47 GMT, Steven R. Loomis <duke at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use `assertThrows`
>
> test/jdk/java/util/Locale/bcp47/TExtensionTests.java line 80:
> 
>> 78:         return new Object[][] {
>> 79:                 {L1, Locale.US,
>> 80:                         "Cyrillic (Transform: Latin, Transform Rules: UN GEGN Transliteration 2007)"},
> 
> ? I like these display names!

Note: another class of use for `-t-` is for keyboards, so for example `ar-t-k0-windows-azerty` in https://github.com/unicode-org/cldr/blob/release-41/keyboards/windows/ar-t-k0-windows-azerty.xml

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

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

From alanb at openjdk.org  Tue Aug  2 08:39:23 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 08:39:23 GMT
Subject: <i18n dev> RFR: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

test/jdk/java/beans/XMLEncoder/Test4625418.java line 26:

> 24: /*
> 25:  * @test
> 26:  * @bug 4625418 8239965 8290488

I'm curious why this XMLEncoder test is updated, is this related to round trip?

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

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

From naoto at openjdk.org  Tue Aug  2 16:31:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 2 Aug 2022 16:31:40 GMT
Subject: <i18n dev> RFR: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
 <Xsk5_R7ADbfiC6cmP2skDWD8_Iiz7ItFWcqlsPVtk4U=.a2544e1d-efdd-4eb3-ba55-477e7ed63063@github.com>
Message-ID: <HjK3kXbc5EHjKmeNX5B2espel3KKdVxwrroi1k8TH8I=.d56b6d48-3ef0-4fa1-babf-0cf29e717e17@github.com>

On Tue, 2 Aug 2022 08:35:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.
>
> test/jdk/java/beans/XMLEncoder/Test4625418.java line 26:
> 
>> 24: /*
>> 25:  * @test
>> 26:  * @bug 4625418 8239965 8290488
> 
> I'm curious why this XMLEncoder test is updated, is this related to round trip?

Yes. The test assumes all code points below U+10000 have 1-1 roundtrip (c2b2c). Since the assumption is now not met with this change, I commented out the 864 entries.

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

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

From alanb at openjdk.org  Tue Aug  2 16:55:19 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 16:55:19 GMT
Subject: <i18n dev> RFR: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <b64VG2VxbmMKsu3WyO9MeJvcJdYL1le0JO-Jy57OkXU=.92d068eb-9c81-4404-8d4e-50696e28e11b@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

Marked as reviewed by alanb (Reviewer).

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

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

From dfuchs at openjdk.org  Wed Aug  3 11:03:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 Aug 2022 11:03:40 GMT
Subject: <i18n dev> RFR: 8290300: Use standard String-joining tools
 where applicable [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <CflYKTgGuEth9cBpvx-_nme9-IyesWKwtVvPN7mcTvI=.9e217399-8639-4bcc-bfb0-a8eb59531176@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Changes to HttpURLConnection look good to me

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

Marked as reviewed by dfuchs (Reviewer).

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

From djelinski at openjdk.org  Wed Aug  3 14:08:07 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Aug 2022 14:08:07 GMT
Subject: <i18n dev> RFR: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
Message-ID: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>

This patch fixes the test to use the same locale as the tested code

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

Commit messages:
 - CustomZoneNameTest fails if default locale does not match defaultFormatLocale

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

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

From itakiguchi at openjdk.org  Wed Aug  3 14:11:40 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Wed, 3 Aug 2022 14:11:40 GMT
Subject: <i18n dev> RFR: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

I think you can ignore my comments.
I'm not sure if this change will solve the reporter's issue...

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

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

From naoto at openjdk.org  Wed Aug  3 16:03:45 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 16:03:45 GMT
Subject: <i18n dev> Integrated: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
Message-ID: <M43QL4lwZ4nFwGPJb4u8tx21xMGOTCgUAk4r30gKpGo=.33a8fcfb-b13a-4496-9fff-184329395b6c@github.com>

On Wed, 27 Jul 2022 17:47:36 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Adding an extra c2b mapping for the `%` in `IBM864` charset. The discrepancy came from the mapping difference between MS and IBM.

This pull request has now been integrated.

Changeset: e52a340d
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e52a340d7fca161539524eedc0c2d48283f4f0a7
Stats:     6 lines in 3 files changed: 2 ins; 0 del; 4 mod

8290488: IBM864 character encoding implementation bug

Reviewed-by: iris, joehw, alanb

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

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

From naoto at openjdk.org  Wed Aug  3 16:17:51 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 16:17:51 GMT
Subject: <i18n dev> RFR: 8290488: IBM864 character encoding
 implementation bug
In-Reply-To: <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>
References: <VE8WFnXOxsRt1nGE66iieGULGu6xxipT-hEGFMMb6Z0=.393e2e92-b2a1-4020-a12f-d70bb571574f@github.com>
 <Z9cLohRva-yFJQWLa92BGpN3kJMnyg7editznjLRmgs=.408b9af7-9269-4049-89df-51d92cc59c38@github.com>
Message-ID: <axRevRchJX0lfCIOsDhv3kS3CNJVZm9RsZtbW3Z_oqQ=.943c7aec-9934-4ace-a2fa-a53624c10804@github.com>

On Wed, 3 Aug 2022 14:08:26 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> I'm not sure if this change will solve the reporter's issue...

It does solve the submitter's issue. With this fix:

jshell> HexFormat.ofDelimiter(" ").formatHex("<%adc".getBytes("IBM864"))
$181 ==> "3c 25 61 64 63"

which is exactly the expected result.

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

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

From naoto at openjdk.org  Wed Aug  3 17:04:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 3 Aug 2022 17:04:39 GMT
Subject: <i18n dev> RFR: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
In-Reply-To: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
References: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
Message-ID: <FvOIgQxQb2zOUz3gZbbP4ccddSNiSUUHTLZImJrHyps=.83f4fb1c-5071-47c9-8847-ae8f7f22a50e@github.com>

On Wed, 3 Aug 2022 13:55:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the test to use the same locale as the tested code

LGTM. Thanks for the fix!

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

Marked as reviewed by naoto (Reviewer).

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

From djelinski at openjdk.org  Thu Aug  4 06:59:58 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 4 Aug 2022 06:59:58 GMT
Subject: <i18n dev> Integrated: 8291825:
 java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if
 defaultLocale and defaultFormatLocale are different
In-Reply-To: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
References: <MjhUu8D26UXPFnSu-IxaaSl9JxDDqL4GVgvsUZQEx5E=.821603c7-ae48-4e42-8b73-45d12baac31b@github.com>
Message-ID: <Y20iTC0pM_CJ7223R9Z4Q5336zGJbqaCj_JBIoFkTgc=.8436b1bc-62cd-499f-845a-667f818f0b1a@github.com>

On Wed, 3 Aug 2022 13:55:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch fixes the test to use the same locale as the tested code

This pull request has now been integrated.

Changeset: 4772354f
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4772354f4caf5eb314eda81217e5bc48a62d485b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8291825: java/time/nontestng/java/time/zone/CustomZoneNameTest.java fails if defaultLocale and defaultFormatLocale are different

Reviewed-by: naoto

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

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

From duke at openjdk.org  Thu Aug  4 18:53:18 2022
From: duke at openjdk.org (Gaurav Chaudhari)
Date: Thu, 4 Aug 2022 18:53:18 GMT
Subject: <i18n dev> Integrated: 8288377: [REDO] DST not applying properly
 with zone id offset set with TZ env variable
In-Reply-To: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
References: <LuefGB--y1FnK1jz5OYGbCLPvm0nLP8PREptv5tImHs=.cbfb1a45-52ec-4983-aced-4606b72b7062@github.com>
Message-ID: <Gi8R81a7_kywu2qVCiCT0OqCF6FOfUTKj97N0Xy9KC0=.4b1e0f69-04ef-46c8-9984-71f99f10ab35@github.com>

On Tue, 28 Jun 2022 18:52:32 GMT, Gaurav Chaudhari <duke at openjdk.org> wrote:

> This is a REDO of the Fix that was incompletely implemented earlier:
> [8285838: Fix for TZ environment variable DST rules](https://github.com/openjdk/jdk/pull/8660)
> 
> Offset calculation now accounts all the way upto year in order to avoid cross-day miscalculations as well as to calculate always in the correct direction for offset. In situations where there may be multiple days, the excess days of offset will be shaved off by applying mod to `seconds_per_day` , which will remove the excessive days that might be included in the offset calculation for special scenarios like a leap year / February months and variances between 30 and 31 days.
> 
> I have tested this solution with the cases where this fix had failed last time as well, and confirmed it works:
> _(where 7200 represents 7200 seconds -> +2 hour offset)_
> Sample output:
> ![image](https://user-images.githubusercontent.com/6877595/176259828-07e27901-4a3f-4949-bd8d-2f88c979685a.png)

This pull request has now been integrated.

Changeset: 3c325641
Author:    Gaurav Chaudhari <deigue at hotmail.com>
Committer: Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c3256414f7df049cdd6c8519fbcea0d818a1a33
Stats:     126 lines in 2 files changed: 86 ins; 28 del; 12 mod

8288377: [REDO] DST not applying properly with zone id offset set with TZ env variable

Reviewed-by: naoto

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

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

From itakiguchi at openjdk.org  Fri Aug  5 02:22:44 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 5 Aug 2022 02:22:44 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Arabic Windows
 command prompt
Message-ID: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>

To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.

- IBM860
- IBM861
- IBM863
- IBM864
- IBM865
- IBM869

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

Commit messages:
 - 8291916: Unexpected output on Arabic Windows command prompt

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

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

From alanb at openjdk.org  Fri Aug  5 06:37:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 06:37:50 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Arabic Windows
 command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <Iv2XVR3LT2ZJOX-XPInyizqaAH2tB8EgA_UG_CYfkCQ=.dab3684a-90e6-4257-9034-5717f9b195d9@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

IBM860 is Portuguese, IBM861 is Icelandic, IBM863 seems to be Candian French. So I think this is adding more than just Arabic charsets, it's really about expanding the set of configurations support on Windows I think.

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

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

From naoto at openjdk.org  Fri Aug  5 16:48:10 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 5 Aug 2022 16:48:10 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Arabic Windows
 command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

Hi @takiguc,
I am not quite sure what is the rationale for moving those charsets into `java.base` module. IIUC, we typically did such a fix when the java runtime cannot boot in a supported configuration (https://bugs.openjdk.org/browse/JDK-8187910), but it seems that this issue does not warrant such a requirement. Will you elaborate more?

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

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

From itakiguchi at openjdk.org  Mon Aug  8 00:24:04 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 8 Aug 2022 00:24:04 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
Message-ID: <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>

On Thu, 7 Jul 2022 09:47:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> And also there is no reason why db drivers or host connectors should not ship their own charset support \(Oracle JDBC for example had nls\_charset addons\. My employer also ship a custom EBCDIC encoding which includes some compatibility hacks\, and that took some effort to adopt it to the missing ext mechanism\)\.
>> 
>> Having said that\, with JPMS a \?legacy ebcdic\? encoding module would be possible while still being optional\. Maybe in the future a mechanism for modules which can be added \(instead of removed\) from standard distribution would make that nicer\?
>> 
>> Is there a performance restriction for charset if they are not part of a platform module \(optimized string access\)\?
>> 
>> Gruss
>> Bernd
>> 
>> 
>> \-\-
>> http\:\/\/bernd\.eckenfels\.net
>> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
>> Von\: core\-libs\-dev \<core\-libs\-dev\-retn at openjdk\.org> im Auftrag von Alan Bateman \<alanb at openjdk\.org>
>> Gesendet\: Thursday\, July 7\, 2022 11\:50\:39 AM
>> An\: build\-dev at openjdk\.org \<build\-dev at openjdk\.org>\; core\-libs\-dev at openjdk\.org \<core\-libs\-dev at openjdk\.org>\; i18n\-dev at openjdk\.org \<i18n\-dev at openjdk\.org>
>> Betreff\: Re\: RFR\: 8289834\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> On Wed\, 6 Jul 2022 16\:18\:08 GMT\, Ichiroh Takiguchi \<itakiguchi at openjdk\.org> wrote\:
>> 
>>> Discussions are available on \:
>>> \[JDK\-8289834\]\(https\:\/\/bugs\.openjdk\.org\/browse\/JDK\-8289834\)\: Add SBCS and DBCS Only EBCDIC charsets
>> 
>> Yes\, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets\. I understand they can be useful for someone using JDBC to connect to a database on z\/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path\. Do you know if the icu4j project is still alive\? I\'ve often wondered why there wasn\'t more use of the provider mechanism\.
>> 
>> \-\-\-\-\-\-\-\-\-\-\-\-\-
>> 
>> PR\: https\:\/\/git\.openjdk\.org\/jdk\/pull\/9399
>> \-\-\-\-\-\-\-\-\-\-\-\-\-\- next part \-\-\-\-\-\-\-\-\-\-\-\-\-\-
>> An HTML attachment was scrubbed\.\.\.
>> URL\: \<https\:\/\/mail\.openjdk\.org\/pipermail\/core\-libs\-dev\/attachments\/20220707\/2d095f3d\/attachment\-0001\.htm>
>
>> Discussions are available on :
>> [JDK-8289834](https://bugs.openjdk.org/browse/JDK-8289834): Add SBCS and DBCS Only EBCDIC charsets
> 
> Yes, I think this need discussion on whether the JDK really needs to keep including and adding more EBCDIC charsets. I understand they can be useful for someone using JDBC to connect to a database on z/OS but this scenario would work equally well if the EBCDIC charsets were deployed on the class path or module path. Do you know if the icu4j project is still alive? I've often wondered why there wasn't more use of the provider mechanism.

Hello @AlanBateman .
Sorry I'm late.
I got some responses from ICU. [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
I'm not sure if they're interested in the new charset...

As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage.
And some other performance advantages are there on built-in charset decoder/encoder.
Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes?
We'd like to use stable conversion loop.

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

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

From itakiguchi at openjdk.org  Mon Aug  8 01:37:38 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Mon, 8 Aug 2022 01:37:38 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Arabic Windows
 command prompt
In-Reply-To: <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
 <OMTA_IGw99A63itvMADg1AOfSSwWLbUSpY_H9PO_QIo=.66f8288a-6ac3-4fad-a13e-81787faa3a05@github.com>
Message-ID: <zXwZ1vYsjQbsTBRUeR0tC5eKb1xaHY0Uh66TeUcW6nE=.ddf86f0f-58c8-4d19-84fa-71ba042a55c7@github.com>

On Fri, 5 Aug 2022 16:44:37 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
>> 
>> - IBM860
>> - IBM861
>> - IBM863
>> - IBM864
>> - IBM865
>> - IBM869
>
> Hi @takiguc,
> I am not quite sure what is the rationale for moving those charsets into `java.base` module. IIUC, we typically did such a fix when the java runtime cannot boot in a supported configuration (https://bugs.openjdk.org/browse/JDK-8187910), but it seems that this issue does not warrant such a requirement. Will you elaborate more?

Hello @naotoj .
As Alan was described, windows codepage mapping table is as follows

- 860 - Portuguese (DOS) - IBM860
- 861 - Icelandic (DOS) - IBM861
- 863 - French Canadian (DOS) - IBM863
- 864 - Arabic (864) - IBM864
- 865 - Nordic (DOS) - IBM865
- 869 - Greek, Modern (DOS) - IBM869

Java 8 implementation is as follows:
Windows command prompt setting, following sample is 864.

>chcp 864
Active code page: 864

Test program

>type termdump.java
import java.nio.charset.*;

public class termdump {
  public static void main(String[] args) throws Exception {
    String csname = System.getProperty("sun.stdout.encoding");
    if (csname == null) csname = System.getProperty("stdout.encoding");
    System.out.println(csname);
    Charset cs = Charset.forName(csname);
    for (int i0 = 0; i0 < 0x100; i0 += 0x10) {
      StringBuilder sb = new StringBuilder();
      for (int i1 = 0; i1 < 0x10; i1++) {
        byte[] ba = new byte[1];
        ba[0] = (byte) (i0 | i1);
        String s = new String(ba, csname);
        if (s.length() == 1) {
          char ch = s.charAt(0);
          if (ch < 0x7F) continue;
          if (Character.isISOControl(ch)) continue;
          if (ch == '\uFFFD') continue;
          sb.append(ch);
        }
      }
      if (sb.length() > 0) {
        System.out.printf("0x%02X %s%n", i0, sb.toString());
        System.out.print("    ");
        for (char ch : sb.toString().toCharArray()) {
          System.out.printf(" %04X", (int)ch);
        }
        System.out.println();
      }
    }
  }
}

Java8 output

>jdk8u345-b01\jre\bin\java termdump
cp864
0x20 %
     066A
0x80 ????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ?????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ??????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ???????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

Java20 output

>jdk-20\bin\java termdump
cp864
0x20 ??
     066A
0x80 ??????????????????????????????????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ????????????????????????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ?????????????????????????????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????????????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ???????????????????????????????????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????????????????????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ???????????????????????????????????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ????????????????????????????????????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

Fixed output

>java -showversion termdump
openjdk version "20-internal" 2023-03-21
OpenJDK Runtime Environment (build 20-internal-adhoc.Administrator.jdk)
OpenJDK 64-Bit Server VM (build 20-internal-adhoc.Administrator.jdk, mixed mode, sharing)
cp864
0x20 %
     066A
0x80 ????????????????
     00B0 00B7 2219 221A 2592 2500 2502 253C 2524 252C 251C 2534 2510 250C 2514 2518
0x90 ?????????????
     03B2 221E 03C6 00B1 00BD 00BC 2248 00AB 00BB FEF7 FEF8 FEFB FEFC
0xA0 ??????????????
     00A0 00AD FE82 00A3 00A4 FE84 FE8E FE8F FE95 FE99 060C FE9D FEA1 FEA5
0xB0 ????????????????
     0660 0661 0662 0663 0664 0665 0666 0667 0668 0669 FED1 061B FEB1 FEB5 FEB9 061F
0xC0 ????????????????
     00A2 FE80 FE81 FE83 FE85 FECA FE8B FE8D FE91 FE93 FE97 FE9B FE9F FEA3 FEA7 FEA9
0xD0 ????????????????
     FEAB FEAD FEAF FEB3 FEB7 FEBB FEBF FEC1 FEC5 FECB FECF 00A6 00AC 00F7 00D7 FEC9
0xE0 ????????????????
     0640 FED3 FED7 FEDB FEDF FEE3 FEE7 FEEB FEED FEEF FEF3 FEBD FECC FECE FECD FEE1
0xF0 ???????????????
     FE7D 0651 FEE5 FEE9 FEEC FEF0 FEF2 FED0 FED5 FEF5 FEF6 FEDD FED9 FEF1 25A0

863's output is as follows:

>chcp 863
Active code page: 863

>jdk8u345-b01\jre\bin\java termdump
cp863
0x80 ????????????????
     00C7 00FC 00E9 00E2 00C2 00E0 00B6 00E7 00EA 00EB 00E8 00EF 00EE 2017 00C0 00A7
0x90 ????????????????
     00C9 00C8 00CA 00F4 00CB 00CF 00FB 00F9 00A4 00D4 00DC 00A2 00A3 00D9 00DB 0192
0xA0 ????????????????
     00A6 00B4 00F3 00FA 00A8 00B8 00B3 00AF 00CE 2310 00AC 00BD 00BC 00BE 00AB 00BB
0xB0 ????????????????
     2591 2592 2593 2502 2524 2561 2562 2556 2555 2563 2551 2557 255D 255C 255B 2510
0xC0 ????????????????
     2514 2534 252C 251C 2500 253C 255E 255F 255A 2554 2569 2566 2560 2550 256C 2567
0xD0 ????????????????
     2568 2564 2565 2559 2558 2552 2553 256B 256A 2518 250C 2588 2584 258C 2590 2580
0xE0 ????????????????
     03B1 00DF 0393 03C0 03A3 03C3 00B5 03C4 03A6 0398 03A9 03B4 221E 03C6 03B5 2229
0xF0 ????????????????
     2261 00B1 2265 2264 2320 2321 00F7 2248 00B0 2219 00B7 221A 207F 00B2 25A0 00A0

>jdk-20\bin\java termdump
cp863
0x80 ?????????????????????????????????
     00C7 00FC 00E9 00E2 00C2 00E0 00B6 00E7 00EA 00EB 00E8 00EF 00EE 2017 00C0 00A7
0x90 ????????????????????????????????
     00C9 00C8 00CA 00F4 00CB 00CF 00FB 00F9 00A4 00D4 00DC 00A2 00A3 00D9 00DB 0192
0xA0 ?????????????????????????????????
     00A6 00B4 00F3 00FA 00A8 00B8 00B3 00AF 00CE 2310 00AC 00BD 00BC 00BE 00AB 00BB
0xB0 ????????????????????????????????????????????????
     2591 2592 2593 2502 2524 2561 2562 2556 2555 2563 2551 2557 255D 255C 255B 2510
0xC0 ????????????????????????????????????????????????
     2514 2534 252C 251C 2500 253C 255E 255F 255A 2554 2569 2566 2560 2550 256C 2567
0xD0 ????????????????????????????????????????????????
     2568 2564 2565 2559 2558 2552 2553 256B 256A 2518 250C 2588 2584 258C 2590 2580
0xE0 ??????????????????????????????????
     03B1 00DF 0393 03C0 03A3 03C3 00B5 03C4 03A6 0398 03A9 03B4 221E 03C6 03B5 2229
0xF0 ??????????????????????????????????????????
     2261 00B1 2265 2264 2320 2321 00F7 2248 00B0 2219 00B7 221A 207F 00B2 25A0 00A0

We are in final phase to migrate from Java8 to next stable Java.
I think tt should be fixed.

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

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

From alanb at openjdk.org  Mon Aug  8 09:26:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Aug 2022 09:26:22 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
 <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
Message-ID: <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>

On Mon, 8 Aug 2022 00:19:57 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage. And some other performance advantages are there on built-in charset decoder/encoder. Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes? We'd like to use stable conversion loop.

If they have ASCII compatible regions then that may be so but I haven't see any performance data published on that. Do you know if any experiments that have deployed a CharsetProvider for the EBCDIC charsets and compared the performance with the charsets that in the JDK? There may be merit in exploring adding base abstracts implementations of CharsetEncoder/CharsetDecoder to java.nio.charsets.spi to support single and double byte charsets to see how such base implementations might look, how they would help performance, and if there are any security downsides.

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

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

From asemenyuk at openjdk.org  Tue Aug  9 17:53:36 2022
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 9 Aug 2022 17:53:36 GMT
Subject: <i18n dev> [jdk19] RFR: 8290889: JDK 19 RDP2 L10n resource
 files update - msgdrop 10 [v4]
In-Reply-To: <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
 <vKXwAs-SGIVaskDopc7GE6LIGnafs2yZFLW3jG6q0zg=.1c432b6d-b66c-4419-8fb5-5d8863e6e51c@github.com>
Message-ID: <k6yuO7WWfo6sUSzqiUmIpuktBZjIi1IlHrmDkULvDvY=.bd053666-f50f-4777-9377-0df00efd5fa5@github.com>

On Fri, 29 Jul 2022 18:13:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

>> open l10n msg drop
>> All tests passed.
>
> Alisen Chung has updated the pull request incrementally with one additional commit since the last revision:
> 
>   added comments in CurrencyNames root in base, moved US CurrencyNames back to base, readded original Chinese translation

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good. Approved that part.

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

PR: https://git.openjdk.org/jdk19/pull/154

From naoto at openjdk.org  Tue Aug  9 20:40:40 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 9 Aug 2022 20:40:40 GMT
Subject: <i18n dev> RFR: 8291916: Unexpected output on Arabic Windows
 command prompt
In-Reply-To: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
References: <kCEIAwQZuJQRpQB-usp-YiUpUyULY1gzf6Bcf-6ZAtU=.e592478d-a7da-4220-84df-914a02dbe1a2@github.com>
Message-ID: <xvXRAlkC7Q81fP5b63cOVROBypIqiYPPuS_OY19qWkA=.3ac6b47a-0a97-45ba-88d5-5b13836f7c06@github.com>

On Fri, 5 Aug 2022 02:15:21 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> To support Windows command prompt's codepage, following charsets should be moved from jdk.charsets module to java.base module.
> 
> - IBM860
> - IBM861
> - IBM863
> - IBM864
> - IBM865
> - IBM869

I looked at this issue a bit more. It looks to me that the issue is caused by the fact that the encoding of `System.out` falls back to the default encoding, as `IBM864` is not in `java.base`. This issue seems not new and reproducible with the releases since JDK9 where modularization has been introduced. Also, I think other encodings than those `IBM*` listed here, can possibly cause this issue. In order to fix this completely, those obscure encodings also have to be in `java.base` which I don't think we would want to do.

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

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

From achung at openjdk.org  Tue Aug  9 22:30:54 2022
From: achung at openjdk.org (Alisen Chung)
Date: Tue, 9 Aug 2022 22:30:54 GMT
Subject: <i18n dev> [jdk19] Integrated: 8290889: JDK 19 RDP2 L10n resource
 files update - msgdrop 10
In-Reply-To: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
References: <sm_MskEXYa57rZRlnc_0Q3dW2_XZeT3hoMih9fjMkEk=.55bca83f-5bf7-4cae-8d1b-5e0b0f55b5bf@github.com>
Message-ID: <q3eKnCK-mTAP42I8K9ifRoP0RBS0nLNwsGoZpEt_e0A=.5da69e5f-4232-40e4-8f69-ccae924fcd3a@github.com>

On Sat, 23 Jul 2022 03:03:25 GMT, Alisen Chung <achung at openjdk.org> wrote:

> open l10n msg drop
> All tests passed.

This pull request has now been integrated.

Changeset: 0def5316
Author:    Alisen Chung <achung at openjdk.org>
Committer: Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/0def5316cd2ec7699c649bf67bf58e6315c3010b
Stats:     684 lines in 42 files changed: 87 ins; 540 del; 57 mod

8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

Reviewed-by: naoto, asemenyuk

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

PR: https://git.openjdk.org/jdk19/pull/154

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: <i18n dev> Integrated: Merge jdk19
Message-ID: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>

Forward port JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8288769: Revert unintentional change to deflate.c
 - 8291496: Allocating card table before heap causes underflow asserts in CardTable::addr_for()
 - 8290889: JDK 19 RDP2 L10n resource files update - msgdrop 10

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9828&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9828/files
  Stats: 686 lines in 44 files changed: 89 ins; 540 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/9828.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9828/head:pull/9828

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

From dholmes at openjdk.org  Thu Aug 11 05:26:56 2022
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 11 Aug 2022 05:26:56 GMT
Subject: <i18n dev> Integrated: Merge jdk19
In-Reply-To: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
References: <Iq9VI6ueABL5_vd9sws6mSxoU2NLFNwS2PN0EfJJDVM=.ef58f425-3f29-41d8-ace3-d307c5bf3104@github.com>
Message-ID: <tDsmxM0i7TDUsE501WbVPMDEMsZb2_d1PaZb84pVJQI=.4b33399d-425a-44ee-a1b3-ea91f25f487e@github.com>

On Thu, 11 Aug 2022 00:06:35 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Forward port JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 85a60235
Author:    David Holmes <dholmes at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/85a602355ff6e92bb468135d712e0b0b41753db4
Stats:     686 lines in 44 files changed: 89 ins; 540 del; 57 mod

Merge

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

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

From duke at openjdk.org  Sun Aug 21 15:13:12 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 15:13:12 GMT
Subject: <i18n dev> RFR: 8290300: Use standard String-joining tools
 where applicable [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <_s3sF9jqz1Y0MQgdRZhGtR-tw5SWD31kE9qc0VLVPu4=.b7288078-0987-422d-8dbf-08b3231c60b4@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Anyone to sponsor?

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

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

From duke at openjdk.org  Sun Aug 21 17:26:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 17:26:25 GMT
Subject: <i18n dev> Integrated: 8290300: Use standard String-joining tools
 where applicable
In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
Message-ID: <svnuj6nwuqYSwv8UKIS1dmTsPaOiLVcc3Bq496Iwb1k=.0a3c92b1-ee46-47ea-932b-71407fd5096f@github.com>

On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Simplify code with `String.join()`

This pull request has now been integrated.

Changeset: 9a65524e
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a65524e2f98c1b4e253dcb637a708cec7b591bc
Stats:     18 lines in 4 files changed: 0 ins; 12 del; 6 mod

8290300: Use standard String-joining tools where applicable

Reviewed-by: naoto, rriggs, dfuchs

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

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

From duke at openjdk.org  Sun Aug 21 18:48:29 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 18:48:29 GMT
Subject: <i18n dev> RFR: 8290300: Use standard String-joining tools
 where applicable [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <BCU12FIOG4jTD6ccnV1_RxyBvCcQAdqjq_CsekHDvr8=.8500dbee-3869-4ca6-bae4-274f7a658763@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Thanks!

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

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

From naoto at openjdk.org  Tue Aug 23 22:54:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 23 Aug 2022 22:54:12 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
Message-ID: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>

This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

Commit messages:
 - 8291660: Grapheme support in BreakIterator
 - 8291660: Add a method to stream extended grapheme clusters in a String

Changes: https://git.openjdk.org/jdk/pull/9991/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9991&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291660
  Stats: 251 lines in 10 files changed: 170 ins; 48 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

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

From smarks at openjdk.org  Thu Aug 25 03:46:40 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 03:46:40 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <SPeojmhJm13tBbkUPgjEo9OY7HPdnDxq9XVklKnxlzY=.5b9ce3cb-648c-41a5-b87c-61742c74a8fc@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

test/jdk/java/util/regex/whitebox/GraphemeTest.java line 30:

> 28:  * @library /lib/testlibrary/java/lang
> 29:  * @compile --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest.java
> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED --add-opens java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest

Can you use the `@modules` directive to export+open the internal module to the test?

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

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

From smarks at openjdk.org  Thu Aug 25 03:56:34 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 03:56:34 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 258:

> 256:                     .filter(i -> boundaries.get(i) > offset)
> 257:                     .findFirst()
> 258:                     .orElse(boundaries.size() - 1);

Is it worth trying to use Collections.binarySearch() here? I think the boundaries list is in ascending sorted order, so you might be able to drop in a binarySearch() call directly. (Need to be a bit careful with negative return values.)

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

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

From smarks at openjdk.org  Thu Aug 25 04:06:28 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 25 Aug 2022 04:06:28 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <eMmxmEfOnBYX3f2wTqQE41y4yu3yLUhEqzyaA5AIwGg=.e52ee19a-8a69-49bd-a60e-25784b57b347@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

I took a quick look. Overall looks reasonable. How much scrutiny did you need?

Also, nice use of method handles.

Might be helpful to provide an example of the behavior change in the CSR.

This is probably also worth a release note documenting the behavior change and showing an example.

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

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

From naoto at openjdk.org  Thu Aug 25 20:40:00 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Aug 2022 20:40:00 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <vmc1EvFEQfa4MgaDPRK4stt9c283CAZalywVmx6Ph6c=.ce84ed14-8986-49fa-87ca-79a1843533f4@github.com>

On Tue, 23 Aug 2022 22:44:13 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Thanks, Stuart. I will update the CSR as you suggested.
I found a couple of failures with the JCK tests. Will update the PR along with your suggestions.

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

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

From naoto at openjdk.org  Thu Aug 25 20:40:02 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 25 Aug 2022 20:40:02 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator
In-Reply-To: <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <OD_tsnO3whqFwuRZlFmhKfQaEqfnIhlQmSfNss8pFzc=.1e73384e-9f85-4acd-90d8-c1b0817ced0e@github.com>
Message-ID: <C_0WLb81K_nI3YtKEcmeGpO_1uAXdGA9r7DbKcUpXA8=.5bf873f2-3a44-484e-a209-7eb1f062ab36@github.com>

On Thu, 25 Aug 2022 03:52:48 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> src/java.base/share/classes/sun/util/locale/provider/BreakIteratorProviderImpl.java line 258:
> 
>> 256:                     .filter(i -> boundaries.get(i) > offset)
>> 257:                     .findFirst()
>> 258:                     .orElse(boundaries.size() - 1);
> 
> Is it worth trying to use Collections.binarySearch() here? I think the boundaries list is in ascending sorted order, so you might be able to drop in a binarySearch() call directly. (Need to be a bit careful with negative return values.)

Will replace this with `Collections.binarySearch()`.

> test/jdk/java/util/regex/whitebox/GraphemeTest.java line 30:
> 
>> 28:  * @library /lib/testlibrary/java/lang
>> 29:  * @compile --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest.java
>> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.util.regex=ALL-UNNAMED --add-opens java.base/jdk.internal.util.regex=ALL-UNNAMED GraphemeTest
> 
> Can you use the `@modules` directive to export+open the internal module to the test?

Good point. Will use `@modules` tag.

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

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

From itakiguchi at openjdk.org  Fri Aug 26 07:19:04 2022
From: itakiguchi at openjdk.org (Ichiroh Takiguchi)
Date: Fri, 26 Aug 2022 07:19:04 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
 <dPS95S9_mDJfE4tPBMTJJ1mDHPCByfqZoRZga5OHo2o=.30bbd8f0-c76e-4ef6-8bdb-6c60a10f4515@github.com>
 <6YYa4t3fubjt79BqFSmZ6N-_KfD75m56Pxr3Da_08Lg=.7cbf3637-bcfe-4ba5-a88f-f20ea7597042@github.com>
 <9dHSNyY4t5qmb9LBhB9sf3AJ-Ci_ZAA5gb1djiW9B5U=.0410f7d2-4815-486c-b889-27bbdad7f5ef@github.com>
 <E2w2-75T72nr_Mtb5p_byI6Zr4vrhPRfhkhUHFaXt4Y=.db0da9f5-701e-43d2-93df-329d6c8b8b7d@github.com>
Message-ID: <0G_XHad3feSdDSGvK33fsCcgu7pvG3BRDYI6AyfkqZs=.e6956cb6-3a1e-4007-bcd6-198e29ee7644@github.com>

On Mon, 8 Aug 2022 09:22:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hello @AlanBateman .
>> Sorry I'm late.
>> I got some responses from ICU. [ICU-22091](https://unicode-org.atlassian.net/browse/ICU-22091)
>> I'm not sure if they're interested in the new charset...
>> 
>> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage.
>> And some other performance advantages are there on built-in charset decoder/encoder.
>> Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes?
>> We'd like to use stable conversion loop.
>
>> As you know `sun.nio.cs.ArrayDecoder` and `sun.nio.cs.ArrayEncoder`interface have performance advantage. And some other performance advantages are there on built-in charset decoder/encoder. Is it possible to create simple public API by using `sun.nio.cs.SingleByte` and `sun.nio.cs.DoubleByte*` classes? We'd like to use stable conversion loop.
> 
> If they have ASCII compatible regions then that may be so but I haven't see any performance data published on that. Do you know if any experiments that have deployed a CharsetProvider for the EBCDIC charsets and compared the performance with the charsets that in the JDK? There may be merit in exploring adding base abstracts implementations of CharsetEncoder/CharsetDecoder to java.nio.charsets.spi to support single and double byte charsets to see how such base implementations might look, how they would help performance, and if there are any security downsides.

Hello @AlanBateman .
Sorry, I'm late.
Test result is attached (not guaranteed).

I created attached small test program, I'm not sure it's good or not

import java.nio.*;
import java.nio.charset.*;

public class tc {
  public static void main(String[] args) throws Exception {
    Charset cs = Charset.forName(args[0]);
    int cnt = Integer.parseInt(args[1]);
    boolean useCA = "1".equals(args[2]);
    boolean useBA = "1".equals(args[3]);
    CharsetEncoder ce = cs.newEncoder();
    byte[] ba = new byte[0x4000];
    for(int i = 0; i < ba.length; i++) {
      ba[i] = (byte) i;
    }
    String s = new String(ba, cs);
    char[] ca = s.toCharArray();
    ByteBuffer bb = useBA ? ByteBuffer.allocate(ca.length) : ByteBuffer.allocateDirect(ca.length);;
    CharBuffer cb = useCA ? CharBuffer.wrap(ca) : CharBuffer.wrap(s);
    System.out.println("CharBuffer.hasArray() = " + cb.hasArray());
    System.out.println("ByteBuffer.hasArray() = " + bb.hasArray());
    long start_t = System.currentTimeMillis();
    for(int i = 0; i < 200; i++) {
      ce.reset();
      bb.position(0);
      cb.position(0);
      ce.encode(cb, bb, true);
    }
    System.out.println("Warmup: "+(System.currentTimeMillis() - start_t));
    start_t = System.currentTimeMillis();
    for(int i = 0; i < cnt; i++) {
      ce.reset();
      bb.position(0);
      cb.position(0);
      ce.encode(cb, bb, true);
    }
    System.out.println("Test: "+(System.currentTimeMillis() - start_t));
  }
}


Following test result is just for my test environment
* CPU: Intel (On-premises environment), not same machine
* Executed 5 times, the values are their average 

Use following options, like
OpenJDK:
`java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1`
ICU4J
`java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`

I used jdk-20 b12
Only A/A with OpenJDK uses ArrayEncoder (ArrayDecoder) interface

| | A/A | A/B | B/A | B/B |
| -- | --: | --: | --: | --: |
| Linux (OpenJDK) | 862 | 1265 | 1838 | 1843 |
| Linux (ICU4J) | 1450 | 1410 | 1152 | 1138 |
| Windows (OpenJDK) | 921 | 1231 | 1959 | 1850 |
| Windows (ICU4J) | 1431 | 1446 | 2227 | 2265 |
| Mac (OpenJDK) | 820 | 1163 | 1799 | 1774 |
| Mac (ICU4J) | 1282 | 1242 | 994 | 1049 |

Notes:
* A/A means CharBuffer is created via char[], ByteBuffer is generated by allocate()
* A/B means CharBuffer is created via char[], ByteBuffer is generated by allocateDirect()
* B/A means CharBuffer is created via String, ByteBuffer is generated by allocate()
* B/B means CharBuffer is created via String, ByteBuffer is generated by allocateDirect()

Actually, I'm confused by this result.
Previously, I was just comparing A/A with B/B on OpenJDK's charset.
I didn't think ICU4J's result would make a difference.

Anyway, please evaluate about this result.
And please let me know if I need more investigation.

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

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

From alanb at openjdk.org  Fri Aug 26 09:28:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 09:28:07 GMT
Subject: <i18n dev> RFR: 8289834: Add SBCS and DBCS Only EBCDIC charsets
In-Reply-To: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
References: <A4o9Xs0AXKvAkccg6NnjGc78VXeVAyluqDr1kacA57g=.7ca3abbc-87f0-47e8-9c34-1c3dd390240b@github.com>
Message-ID: <LGD-fiueNpTP8_1CwFf54JPt1o44S1lM0iMGbB4LiK8=.896fea2f-158e-4c9a-83f4-4394e2ff1789@github.com>

On Wed, 6 Jul 2022 14:05:39 GMT, Ichiroh Takiguchi <itakiguchi at openjdk.org> wrote:

> OpenJDK supports "Japanese EBCDIC - Katakana" and "Korean EBCDIC" SBCS and DBCS Only charsets.
> |Charset|Mix|SBCS|DBCS|
> | -- | -- | -- | -- |
> | Japanese EBCDIC - Katakana | Cp930 | Cp290 | Cp300 |
> | Korean | Cp933 | Cp833 | Cp834 |
> 
> But OpenJDK does not supports some of "Japanese EBCDIC - English" / "Simplified Chinese EBCDIC" / "Traditional Chinese EBCDIC" SBCS and DBCS Only charsets.
> 
> I'd like to request Cp1027/Cp835/Cp836/Cp837 for consistency
> |Charset|Mix|SBCS|DBCS|
> | ------------- | ------------- | ------------- | ------------- |
> | Japanese EBCDIC - English | Cp939 | **Cp1027** | Cp300 |
> | Simplified Chinese EBCDIC | Cp935 | **Cp836** | **Cp837** |
> | Traditional Chinese EBCDIC | Cp937 | (*1) | **Cp835** | 
> 
> *1: Cp037 compatible

> Use following options, like OpenJDK: `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047 20000 1 1` ICU4J `java -cp icu4j-71_1.jar:icu4j-charset-71_1.jar:. tc IBM-1047_P100-1995 20000 1 1`
> 
> Actually, I'm confused by this result. Previously, I was just comparing A/A with B/B on OpenJDK's charset. I didn't think ICU4J's result would make a difference.

My initial reaction is one of relief that the icu4j provider can be used with current JDK builds. This means there is an option should we decide to stop adding more EBCDIC charsets to the JDK.

The test uses IBM-1047 and I can't tell if the icu4j provider is used or not. Charset doesn't define a provider method but I think would be useful to print cs.getClass() or cs.getClass().getModule() so we know which Charset implementation is used. Also I think any discussion on performance would be better served with a JMH benchmark rather than a standalone test.

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

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

From naoto at openjdk.org  Fri Aug 26 16:39:28 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 16:39:28 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v2]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <hvxSaidNZEdjHcXgcw_Mb5GaZ2UzKWGPBK2W8Jaf9bU=.35e52112-2833-4503-b50f-ea9a09caf7ce@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

Naoto Sato has updated the pull request incrementally with two additional commits since the last revision:

 - Fixing JCK failures
 - Addressing review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/6396eefa..a772c3a1

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

  Stats: 69 lines in 5 files changed: 28 ins; 12 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/9991.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9991/head:pull/9991

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

From naoto at openjdk.org  Fri Aug 26 18:12:04 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 18:12:04 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

  Reverting the fix to BreakIterator.isBoundary()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/a772c3a1..d2608451

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

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

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

From naoto at openjdk.org  Fri Aug 26 18:27:57 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 18:27:57 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
Message-ID: <3U41Hgu9ciWVjRgUekZs2Aeiu3tnJo7DFnT9ijwDyUM=.1ad6fd66-4e11-450a-84e9-668fc84546a7@github.com>

On Fri, 26 Aug 2022 18:12:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting the fix to BreakIterator.isBoundary()

Modified the fix according to suggestions. Also, the CSR has been updated and a release note has been drafted.

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

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

From smarks at openjdk.org  Fri Aug 26 21:00:55 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 26 Aug 2022 21:00:55 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
Message-ID: <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>

On Fri, 26 Aug 2022 18:12:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reverting the fix to BreakIterator.isBoundary()

src/java.base/share/classes/java/text/BreakIterator.java line 107:

> 105:  * <a href="https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries">
> 106:  * Grapheme Cluster Boundaries</a> section in the Unicode Standard Annex #29.
> 107:  *

I would say this is an `@implSpec` instead of an `@implNote` because we want applications to be able to rely on this behavior if they're using the default implementation. Also please make corresponding update to the CSR.

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

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

From naoto at openjdk.org  Fri Aug 26 21:48:14 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 21:48:14 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v4]
In-Reply-To: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
Message-ID: <gMCB2FydC8HN9bhgEhD_rgJ8nYsH4jbdrwxBf6nV70I=.6200e629-b5e3-4f53-936d-a2b9669daeb3@github.com>

> This is to enhance the character break analysis in `java.text.BreakIterator` to conform to the extended grapheme cluster boundaries defined in https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries. A corresponding CSR has also been drafted, as there will be behavioral changes with this modification.

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

  Changed the paragraph to @implSpec

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9991/files
  - new: https://git.openjdk.org/jdk/pull/9991/files/d2608451..06cfc222

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

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

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

From naoto at openjdk.org  Fri Aug 26 21:48:15 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 26 Aug 2022 21:48:15 GMT
Subject: <i18n dev> RFR: 8291660: Grapheme support in BreakIterator [v3]
In-Reply-To: <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>
References: <PAxeyBr2SARDXG1xnzL7mGAFWAlirlGE3XsqHnHSMyc=.8f24f0b1-2664-4722-8b85-1d617b41ce30@github.com>
 <vUllDh014V60guctnt7BLdhdmvkFaavtmk0RsoRMbnQ=.6205e328-0cef-4f74-ae35-9285b502963e@github.com>
 <51daFZs3iSevVCgEiCPw3lUydTORVgE2R7K2UgSJBvc=.8bd99bfa-8875-4894-8c48-1cc88717e973@github.com>
Message-ID: <EK5-OSVqB_5OwiytXkuQaEWcb-Pxe9P2TuHFwREsopM=.c21800d3-6e8c-4b46-af12-2a82a38734d0@github.com>

On Fri, 26 Aug 2022 20:57:05 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reverting the fix to BreakIterator.isBoundary()
>
> src/java.base/share/classes/java/text/BreakIterator.java line 107:
> 
>> 105:  * <a href="https://www.unicode.org/reports/tr29/#Grapheme_Cluster_Boundaries">
>> 106:  * Grapheme Cluster Boundaries</a> section in the Unicode Standard Annex #29.
>> 107:  *
> 
> I would say this is an `@implSpec` instead of an `@implNote` because we want applications to be able to rely on this behavior if they're using the default implementation. Also please make corresponding update to the CSR.

Fixed

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

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

From aturbanov at openjdk.org  Sun Aug 28 13:28:59 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 28 Aug 2022 13:28:59 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
Message-ID: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>

Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

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

Commit messages:
 - [PATCH] Replace uses of StringBuffer with StringBuilder in MergeCollation
 - [PATCH] Replace uses of StringBuffer with StringBuilder in MergeCollation

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

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

From aturbanov at openjdk.org  Sun Aug 28 13:31:07 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Sun, 28 Aug 2022 13:31:07 GMT
Subject: <i18n dev> RFR: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
Message-ID: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>

Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

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

Commit messages:
 - [PATCH] Unused field DateFormatSymbols.millisPerHour

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

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

From rriggs at openjdk.org  Mon Aug 29 15:11:07 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 29 Aug 2022 15:11:07 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <GVVK3Tj_cK5NHEyzCEz3XePjHGW_lDNyv4QFgNTb0mg=.a78167c9-6d07-4af5-9f66-4b2066c31984@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From naoto at openjdk.org  Mon Aug 29 16:26:06 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 16:26:06 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <aaY57G2PyolHTe5dVq4KW-VxL6mBtwzBxvxZQiJp2-E=.35662b31-612f-493b-929f-0563317236ab@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

+1

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

Marked as reviewed by naoto (Reviewer).

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

From naoto at openjdk.org  Mon Aug 29 16:41:11 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 16:41:11 GMT
Subject: <i18n dev> RFR: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <tHA8U4garyoiuBMtIU_f8Sl4fH03a_oMzUlKPR6X_QA=.cc0165f1-68d2-44fd-953f-193ed5c40f29@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

This looks good too.

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

Marked as reviewed by naoto (Reviewer).

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

From bpb at openjdk.org  Mon Aug 29 16:49:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 29 Aug 2022 16:49:16 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <zQusT2LbybrbZ36KOE1z4j9ueiwti1WA0HNUO2XRucI=.49b8d943-28ef-4926-a9a0-e093b9ebc492@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

Marked as reviewed by bpb (Reviewer).

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

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

From naoto at openjdk.org  Mon Aug 29 21:41:20 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 29 Aug 2022 21:41:20 GMT
Subject: <i18n dev> Withdrawn: 8289227: Support for BCP 47 Extension T -
 Transformed Content
In-Reply-To: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
References: <EXawql3Ndy2lEbLZKcV48an5FTKd0gWqYiWqe7xYie0=.db71e901-2c76-4f66-9a90-e452daf36982@github.com>
Message-ID: <73N1yjCvoMAXDZtFx04iOz09jCXxuKoNlNDpby8uxl0=.0e2867b9-3e58-4f32-a1b9-34f8e3997712@github.com>

On Fri, 22 Jul 2022 21:53:35 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> This PR is to propose supporting the `T` extension to the BCP 47 to which `java.util.Locale` class conforms. There are two extensions to the BCP 47, one is `Unicode Locale Extension` which has been supported since JDK7, the other is this `Transformed Content` extension. A CSR has also been drafted.

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Tue Aug 30 09:02:00 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:02:00 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

src/java.base/share/classes/java/text/PatternEntry.java line 55:

> 53:      * Gets the current extension, quoted
> 54:      */
> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {

Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?

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

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

From jpai at openjdk.org  Tue Aug 30 09:04:12 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 30 Aug 2022 09:04:12 GMT
Subject: <i18n dev> RFR: 8293009: Remove unused field 'millisPerHour' in
 DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <vY_BUsk7ZsGe4ZMtRpJ_gUjV6i3con5CfdZq0xiR9hk=.ea8da569-04e6-4748-baa1-6a0d0050479b@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

Marked as reviewed by jpai (Reviewer).

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

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

From aturbanov at openjdk.org  Tue Aug 30 17:34:11 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 30 Aug 2022 17:34:11 GMT
Subject: <i18n dev> Integrated: 8293009: Remove unused field 'millisPerHour'
 in DateFormatSymbols
In-Reply-To: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
References: <iaqp02xUBKKGh8Re80MFNHBj4xiM_3PDcH9w49ctsyk=.e2c45351-3ca0-46fc-aba6-ac0b538acbe0@github.com>
Message-ID: <CoKzSrLF8f6z5GSpOqtJwwcS51FNEdqbHIPq8xFs21U=.84718ad4-a64f-480b-872b-2c49b270b47f@github.com>

On Wed, 24 Aug 2022 19:22:51 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Field `java.text.DateFormatSymbols#millisPerHour` is unused. It was unused in initial OpenJDK sources.

This pull request has now been integrated.

Changeset: d3d2e669
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3d2e669b7bdfbd91cab7b918bc62cf1879cc95b
Stats:     6 lines in 1 file changed: 0 ins; 5 del; 1 mod

8293009: Remove unused field 'millisPerHour' in DateFormatSymbols

Reviewed-by: naoto, jpai

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

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

From aturbanov at openjdk.org  Wed Aug 31 08:46:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 08:46:32 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation [v2]
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

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

  8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
  
  use private for methods which changed signature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10007/files
  - new: https://git.openjdk.org/jdk/pull/10007/files/a53bcac0..e85e3c34

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

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

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

From aturbanov at openjdk.org  Wed Aug 31 08:46:32 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 08:46:32 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation [v2]
In-Reply-To: <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <S-iuHneomZKuiz0qOIBcdl-GBTXQEs0W0k2tmdcooN4=.00ac5745-2628-4084-aba2-e6d2e449b9d4@github.com>
Message-ID: <Hv1r0u6eG8WTefw4fMJOQ9s8_OQf_REWuIS6Fo9lPcI=.490e6586-bc2b-418a-93b9-61b5e7081ede@github.com>

On Tue, 30 Aug 2022 08:58:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>>   
>>   use private for methods which changed signature
>
> src/java.base/share/classes/java/text/PatternEntry.java line 55:
> 
>> 53:      * Gets the current extension, quoted
>> 54:      */
>> 55:     public void appendQuotedExtension(StringBuilder toAddTo) {
> 
> Hello Andrey, this and the other `public` method that's changed in this (package private) class don't seem to be used anywhere else other than this class itself. So maybe you could change them to `private` as part of this change?

Changed a few of methods to `private`

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

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

From rriggs at openjdk.org  Wed Aug 31 13:34:23 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 Aug 2022 13:34:23 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation [v2]
In-Reply-To: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
Message-ID: <9hhJhKV_ZZHpLSbWcewBI-3VrkZPQyiue94UJvsiqR0=.278656fb-0770-4b34-931c-435384d2b009@github.com>

On Wed, 31 Aug 2022 08:46:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
>> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>   
>   use private for methods which changed signature

Marked as reviewed by rriggs (Reviewer).

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

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

From aturbanov at openjdk.org  Wed Aug 31 14:00:33 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 14:00:33 GMT
Subject: <i18n dev> RFR: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation [v2]
In-Reply-To: <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
 <OPfJXAJK6gK8RwEkrvoUve2ZeJhOZx0FfFY4UmFK-48=.38548d7b-8afb-4701-a87e-10aa16b8eb0d@github.com>
Message-ID: <9J9DTL4GgD0jgjeYTMii-8cWRpeRe6KfQaNlPr6jUVM=.7043c1a3-c89f-42be-91cf-7f30c3e18b7f@github.com>

On Wed, 31 Aug 2022 08:46:32 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
>> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation
>   
>   use private for methods which changed signature

Thank you for review!

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

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

From aturbanov at openjdk.org  Wed Aug 31 14:00:34 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 31 Aug 2022 14:00:34 GMT
Subject: <i18n dev> Integrated: 8293008: Replace uses of StringBuffer with
 StringBuilder in MergeCollation
In-Reply-To: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
References: <xd8CMsCBvuQT6uJHCsO1DF6yNs3ZY6BB1Y-Fs82F1as=.98656fc5-e52d-4fa3-8e7d-3150d4b154ff@github.com>
Message-ID: <e-eO9kJOLT264V9HoTRg4XeFR-pCT9t4AXGzdxxJSAo=.a1e0a9fa-d696-4959-bce5-d0f12fb80f66@github.com>

On Wed, 24 Aug 2022 19:31:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Couple of package-private classes in `java.text` package still use `StringBuffer`: `MergeCollation` and `PatternEntry`.
> StringBuffer is a legacy synchronized class. StringBuilder is a direct replacement to StringBuffer which generally have better performance.

This pull request has now been integrated.

Changeset: 0d51f63a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0d51f63a2e95976636f8ec74a69096791304724e
Stats:     9 lines in 2 files changed: 0 ins; 0 del; 9 mod

8293008: Replace uses of StringBuffer with StringBuilder in MergeCollation

Reviewed-by: rriggs, naoto, bpb

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

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

From naoto at openjdk.org  Wed Aug 31 17:14:59 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 31 Aug 2022 17:14:59 GMT
Subject: <i18n dev> RFR: 8293154: TemporalQueries java doc error
Message-ID: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>

Simple doc fix.

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

Commit messages:
 - 8293154: TemporalQueries java doc error

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

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

From rriggs at openjdk.org  Wed Aug 31 17:22:05 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 31 Aug 2022 17:22:05 GMT
Subject: <i18n dev> RFR: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <l1aJ3rjZ6DL5WTYCLz-xWVW9wv--_DCqnyhcZ2nWtm4=.4ac9b4a9-e6ad-4402-a295-19e5d58742ba@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by rriggs (Reviewer).

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

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

From lancea at openjdk.org  Wed Aug 31 17:26:07 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 31 Aug 2022 17:26:07 GMT
Subject: <i18n dev> RFR: 8293154: TemporalQueries java doc error
In-Reply-To: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
References: <vfGW9kmfaPQ8dxueJKopIwNonzfqYl21UUYzDMRyPL8=.fd1aeab4-2367-4177-a61b-f65c7d4d9c5d@github.com>
Message-ID: <A65eUqBfQSXAiyQvpWO4TqZ-8dU4Vv1SqZwdczNr_d8=.55115dff-8393-4ed8-bbb7-c426fe3c11e9@github.com>

On Wed, 31 Aug 2022 17:08:28 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Simple doc fix.

Marked as reviewed by lancea (Reviewer).

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

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