From suenaga at oss.nttdata.com  Sun Feb  2 16:33:25 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Sun, 2 Feb 2020 17:33:25 +0100
Subject: <i18n dev> RFR: 8238203: Return value of
 GetUserDefaultUILanguage() should be handled as LANGID
In-Reply-To: <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
 <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
Message-ID: <51cfbcd7-28a9-b4d8-5794-9f7120764163@oss.nttdata.com>

Hi all,

Could you review this change?

>    JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>    webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/

This webrev has been reviewed by Naoto.
I need one more reviewer to push.


Thanks,

Yasumasa


On 2020/01/30 4:36, Yasumasa Suenaga wrote:
> Hi Sato-san,
> 
> I filed it to JBS, and create webrev.
> Could you review it?
> 
>  ? JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>  ? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2020/01/30 3:15, naoto.sato at oracle.com wrote:
>> Hi Suenaga-san,
>>
>> I think your fix looks reasonable. Although currently sort id is not being used, I'd replace 'SORT_DEFAULT' with 'SORTIDFROMLCID(userDefaultLCID)', which is more of a correct usage.
>>
>> Naoto
>>
>> On 1/28/20 11:51 PM, Yasumasa Suenaga wrote:
>>> Hi all,
>>>
>>> I checked how JDK detects default language on Windows, but I cannot understand the code
>>> in below:
>>>
>>> src/java.base/windows/native/libjava/java_props_md.c:
>>> ```
>>> LCID userDefaultUILang = GetUserDefaultUILanguage();
>>> ```
>>>
>>> According to MSDN [1], GetUserDefaultUILanguage() returns LANGID.
>>> `userDefaultUILang` is used later as LCID. I think it is wrong.
>>>
>>> I think we should be fix it as below.
>>> If it is correct, I will file it to JBS and will send webrev.
>>>
>>> ```
>>> diff --git a/src/java.base/windows/native/libjava/java_props_md.c b/src/java.base/windows/native/libjava/java_props_md.cindex 231f44ce2b..9068595dcf 100644
>>> --- a/src/java.base/windows/native/libjava/java_props_md.c
>>> +++ b/src/java.base/windows/native/libjava/java_props_md.c
>>> @@ -641,7 +641,7 @@ GetJavaProperties(JNIEnv* env)
>>> ?????????? */
>>> ????????? LCID userDefaultLCID = GetUserDefaultLCID();
>>> ????????? LCID systemDefaultLCID = GetSystemDefaultLCID();
>>> -??????? LCID userDefaultUILang = GetUserDefaultUILanguage();
>>> +??????? LANGID userDefaultUILang = GetUserDefaultUILanguage();
>>>
>>> ????????? {
>>> ????????????? char * display_encoding;
>>> @@ -655,8 +655,8 @@ GetJavaProperties(JNIEnv* env)
>>> ????????????? // for the UI Language, if the "language" portion of those
>>> ????????????? // two locales are the same.
>>> ????????????? if (PRIMARYLANGID(LANGIDFROMLCID(userDefaultLCID)) ==
>>> -??????????????? PRIMARYLANGID(LANGIDFROMLCID(userDefaultUILang))) {
>>> -??????????????? userDefaultUILang = userDefaultLCID;
>>> +??????????????? PRIMARYLANGID(userDefaultUILang)) {
>>> +??????????????? userDefaultUILang = LANGIDFROMLCID(userDefaultLCID);
>>> ????????????? }
>>>
>>> ????????????? SetupI18nProps(userDefaultLCID,
>>> @@ -665,7 +665,7 @@ GetJavaProperties(JNIEnv* env)
>>> ???????????????????????????? &sprops.format_country,
>>> ???????????????????????????? &sprops.format_variant,
>>> ???????????????????????????? &sprops.encoding);
>>> -??????????? SetupI18nProps(userDefaultUILang,
>>> +??????????? SetupI18nProps(MAKELCID(userDefaultUILang, SORT_DEFAULT),
>>> ???????????????????????????? &sprops.display_language,
>>> ???????????????????????????? &sprops.display_script,
>>> ???????????????????????????? &sprops.display_country,
>>> ```
>>>
>>> Do you have any comments / suggestions?
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> [1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultuilanguage

From naoto.sato at oracle.com  Sun Feb  2 17:13:51 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Sun, 2 Feb 2020 09:13:51 -0800
Subject: <i18n dev> RFR: 8238203: Return value of
 GetUserDefaultUILanguage() should be handled as LANGID
In-Reply-To: <51cfbcd7-28a9-b4d8-5794-9f7120764163@oss.nttdata.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
 <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
 <51cfbcd7-28a9-b4d8-5794-9f7120764163@oss.nttdata.com>
Message-ID: <567e0077-8aea-23a6-da10-90eeb884cd61@oracle.com>

You can go ahead and push the changeset, as there's no strict rule to 
have two reviewers in core-libs area.

Naoto

On 2/2/20 8:33 AM, Yasumasa Suenaga wrote:
> Hi all,
> 
> Could you review this change?
> 
>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/
> 
> This webrev has been reviewed by Naoto.
> I need one more reviewer to push.
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> On 2020/01/30 4:36, Yasumasa Suenaga wrote:
>> Hi Sato-san,
>>
>> I filed it to JBS, and create webrev.
>> Could you review it?
>>
>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2020/01/30 3:15, naoto.sato at oracle.com wrote:
>>> Hi Suenaga-san,
>>>
>>> I think your fix looks reasonable. Although currently sort id is not 
>>> being used, I'd replace 'SORT_DEFAULT' with 
>>> 'SORTIDFROMLCID(userDefaultLCID)', which is more of a correct usage.
>>>
>>> Naoto
>>>
>>> On 1/28/20 11:51 PM, Yasumasa Suenaga wrote:
>>>> Hi all,
>>>>
>>>> I checked how JDK detects default language on Windows, but I cannot 
>>>> understand the code
>>>> in below:
>>>>
>>>> src/java.base/windows/native/libjava/java_props_md.c:
>>>> ```
>>>> LCID userDefaultUILang = GetUserDefaultUILanguage();
>>>> ```
>>>>
>>>> According to MSDN [1], GetUserDefaultUILanguage() returns LANGID.
>>>> `userDefaultUILang` is used later as LCID. I think it is wrong.
>>>>
>>>> I think we should be fix it as below.
>>>> If it is correct, I will file it to JBS and will send webrev.
>>>>
>>>> ```
>>>> diff --git a/src/java.base/windows/native/libjava/java_props_md.c 
>>>> b/src/java.base/windows/native/libjava/java_props_md.cindex 
>>>> 231f44ce2b..9068595dcf 100644
>>>> --- a/src/java.base/windows/native/libjava/java_props_md.c
>>>> +++ b/src/java.base/windows/native/libjava/java_props_md.c
>>>> @@ -641,7 +641,7 @@ GetJavaProperties(JNIEnv* env)
>>>> ?????????? */
>>>> ????????? LCID userDefaultLCID = GetUserDefaultLCID();
>>>> ????????? LCID systemDefaultLCID = GetSystemDefaultLCID();
>>>> -??????? LCID userDefaultUILang = GetUserDefaultUILanguage();
>>>> +??????? LANGID userDefaultUILang = GetUserDefaultUILanguage();
>>>>
>>>> ????????? {
>>>> ????????????? char * display_encoding;
>>>> @@ -655,8 +655,8 @@ GetJavaProperties(JNIEnv* env)
>>>> ????????????? // for the UI Language, if the "language" portion of 
>>>> those
>>>> ????????????? // two locales are the same.
>>>> ????????????? if (PRIMARYLANGID(LANGIDFROMLCID(userDefaultLCID)) ==
>>>> -??????????????? PRIMARYLANGID(LANGIDFROMLCID(userDefaultUILang))) {
>>>> -??????????????? userDefaultUILang = userDefaultLCID;
>>>> +??????????????? PRIMARYLANGID(userDefaultUILang)) {
>>>> +??????????????? userDefaultUILang = LANGIDFROMLCID(userDefaultLCID);
>>>> ????????????? }
>>>>
>>>> ????????????? SetupI18nProps(userDefaultLCID,
>>>> @@ -665,7 +665,7 @@ GetJavaProperties(JNIEnv* env)
>>>> ???????????????????????????? &sprops.format_country,
>>>> ???????????????????????????? &sprops.format_variant,
>>>> ???????????????????????????? &sprops.encoding);
>>>> -??????????? SetupI18nProps(userDefaultUILang,
>>>> +??????????? SetupI18nProps(MAKELCID(userDefaultUILang, SORT_DEFAULT),
>>>> ???????????????????????????? &sprops.display_language,
>>>> ???????????????????????????? &sprops.display_script,
>>>> ???????????????????????????? &sprops.display_country,
>>>> ```
>>>>
>>>> Do you have any comments / suggestions?
>>>>
>>>>
>>>> Thanks,
>>>>
>>>> Yasumasa
>>>>
>>>>
>>>> [1] 
>>>> https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultuilanguage 
>>>>

From suenaga at oss.nttdata.com  Sun Feb  2 17:19:24 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Sun, 2 Feb 2020 18:19:24 +0100
Subject: <i18n dev> RFR: 8238203: Return value of
 GetUserDefaultUILanguage() should be handled as LANGID
In-Reply-To: <567e0077-8aea-23a6-da10-90eeb884cd61@oracle.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
 <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
 <51cfbcd7-28a9-b4d8-5794-9f7120764163@oss.nttdata.com>
 <567e0077-8aea-23a6-da10-90eeb884cd61@oracle.com>
Message-ID: <ec2698f1-d3b9-2375-671c-2f3c5151fdcc@oss.nttdata.com>

Thanks, I will push it.

Yasumasa

On 2020/02/02 18:13, naoto.sato at oracle.com wrote:
> You can go ahead and push the changeset, as there's no strict rule to have two reviewers in core-libs area.
> 
> Naoto
> 
> On 2/2/20 8:33 AM, Yasumasa Suenaga wrote:
>> Hi all,
>>
>> Could you review this change?
>>
>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/
>>
>> This webrev has been reviewed by Naoto.
>> I need one more reviewer to push.
>>
>>
>> Thanks,
>>
>> Yasumasa
>>
>>
>> On 2020/01/30 4:36, Yasumasa Suenaga wrote:
>>> Hi Sato-san,
>>>
>>> I filed it to JBS, and create webrev.
>>> Could you review it?
>>>
>>> ?? JBS: https://bugs.openjdk.java.net/browse/JDK-8238203
>>> ?? webrev: http://cr.openjdk.java.net/~ysuenaga/JDK-8238203/webrev.00/
>>>
>>>
>>> Thanks,
>>>
>>> Yasumasa
>>>
>>>
>>> On 2020/01/30 3:15, naoto.sato at oracle.com wrote:
>>>> Hi Suenaga-san,
>>>>
>>>> I think your fix looks reasonable. Although currently sort id is not being used, I'd replace 'SORT_DEFAULT' with 'SORTIDFROMLCID(userDefaultLCID)', which is more of a correct usage.
>>>>
>>>> Naoto
>>>>
>>>> On 1/28/20 11:51 PM, Yasumasa Suenaga wrote:
>>>>> Hi all,
>>>>>
>>>>> I checked how JDK detects default language on Windows, but I cannot understand the code
>>>>> in below:
>>>>>
>>>>> src/java.base/windows/native/libjava/java_props_md.c:
>>>>> ```
>>>>> LCID userDefaultUILang = GetUserDefaultUILanguage();
>>>>> ```
>>>>>
>>>>> According to MSDN [1], GetUserDefaultUILanguage() returns LANGID.
>>>>> `userDefaultUILang` is used later as LCID. I think it is wrong.
>>>>>
>>>>> I think we should be fix it as below.
>>>>> If it is correct, I will file it to JBS and will send webrev.
>>>>>
>>>>> ```
>>>>> diff --git a/src/java.base/windows/native/libjava/java_props_md.c b/src/java.base/windows/native/libjava/java_props_md.cindex 231f44ce2b..9068595dcf 100644
>>>>> --- a/src/java.base/windows/native/libjava/java_props_md.c
>>>>> +++ b/src/java.base/windows/native/libjava/java_props_md.c
>>>>> @@ -641,7 +641,7 @@ GetJavaProperties(JNIEnv* env)
>>>>> ?????????? */
>>>>> ????????? LCID userDefaultLCID = GetUserDefaultLCID();
>>>>> ????????? LCID systemDefaultLCID = GetSystemDefaultLCID();
>>>>> -??????? LCID userDefaultUILang = GetUserDefaultUILanguage();
>>>>> +??????? LANGID userDefaultUILang = GetUserDefaultUILanguage();
>>>>>
>>>>> ????????? {
>>>>> ????????????? char * display_encoding;
>>>>> @@ -655,8 +655,8 @@ GetJavaProperties(JNIEnv* env)
>>>>> ????????????? // for the UI Language, if the "language" portion of those
>>>>> ????????????? // two locales are the same.
>>>>> ????????????? if (PRIMARYLANGID(LANGIDFROMLCID(userDefaultLCID)) ==
>>>>> -??????????????? PRIMARYLANGID(LANGIDFROMLCID(userDefaultUILang))) {
>>>>> -??????????????? userDefaultUILang = userDefaultLCID;
>>>>> +??????????????? PRIMARYLANGID(userDefaultUILang)) {
>>>>> +??????????????? userDefaultUILang = LANGIDFROMLCID(userDefaultLCID);
>>>>> ????????????? }
>>>>>
>>>>> ????????????? SetupI18nProps(userDefaultLCID,
>>>>> @@ -665,7 +665,7 @@ GetJavaProperties(JNIEnv* env)
>>>>> ???????????????????????????? &sprops.format_country,
>>>>> ???????????????????????????? &sprops.format_variant,
>>>>> ???????????????????????????? &sprops.encoding);
>>>>> -??????????? SetupI18nProps(userDefaultUILang,
>>>>> +??????????? SetupI18nProps(MAKELCID(userDefaultUILang, SORT_DEFAULT),
>>>>> ???????????????????????????? &sprops.display_language,
>>>>> ???????????????????????????? &sprops.display_script,
>>>>> ???????????????????????????? &sprops.display_country,
>>>>> ```
>>>>>
>>>>> Do you have any comments / suggestions?
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Yasumasa
>>>>>
>>>>>
>>>>> [1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultuilanguage

From takiguc at linux.vnet.ibm.com  Tue Feb  4 16:23:20 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 05 Feb 2020 01:23:20 +0900
Subject: <i18n dev> RFR: CSR JDK-8233385 Align some one-way conversion
 in MS950 charset with Windows
In-Reply-To: <5c110af7-15de-dce1-5396-0a1b96bf5221@oracle.com>
References: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
 <ba86d6af16dc9328550e3a6b1b4758cb@linux.vnet.ibm.com>
 <5c110af7-15de-dce1-5396-0a1b96bf5221@oracle.com>
Message-ID: <460aabc41d1bc0b46cd382dcd0f09dec@linux.vnet.ibm.com>

Hello.

This is reminder, again.

Could you review CSR JDK-8233385 [1] ?

[1] https://bugs.openjdk.java.net/browse/JDK-8233385

Thanks,
Ichiroh Takiguchi

On 2020-01-22 02:47, naoto.sato at oracle.com wrote:
> Looks good to me.
> 
> Naoto
> 
> On 1/20/20 4:30 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> This is just a gentle reminder.
>> 
>> Could you review CSR JDK-8233385 [1] ?
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
>>> Hello.
>>> 
>>> Could you review CSR JDK-8233385 [1] ?
>>> 
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
>>> 
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Thu Feb  6 16:50:47 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 6 Feb 2020 08:50:47 -0800
Subject: <i18n dev> [14] RFR (XXS) 8238605: Correct the CLDR version number
 in cldr.md files
Message-ID: <522d7249-749f-1986-5f2a-48861bb57278@oracle.com>

Hello,

Please review this extra small fix for this issue:

https://bugs.openjdk.java.net/browse/JDK-8238605

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8238605/webrev.00/

It is simply updating the version number in cldr.md files, which should 
have been done with JDK-8231273.

Naoto

From huizhe.wang at oracle.com  Thu Feb  6 17:40:18 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 6 Feb 2020 09:40:18 -0800
Subject: <i18n dev> [14] RFR (XXS) 8238605: Correct the CLDR version
 number in cldr.md files
In-Reply-To: <522d7249-749f-1986-5f2a-48861bb57278@oracle.com>
References: <522d7249-749f-1986-5f2a-48861bb57278@oracle.com>
Message-ID: <ccab48f0-0bcf-2cf4-4565-4883c6ad6aef@oracle.com>

+1

Best,
Joe


On 2/6/20 8:50 AM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review this extra small fix for this issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8238605
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8238605/webrev.00/
>
> It is simply updating the version number in cldr.md files, which 
> should have been done with JDK-8231273.
>
> Naoto


From Alan.Bateman at oracle.com  Thu Feb  6 17:54:17 2020
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 6 Feb 2020 17:54:17 +0000
Subject: <i18n dev> [14] RFR (XXS) 8238605: Correct the CLDR version
 number in cldr.md files
In-Reply-To: <522d7249-749f-1986-5f2a-48861bb57278@oracle.com>
References: <522d7249-749f-1986-5f2a-48861bb57278@oracle.com>
Message-ID: <49457234-02ca-86a9-07ff-d186b6a0acbf@oracle.com>

On 06/02/2020 16:50, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review this extra small fix for this issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8238605
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8238605/webrev.00/
>
> It is simply updating the version number in cldr.md files, which 
> should have been done with JDK-8231273.
This seems to be a "must-fix" to the license file so I think it's okay.

-Alan

From naoto.sato at oracle.com  Fri Feb  7 21:44:17 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 7 Feb 2020 13:44:17 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
Message-ID: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>

Hello,

Please review the fix to the following issues:

https://bugs.openjdk.java.net/browse/JDK-8234347
https://bugs.openjdk.java.net/browse/JDK-8236548

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/

This changeset includes the following changes:

- English time zone names missing in CLDR source files are no longer 
copied from COMPAT provider at build time. Rather it is synthesized at 
runtime, which has been the way other locales did.

- Runtime CLDR time zone name provider fallback logic has been refined. 
It now falls back to parent locales per each missing name, instead of 
resource bundle. Also, region fall back is now using exemplar city to 
synthesize the name (e.g., "Turkey" meta zone)

- Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
parses zone texts that start with "UTC", yet it is ZoneId.

Naoto

From huizhe.wang at oracle.com  Sat Feb  8 02:00:10 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 7 Feb 2020 18:00:10 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
In-Reply-To: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
References: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
Message-ID: <a9de3ad2-55eb-99db-07f7-c5362d40e014@oracle.com>

Hi Naoto,

I see the existing tests were changed, e.g. the abbreviation / short 
timezone name, the result of calling getDisplayName. Would you need a 
CSR to discuss/document the potential incompatibility?

Best,
Joe

On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issues:
>
> https://bugs.openjdk.java.net/browse/JDK-8234347
> https://bugs.openjdk.java.net/browse/JDK-8236548
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
>
> This changeset includes the following changes:
>
> - English time zone names missing in CLDR source files are no longer 
> copied from COMPAT provider at build time. Rather it is synthesized at 
> runtime, which has been the way other locales did.
>
> - Runtime CLDR time zone name provider fallback logic has been 
> refined. It now falls back to parent locales per each missing name, 
> instead of resource bundle. Also, region fall back is now using 
> exemplar city to synthesize the name (e.g., "Turkey" meta zone)
>
> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
> parses zone texts that start with "UTC", yet it is ZoneId.
>
> Naoto


From naoto.sato at oracle.com  Mon Feb 10 16:52:10 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 10 Feb 2020 08:52:10 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
In-Reply-To: <a9de3ad2-55eb-99db-07f7-c5362d40e014@oracle.com>
References: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
 <a9de3ad2-55eb-99db-07f7-c5362d40e014@oracle.com>
Message-ID: <c611df01-2995-d253-5838-8d7d0215bdf8@oracle.com>

Good point. I will file a CSR for the behavioral changes.

Naoto

On 2/7/20 6:00 PM, Joe Wang wrote:
> Hi Naoto,
> 
> I see the existing tests were changed, e.g. the abbreviation / short 
> timezone name, the result of calling getDisplayName. Would you need a 
> CSR to discuss/document the potential incompatibility?
> 
> Best,
> Joe
> 
> On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8234347
>> https://bugs.openjdk.java.net/browse/JDK-8236548
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
>>
>> This changeset includes the following changes:
>>
>> - English time zone names missing in CLDR source files are no longer 
>> copied from COMPAT provider at build time. Rather it is synthesized at 
>> runtime, which has been the way other locales did.
>>
>> - Runtime CLDR time zone name provider fallback logic has been 
>> refined. It now falls back to parent locales per each missing name, 
>> instead of resource bundle. Also, region fall back is now using 
>> exemplar city to synthesize the name (e.g., "Turkey" meta zone)
>>
>> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
>> parses zone texts that start with "UTC", yet it is ZoneId.
>>
>> Naoto
> 

From naoto.sato at oracle.com  Mon Feb 10 22:45:48 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 10 Feb 2020 14:45:48 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
In-Reply-To: <c611df01-2995-d253-5838-8d7d0215bdf8@oracle.com>
References: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
 <a9de3ad2-55eb-99db-07f7-c5362d40e014@oracle.com>
 <c611df01-2995-d253-5838-8d7d0215bdf8@oracle.com>
Message-ID: <8af77199-e628-dd3a-9c1b-4f3c7e46ca8a@oracle.com>

Drafted a CSR:

https://bugs.openjdk.java.net/browse/JDK-8238809

Appreciate the review for this as well.

Naoto

On 2/10/20 8:52 AM, naoto.sato at oracle.com wrote:
> Good point. I will file a CSR for the behavioral changes.
> 
> Naoto
> 
> On 2/7/20 6:00 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> I see the existing tests were changed, e.g. the abbreviation / short 
>> timezone name, the result of calling getDisplayName. Would you need a 
>> CSR to discuss/document the potential incompatibility?
>>
>> Best,
>> Joe
>>
>> On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issues:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8234347
>>> https://bugs.openjdk.java.net/browse/JDK-8236548
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
>>>
>>> This changeset includes the following changes:
>>>
>>> - English time zone names missing in CLDR source files are no longer 
>>> copied from COMPAT provider at build time. Rather it is synthesized 
>>> at runtime, which has been the way other locales did.
>>>
>>> - Runtime CLDR time zone name provider fallback logic has been 
>>> refined. It now falls back to parent locales per each missing name, 
>>> instead of resource bundle. Also, region fall back is now using 
>>> exemplar city to synthesize the name (e.g., "Turkey" meta zone)
>>>
>>> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
>>> parses zone texts that start with "UTC", yet it is ZoneId.
>>>
>>> Naoto
>>

From naoto.sato at oracle.com  Tue Feb 11 18:17:12 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 11 Feb 2020 10:17:12 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
In-Reply-To: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
References: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
Message-ID: <8095f9c8-f279-4451-1680-53fe0b9d2d13@oracle.com>

Hi,

I modified the proposed changeset. Removed the hard coded 3-letter id 
compatibility mappings (oldMappings) from CLDRConverter.java. Instead, 
using public ZoneId.SHORT_IDS that contain the same set of mappings 
(wasn't aware it was defined in the spec!)

Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.01/

Naoto

On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
> Hello,
> 
> Please review the fix to the following issues:
> 
> https://bugs.openjdk.java.net/browse/JDK-8234347
> https://bugs.openjdk.java.net/browse/JDK-8236548
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
> 
> This changeset includes the following changes:
> 
> - English time zone names missing in CLDR source files are no longer 
> copied from COMPAT provider at build time. Rather it is synthesized at 
> runtime, which has been the way other locales did.
> 
> - Runtime CLDR time zone name provider fallback logic has been refined. 
> It now falls back to parent locales per each missing name, instead of 
> resource bundle. Also, region fall back is now using exemplar city to 
> synthesize the name (e.g., "Turkey" meta zone)
> 
> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
> parses zone texts that start with "UTC", yet it is ZoneId.
> 
> Naoto

From huizhe.wang at oracle.com  Tue Feb 11 23:12:32 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 11 Feb 2020 15:12:32 -0800
Subject: <i18n dev> [15] RFR: 8234347: "Turkey" meta time zone does not
 generate composed localized names,
 8236548: Localized time zone name inconsistency between English and other
 locales
In-Reply-To: <8095f9c8-f279-4451-1680-53fe0b9d2d13@oracle.com>
References: <016253d4-e458-55e6-6794-77b574fc42dc@oracle.com>
 <8095f9c8-f279-4451-1680-53fe0b9d2d13@oracle.com>
Message-ID: <482f3a89-3cdf-131d-20bb-b827e4511bfc@oracle.com>

+1. That's nicer.

-Joe

On 2/11/20 10:17 AM, naoto.sato at oracle.com wrote:
> Hi,
>
> I modified the proposed changeset. Removed the hard coded 3-letter id 
> compatibility mappings (oldMappings) from CLDRConverter.java. Instead, 
> using public ZoneId.SHORT_IDS that contain the same set of mappings 
> (wasn't aware it was defined in the spec!)
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.01/
>
> Naoto
>
> On 2/7/20 1:44 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issues:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8234347
>> https://bugs.openjdk.java.net/browse/JDK-8236548
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8234347.8236548/webrev.00/
>>
>> This changeset includes the following changes:
>>
>> - English time zone names missing in CLDR source files are no longer 
>> copied from COMPAT provider at build time. Rather it is synthesized 
>> at runtime, which has been the way other locales did.
>>
>> - Runtime CLDR time zone name provider fallback logic has been 
>> refined. It now falls back to parent locales per each missing name, 
>> instead of resource bundle. Also, region fall back is now using 
>> exemplar city to synthesize the name (e.g., "Turkey" meta zone)
>>
>> - Minor fix in DateTimeFormatterBuilder on zone text parsing. It now 
>> parses zone texts that start with "UTC", yet it is ZoneId.
>>
>> Naoto


From takiguc at linux.vnet.ibm.com  Mon Feb 17 18:23:04 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 18 Feb 2020 03:23:04 +0900
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
Message-ID: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8235834
Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/

IBM-943 is for IBM Japanese PC encoding.
MS932 is for Microsoft Japanese Windows encoding.
IBM-943 charset encoder does not contain 5 compatible entries compared 
to MS932 charset.

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From naoto.sato at oracle.com  Tue Feb 18 22:33:32 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 18 Feb 2020 14:33:32 -0800
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
Message-ID: <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>

Hi Takiguchi-san,

Can you please elaborate the rationale for the change? It looks like 
IBM943 chaset hasn't changed for a long time, at least from JDK8. Has 
the mapping definition recently changed?

Naoto

On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
> 
> IBM-943 is for IBM Japanese PC encoding.
> MS932 is for Microsoft Japanese Windows encoding.
> IBM-943 charset encoder does not contain 5 compatible entries compared 
> to MS932 charset.
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Thu Feb 20 10:47:55 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 20 Feb 2020 19:47:55 +0900
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
 <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
Message-ID: <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>

Hello Naoto.

I appreciate your comment.

The definition has not changed recently.
Applying the change will prevent the characters which are used on 
Japanese PC from being converted to "?".

I checked IBM-943 definition and changelog.

Definitions and creation date are as follows:
(All definitions are valid)
03AF34B0.TPMAP120: May 20 1997 ?Current OpenJDK)
34B003AF.RPMAP130: May 20 1997 (Proposed change, upward compatible)
34B003AF.RPMAP14A: Jul 29 1998 (Same as 34B003AF.RPMAP130)
34B003AF.RPMAP15A: Jan  8 2003 (Additionally, 13 characters are changed)

According to IBM943.map, OpenJDK JDK refers 03AF34B0.TPMAP120.
03AF34B0.TPMAP120 just has B2C conversion table only, no C2B definition.
34B003AF.RPMAP130 which has C2B definition was released on same date.
I assume C2B definition was not implemented at that time.

C2B definition for 34B003AF.RPMAP130 and 34B003AF.RPMAP14A are same, 
only replacement character is changed.
34B003AF.RPMAP15A is the latest, but it's almost same as MS932.
If 34B003AF.RPMAP15A is applied, 03AF34B0.TPMAP14A is also required.
I'd like to add C2B definition without B2C definition because of 
compatibility.
I don't want to apply 03AF34B0.TPMAP14A B2C definition.

So I'd like to apply 34B003AF.RPMAP130 definition.

Thanks,
Ichiroh Takiguchi

On 2020-02-19 07:33, naoto.sato at oracle.com wrote:
> Hi Takiguchi-san,
> 
> Can you please elaborate the rationale for the change? It looks like
> IBM943 chaset hasn't changed for a long time, at least from JDK8. Has
> the mapping definition recently changed?
> 
> Naoto
> 
> On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
>> 
>> IBM-943 is for IBM Japanese PC encoding.
>> MS932 is for Microsoft Japanese Windows encoding.
>> IBM-943 charset encoder does not contain 5 compatible entries compared 
>> to MS932 charset.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Thu Feb 20 17:51:22 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 20 Feb 2020 09:51:22 -0800
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
 <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
 <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>
Message-ID: <56bca64c-dad8-1f48-60ef-cb5595b4fdf7@oracle.com>

Thanks for the explanation. Here are comments to your fix:

- Can you add some comments about the gist of the change to IBM943.c2b? 
Summarizing the explanation below would be fine.

For the test case:

- Please wrap the @bug line appropriately.

- Those byte array/Strings can be "static final" outside the test method.

- Looks like the mapping is exactly the same with IBM943C for those code 
points. Is that correct? If so, would you please add some comment as such?

- Typo: "round-tip" -> "round-trip"

Naoto

On 2/20/20 2:47 AM, Ichiroh Takiguchi wrote:
> Hello Naoto.
> 
> I appreciate your comment.
> 
> The definition has not changed recently.
> Applying the change will prevent the characters which are used on 
> Japanese PC from being converted to "?".
> 
> I checked IBM-943 definition and changelog.
> 
> Definitions and creation date are as follows:
> (All definitions are valid)
> 03AF34B0.TPMAP120: May 20 1997 ?Current OpenJDK)
> 34B003AF.RPMAP130: May 20 1997 (Proposed change, upward compatible)
> 34B003AF.RPMAP14A: Jul 29 1998 (Same as 34B003AF.RPMAP130)
> 34B003AF.RPMAP15A: Jan? 8 2003 (Additionally, 13 characters are changed)
> 
> According to IBM943.map, OpenJDK JDK refers 03AF34B0.TPMAP120.
> 03AF34B0.TPMAP120 just has B2C conversion table only, no C2B definition.
> 34B003AF.RPMAP130 which has C2B definition was released on same date.
> I assume C2B definition was not implemented at that time.
> 
> C2B definition for 34B003AF.RPMAP130 and 34B003AF.RPMAP14A are same, 
> only replacement character is changed.
> 34B003AF.RPMAP15A is the latest, but it's almost same as MS932.
> If 34B003AF.RPMAP15A is applied, 03AF34B0.TPMAP14A is also required.
> I'd like to add C2B definition without B2C definition because of 
> compatibility.
> I don't want to apply 03AF34B0.TPMAP14A B2C definition.
> 
> So I'd like to apply 34B003AF.RPMAP130 definition.
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2020-02-19 07:33, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>>
>> Can you please elaborate the rationale for the change? It looks like
>> IBM943 chaset hasn't changed for a long time, at least from JDK8. Has
>> the mapping definition recently changed?
>>
>> Naoto
>>
>> On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
>>>
>>> IBM-943 is for IBM Japanese PC encoding.
>>> MS932 is for Microsoft Japanese Windows encoding.
>>> IBM-943 charset encoder does not contain 5 compatible entries 
>>> compared to MS932 charset.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Fri Feb 21 13:10:32 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 21 Feb 2020 22:10:32 +0900
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <56bca64c-dad8-1f48-60ef-cb5595b4fdf7@oracle.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
 <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
 <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>
 <56bca64c-dad8-1f48-60ef-cb5595b4fdf7@oracle.com>
Message-ID: <bacf1dbdf33e558ad77ebd0b6f9e7d70@linux.vnet.ibm.com>

Hello Naoto.

I appreciate your suggestions.
I applied your suggestions into new patch.
Could you review the fix again ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8235834
Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.01/

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

On 2020-02-21 02:51, naoto.sato at oracle.com wrote:
> Thanks for the explanation. Here are comments to your fix:
> 
> - Can you add some comments about the gist of the change to
> IBM943.c2b? Summarizing the explanation below would be fine.
> 
> For the test case:
> 
> - Please wrap the @bug line appropriately.
> 
> - Those byte array/Strings can be "static final" outside the test 
> method.
> 
> - Looks like the mapping is exactly the same with IBM943C for those
> code points. Is that correct? If so, would you please add some comment
> as such?
> 
> - Typo: "round-tip" -> "round-trip"
> 
> Naoto
> 
> On 2/20/20 2:47 AM, Ichiroh Takiguchi wrote:
>> Hello Naoto.
>> 
>> I appreciate your comment.
>> 
>> The definition has not changed recently.
>> Applying the change will prevent the characters which are used on 
>> Japanese PC from being converted to "?".
>> 
>> I checked IBM-943 definition and changelog.
>> 
>> Definitions and creation date are as follows:
>> (All definitions are valid)
>> 03AF34B0.TPMAP120: May 20 1997 ?Current OpenJDK)
>> 34B003AF.RPMAP130: May 20 1997 (Proposed change, upward compatible)
>> 34B003AF.RPMAP14A: Jul 29 1998 (Same as 34B003AF.RPMAP130)
>> 34B003AF.RPMAP15A: Jan? 8 2003 (Additionally, 13 characters are 
>> changed)
>> 
>> According to IBM943.map, OpenJDK JDK refers 03AF34B0.TPMAP120.
>> 03AF34B0.TPMAP120 just has B2C conversion table only, no C2B 
>> definition.
>> 34B003AF.RPMAP130 which has C2B definition was released on same date.
>> I assume C2B definition was not implemented at that time.
>> 
>> C2B definition for 34B003AF.RPMAP130 and 34B003AF.RPMAP14A are same, 
>> only replacement character is changed.
>> 34B003AF.RPMAP15A is the latest, but it's almost same as MS932.
>> If 34B003AF.RPMAP15A is applied, 03AF34B0.TPMAP14A is also required.
>> I'd like to add C2B definition without B2C definition because of 
>> compatibility.
>> I don't want to apply 03AF34B0.TPMAP14A B2C definition.
>> 
>> So I'd like to apply 34B003AF.RPMAP130 definition.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2020-02-19 07:33, naoto.sato at oracle.com wrote:
>>> Hi Takiguchi-san,
>>> 
>>> Can you please elaborate the rationale for the change? It looks like
>>> IBM943 chaset hasn't changed for a long time, at least from JDK8. Has
>>> the mapping definition recently changed?
>>> 
>>> Naoto
>>> 
>>> On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>> 
>>>> Could you review the fix ?
>>>> 
>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
>>>> 
>>>> IBM-943 is for IBM Japanese PC encoding.
>>>> MS932 is for Microsoft Japanese Windows encoding.
>>>> IBM-943 charset encoder does not contain 5 compatible entries 
>>>> compared to MS932 charset.
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Fri Feb 21 16:53:59 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 21 Feb 2020 08:53:59 -0800
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <bacf1dbdf33e558ad77ebd0b6f9e7d70@linux.vnet.ibm.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
 <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
 <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>
 <56bca64c-dad8-1f48-60ef-cb5595b4fdf7@oracle.com>
 <bacf1dbdf33e558ad77ebd0b6f9e7d70@linux.vnet.ibm.com>
Message-ID: <a00da2af-4932-3c3a-8d4b-e6c6b8ae2918@oracle.com>

Two subtle comments to the new webrev:

- I'd add "private" to those static finals.
- "cs.name()" in the exception messages can be replaced with "csName".

Otherwise it looks good. If you agree with the above, no further review 
is needed. Also, if you need a sponsor, I can sponsor your changeset.

Naoto

On 2/21/20 5:10 AM, Ichiroh Takiguchi wrote:
> Hello Naoto.
> 
> I appreciate your suggestions.
> I applied your suggestions into new patch.
> Could you review the fix again ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.01/
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.
> 
> On 2020-02-21 02:51, naoto.sato at oracle.com wrote:
>> Thanks for the explanation. Here are comments to your fix:
>>
>> - Can you add some comments about the gist of the change to
>> IBM943.c2b? Summarizing the explanation below would be fine.
>>
>> For the test case:
>>
>> - Please wrap the @bug line appropriately.
>>
>> - Those byte array/Strings can be "static final" outside the test method.
>>
>> - Looks like the mapping is exactly the same with IBM943C for those
>> code points. Is that correct? If so, would you please add some comment
>> as such?
>>
>> - Typo: "round-tip" -> "round-trip"
>>
>> Naoto
>>
>> On 2/20/20 2:47 AM, Ichiroh Takiguchi wrote:
>>> Hello Naoto.
>>>
>>> I appreciate your comment.
>>>
>>> The definition has not changed recently.
>>> Applying the change will prevent the characters which are used on 
>>> Japanese PC from being converted to "?".
>>>
>>> I checked IBM-943 definition and changelog.
>>>
>>> Definitions and creation date are as follows:
>>> (All definitions are valid)
>>> 03AF34B0.TPMAP120: May 20 1997 ?Current OpenJDK)
>>> 34B003AF.RPMAP130: May 20 1997 (Proposed change, upward compatible)
>>> 34B003AF.RPMAP14A: Jul 29 1998 (Same as 34B003AF.RPMAP130)
>>> 34B003AF.RPMAP15A: Jan? 8 2003 (Additionally, 13 characters are changed)
>>>
>>> According to IBM943.map, OpenJDK JDK refers 03AF34B0.TPMAP120.
>>> 03AF34B0.TPMAP120 just has B2C conversion table only, no C2B definition.
>>> 34B003AF.RPMAP130 which has C2B definition was released on same date.
>>> I assume C2B definition was not implemented at that time.
>>>
>>> C2B definition for 34B003AF.RPMAP130 and 34B003AF.RPMAP14A are same, 
>>> only replacement character is changed.
>>> 34B003AF.RPMAP15A is the latest, but it's almost same as MS932.
>>> If 34B003AF.RPMAP15A is applied, 03AF34B0.TPMAP14A is also required.
>>> I'd like to add C2B definition without B2C definition because of 
>>> compatibility.
>>> I don't want to apply 03AF34B0.TPMAP14A B2C definition.
>>>
>>> So I'd like to apply 34B003AF.RPMAP130 definition.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2020-02-19 07:33, naoto.sato at oracle.com wrote:
>>>> Hi Takiguchi-san,
>>>>
>>>> Can you please elaborate the rationale for the change? It looks like
>>>> IBM943 chaset hasn't changed for a long time, at least from JDK8. Has
>>>> the mapping definition recently changed?
>>>>
>>>> Naoto
>>>>
>>>> On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
>>>>> Hello.
>>>>>
>>>>> Could you review the fix ?
>>>>>
>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
>>>>>
>>>>> IBM-943 is for IBM Japanese PC encoding.
>>>>> MS932 is for Microsoft Japanese Windows encoding.
>>>>> IBM-943 charset encoder does not contain 5 compatible entries 
>>>>> compared to MS932 charset.
>>>>>
>>>>> Thanks,
>>>>> Ichiroh Takiguchi
>>>>> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Mon Feb 24 14:57:06 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 24 Feb 2020 23:57:06 +0900
Subject: <i18n dev> RFR: 8235834 IBM-943 charset encoder needs updating
In-Reply-To: <a00da2af-4932-3c3a-8d4b-e6c6b8ae2918@oracle.com>
References: <e3ab0a27e07a40e25947ef7da7b5bcc5@linux.vnet.ibm.com>
 <8fcaa338-f0e3-6c2b-71fa-48b074fe762e@oracle.com>
 <a3ebbef34e7f4c9b24b4c855fac0d511@linux.vnet.ibm.com>
 <56bca64c-dad8-1f48-60ef-cb5595b4fdf7@oracle.com>
 <bacf1dbdf33e558ad77ebd0b6f9e7d70@linux.vnet.ibm.com>
 <a00da2af-4932-3c3a-8d4b-e6c6b8ae2918@oracle.com>
Message-ID: <fc02402ab488b2a3434fb58c7451ea71@linux.vnet.ibm.com>

Hello Naoto.

Yes, I agree with your suggestion.
I'm very happy if you are the sponsor of this issue.

Thanks,
Ichiroh Takiguchi

On 2020-02-22 01:53, naoto.sato at oracle.com wrote:
> Two subtle comments to the new webrev:
> 
> - I'd add "private" to those static finals.
> - "cs.name()" in the exception messages can be replaced with "csName".
> 
> Otherwise it looks good. If you agree with the above, no further
> review is needed. Also, if you need a sponsor, I can sponsor your
> changeset.
> 
> Naoto
> 
> On 2/21/20 5:10 AM, Ichiroh Takiguchi wrote:
>> Hello Naoto.
>> 
>> I appreciate your suggestions.
>> I applied your suggestions into new patch.
>> Could you review the fix again ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.01/
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.
>> 
>> On 2020-02-21 02:51, naoto.sato at oracle.com wrote:
>>> Thanks for the explanation. Here are comments to your fix:
>>> 
>>> - Can you add some comments about the gist of the change to
>>> IBM943.c2b? Summarizing the explanation below would be fine.
>>> 
>>> For the test case:
>>> 
>>> - Please wrap the @bug line appropriately.
>>> 
>>> - Those byte array/Strings can be "static final" outside the test 
>>> method.
>>> 
>>> - Looks like the mapping is exactly the same with IBM943C for those
>>> code points. Is that correct? If so, would you please add some 
>>> comment
>>> as such?
>>> 
>>> - Typo: "round-tip" -> "round-trip"
>>> 
>>> Naoto
>>> 
>>> On 2/20/20 2:47 AM, Ichiroh Takiguchi wrote:
>>>> Hello Naoto.
>>>> 
>>>> I appreciate your comment.
>>>> 
>>>> The definition has not changed recently.
>>>> Applying the change will prevent the characters which are used on 
>>>> Japanese PC from being converted to "?".
>>>> 
>>>> I checked IBM-943 definition and changelog.
>>>> 
>>>> Definitions and creation date are as follows:
>>>> (All definitions are valid)
>>>> 03AF34B0.TPMAP120: May 20 1997 ?Current OpenJDK)
>>>> 34B003AF.RPMAP130: May 20 1997 (Proposed change, upward compatible)
>>>> 34B003AF.RPMAP14A: Jul 29 1998 (Same as 34B003AF.RPMAP130)
>>>> 34B003AF.RPMAP15A: Jan? 8 2003 (Additionally, 13 characters are 
>>>> changed)
>>>> 
>>>> According to IBM943.map, OpenJDK JDK refers 03AF34B0.TPMAP120.
>>>> 03AF34B0.TPMAP120 just has B2C conversion table only, no C2B 
>>>> definition.
>>>> 34B003AF.RPMAP130 which has C2B definition was released on same 
>>>> date.
>>>> I assume C2B definition was not implemented at that time.
>>>> 
>>>> C2B definition for 34B003AF.RPMAP130 and 34B003AF.RPMAP14A are same, 
>>>> only replacement character is changed.
>>>> 34B003AF.RPMAP15A is the latest, but it's almost same as MS932.
>>>> If 34B003AF.RPMAP15A is applied, 03AF34B0.TPMAP14A is also required.
>>>> I'd like to add C2B definition without B2C definition because of 
>>>> compatibility.
>>>> I don't want to apply 03AF34B0.TPMAP14A B2C definition.
>>>> 
>>>> So I'd like to apply 34B003AF.RPMAP130 definition.
>>>> 
>>>> Thanks,
>>>> Ichiroh Takiguchi
>>>> 
>>>> On 2020-02-19 07:33, naoto.sato at oracle.com wrote:
>>>>> Hi Takiguchi-san,
>>>>> 
>>>>> Can you please elaborate the rationale for the change? It looks 
>>>>> like
>>>>> IBM943 chaset hasn't changed for a long time, at least from JDK8. 
>>>>> Has
>>>>> the mapping definition recently changed?
>>>>> 
>>>>> Naoto
>>>>> 
>>>>> On 2/17/20 10:23 AM, Ichiroh Takiguchi wrote:
>>>>>> Hello.
>>>>>> 
>>>>>> Could you review the fix ?
>>>>>> 
>>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8235834
>>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8235834/webrev.00/
>>>>>> 
>>>>>> IBM-943 is for IBM Japanese PC encoding.
>>>>>> MS932 is for Microsoft Japanese Windows encoding.
>>>>>> IBM-943 charset encoder does not contain 5 compatible entries 
>>>>>> compared to MS932 charset.
>>>>>> 
>>>>>> Thanks,
>>>>>> Ichiroh Takiguchi
>>>>>> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Wed Feb 26 18:03:00 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 27 Feb 2020 03:03:00 +0900
Subject: <i18n dev> RFR: 8239965: XMLEncoder/Test4625418.java fails due to
 "Error: Cp943 - can't read properly"
Message-ID: <5d397b0c64ac8af0d6aee4efdbdc2d2e@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8239965
Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.00/

Sorry for side effect.
Test4625418.java should skip Cp943 and x-IBM943 should be skipped
after JDK-8235834 [1] was integrated.

[1] https://bugs.openjdk.java.net/browse/JDK-8235834

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From naoto.sato at oracle.com  Wed Feb 26 20:56:01 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 26 Feb 2020 12:56:01 -0800
Subject: <i18n dev> RFR: 8239965: XMLEncoder/Test4625418.java fails due
 to "Error: Cp943 - can't read properly"
In-Reply-To: <5d397b0c64ac8af0d6aee4efdbdc2d2e@linux.vnet.ibm.com>
References: <5d397b0c64ac8af0d6aee4efdbdc2d2e@linux.vnet.ibm.com>
Message-ID: <22b947cc-02ca-84af-2644-84bf1012c5a2@oracle.com>

Takiguchi-san,

Some nits:

- Please add 'noreg-self' to the jira issue.
- Copyright year should be modified.
- Add the bug number to '@bug' tag.

Naoto

On 2/26/20 10:03 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review the fix ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8239965
> Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.00/
> 
> Sorry for side effect.
> Test4625418.java should skip Cp943 and x-IBM943 should be skipped
> after JDK-8235834 [1] was integrated.
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8235834
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Thu Feb 27 14:00:56 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Thu, 27 Feb 2020 23:00:56 +0900
Subject: <i18n dev> RFR: 8239965: XMLEncoder/Test4625418.java fails due
 to "Error: Cp943 - can't read properly"
In-Reply-To: <22b947cc-02ca-84af-2644-84bf1012c5a2@oracle.com>
References: <5d397b0c64ac8af0d6aee4efdbdc2d2e@linux.vnet.ibm.com>
 <22b947cc-02ca-84af-2644-84bf1012c5a2@oracle.com>
Message-ID: <2461ebc751531239042c28f2819a729b@linux.vnet.ibm.com>

Hello Naoto.

I appreciate your comments.
And sorry for my easy mistake.

Could you review the fix again ?

Bug:    https://bugs.openjdk.java.net/browse/JDK-8239965
Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.01/

Thanks,
Ichiroh Takiguchi

On 2020-02-27 05:56, naoto.sato at oracle.com wrote:
> Takiguchi-san,
> 
> Some nits:
> 
> - Please add 'noreg-self' to the jira issue.
> - Copyright year should be modified.
> - Add the bug number to '@bug' tag.
> 
> Naoto
> 
> On 2/26/20 10:03 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8239965
>> Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.00/
>> 
>> Sorry for side effect.
>> Test4625418.java should skip Cp943 and x-IBM943 should be skipped
>> after JDK-8235834 [1] was integrated.
>> 
>> [1] https://bugs.openjdk.java.net/browse/JDK-8235834
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Thu Feb 27 16:42:43 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 27 Feb 2020 08:42:43 -0800
Subject: <i18n dev> RFR: 8239965: XMLEncoder/Test4625418.java fails due
 to "Error: Cp943 - can't read properly"
In-Reply-To: <2461ebc751531239042c28f2819a729b@linux.vnet.ibm.com>
References: <5d397b0c64ac8af0d6aee4efdbdc2d2e@linux.vnet.ibm.com>
 <22b947cc-02ca-84af-2644-84bf1012c5a2@oracle.com>
 <2461ebc751531239042c28f2819a729b@linux.vnet.ibm.com>
Message-ID: <9031d509-691e-d429-5785-06ecc46a248c@oracle.com>

Looks good.

Naoto

On 2/27/20 6:00 AM, Ichiroh Takiguchi wrote:
> Hello Naoto.
> 
> I appreciate your comments.
> And sorry for my easy mistake.
> 
> Could you review the fix again ?
> 
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8239965
> Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.01/
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2020-02-27 05:56, naoto.sato at oracle.com wrote:
>> Takiguchi-san,
>>
>> Some nits:
>>
>> - Please add 'noreg-self' to the jira issue.
>> - Copyright year should be modified.
>> - Add the bug number to '@bug' tag.
>>
>> Naoto
>>
>> On 2/26/20 10:03 AM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8239965
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8239965/webrev.00/
>>>
>>> Sorry for side effect.
>>> Test4625418.java should skip Cp943 and x-IBM943 should be skipped
>>> after JDK-8235834 [1] was integrated.
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8235834
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>> IBM Japan, Ltd.