From huizhe.wang at oracle.com  Wed Dec  4 18:12:03 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Wed, 4 Dec 2019 10:12:03 -0800
Subject: <i18n dev> [14] RFR: 8222756: Plural support in
 CompactNumberFormat
In-Reply-To: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
 <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
Message-ID: <8620cb24-dbd0-fe5e-15ee-bf014c10243d@oracle.com>

Hi Naoto,

Looks good. I understand you'll update the webrev (with the added 
statement to readObject) once the CSR is approved.

ResourceBundleGenerator.java might have been accidentally touched as 
there's no change there.

I wonder if you need to guard the pluralRules input since you're 
building a Map with a split. While it normally won't be a problem if the 
factory methods are used, there's still a chance CompactNumberFormat is 
constructed directly (e.g. with a custom format).

Best,
Joe

On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote:
> I modified CompactNumberFormat.java to simplify the syntax parsing:
>
> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/
>
> Please review this webrev instead.
>
> Naoto
>
> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> CompactNumberFormat has been added since JDK 12 to support compact 
>> number formatting, such as 10_000 being formatted as "10K." [1] It 
>> works fine for English, however, not for other languages that take 
>> plural forms in formatted number prefixes/suffixes. In order to fix 
>> this, I filed the following CSR to extend the current 
>> CompactNumberFormat spec:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8232633
>>
>> It basically accommodates the plural prefix/suffix forms into the 
>> existing compact patterns array, so that the existing compact number 
>> format works compatibly. The plural rules are solely based on the 
>> CLDR's plural language rules [2]
>>
>> Here is the implementation of the CSR:
>>
>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/
>>
>> Please review the CSR as well as its implementation.
>>
>> Naoto
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552
>> [2] 
>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules


From letuyang at amazon.com  Wed Dec  4 19:38:40 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Wed, 4 Dec 2019 19:38:40 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
 <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>
Message-ID: <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com>

Hi Naoto,

Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/

Letu

?On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:

    Looks good.
    
    Naoto
    
    On 11/22/19 9:55 PM, Yang, Letu wrote:
    > Hi Naoto,
    > 
    > Added it in the new webrev 
    > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!
    > 
    > Letu
    > 
    > 
    > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
    > Hi Letu,
    > 
    > You might want to add lines for "Turkey" zone as well in LocaleData?
    > 
    > Naoto
    > 
    > On 11/22/19 4:16 PM, Yang, Letu wrote:
    >> Hi Naoto,
    >> 
    >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
    >> 
    >> Letu
    >> 
    >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >> 
    >>      Hi Letu,
    >>      
    >>      The change in the resource bundle file looks good.
    >>      
    >>      As to the regression test, I would avoid adding a separate file, instead
    >>      add some variations for
    >>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
    >>      some lines in "LocaleData" file, which contains the expected resources
    >>      for the COMPAT locale provider.
    >>      
    >>      Naoto
    >>      
    >>      On 11/20/19 9:43 PM, Yang, Letu wrote:
    >>      > Hi Naoto,
    >>      >
    >>      > Thank you for the suggestions!
    >>      >
    >>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
    >>      >
    >>      > Letu
    >>      >
    >>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >>      >
    >>      >      Hi Letu,
    >>      >
    >>      >      Here are my comments to your changes:
    >>      >
    >>      >      - You will need a regression test for this fix. Take a look at
    >>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
    >>      >      test cases.
    >>      >
    >>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
    >>      >
    >>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
    >>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
    >>      >      DST, names in those slots should reflect the DST (consistent to other names)
    >>      >
    >>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
    >>      >
    >>      >      Naoto
    >>      >
    >>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
    >>      >
    >>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
    >>      >      > Hi Naoto,
    >>      >      >
    >>      >      > Thank you for the clarification!
    >>      >      >
    >>      >      > Xin from my team has filed a JBS and uploaded my webrev:
    >>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
    >>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
    >>      >      >
    >>      >      > Letu
    >>      >      >
    >>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >>      >      >
    >>      >      >      Letu,
    >>      >      >
    >>      >      >      Please go ahead and fix the issue in English resource. As to the
    >>      >      >      translation, Oracle l10n will translate it in appropriate locales.
    >>      >      >
    >>      >      >      Naoto
    >>      >      >
    >>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
    >>      >      >      > Hi Naoto
    >>      >      >      >
    >>      >      >      > Thank you for the quick response! We will file a ticket later today.
    >>      >      >      >
    >>      >      >      > Shall we make an effort on fixing and translating the strings, or you
    >>      >      >      > prefer to take care of it at Oracle?
    >>      >      >      >
    >>      >      >      > Letu
    >>      >      >      >
    >>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    >>      >      >      > Hi Letu,
    >>      >      >      >
    >>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
    >>      >      >      > java.util:i18n).
    >>      >      >      >
    >>      >      >      > Naoto
    >>      >      >      >
    >>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >>      >      >      >> Hi,
    >>      >      >      >>
    >>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been  updated yet:
    >>      >      >      >>
    >>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >>      >      >      >>
    >>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul".  This also need to  be updated for other locales. I can create a JBS 
    > issue for this, but I
    >>      >      >      > am not sure whether we should fix this bug, or there is an existing
    >>      >      >      > procedure for this kind of bug which requires language translation.
    >>      >      >      >>
    >>      >      >      >> Letu
    >>      >      >      >>
    >>      >      >      >>
    >>      >      >      >>
    >>      >      >
    >>      >      >
    >>      >
    >>      >
    >>      
    >> 
    


From naoto.sato at oracle.com  Wed Dec  4 20:35:10 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 4 Dec 2019 12:35:10 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
 <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>
 <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com>
Message-ID: <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com>

Looks good, assuming the change between 03 and 04 is to fix "no new line..."

Naoto

On 12/4/19 11:38 AM, Yang, Letu wrote:
> Hi Naoto,
> 
> Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/
> 
> Letu
> 
> ?On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
> 
>      Looks good.
>      
>      Naoto
>      
>      On 11/22/19 9:55 PM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Added it in the new webrev
>      > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!
>      >
>      > Letu
>      >
>      >
>      > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
>      > Hi Letu,
>      >
>      > You might want to add lines for "Turkey" zone as well in LocaleData?
>      >
>      > Naoto
>      >
>      > On 11/22/19 4:16 PM, Yang, Letu wrote:
>      >> Hi Naoto,
>      >>
>      >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
>      >>
>      >> Letu
>      >>
>      >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >>
>      >>      Hi Letu,
>      >>
>      >>      The change in the resource bundle file looks good.
>      >>
>      >>      As to the regression test, I would avoid adding a separate file, instead
>      >>      add some variations for
>      >>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
>      >>      some lines in "LocaleData" file, which contains the expected resources
>      >>      for the COMPAT locale provider.
>      >>
>      >>      Naoto
>      >>
>      >>      On 11/20/19 9:43 PM, Yang, Letu wrote:
>      >>      > Hi Naoto,
>      >>      >
>      >>      > Thank you for the suggestions!
>      >>      >
>      >>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
>      >>      >
>      >>      > Letu
>      >>      >
>      >>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >>      >
>      >>      >      Hi Letu,
>      >>      >
>      >>      >      Here are my comments to your changes:
>      >>      >
>      >>      >      - You will need a regression test for this fix. Take a look at
>      >>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      >>      >      test cases.
>      >>      >
>      >>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
>      >>      >
>      >>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      >>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
>      >>      >      DST, names in those slots should reflect the DST (consistent to other names)
>      >>      >
>      >>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      >>      >
>      >>      >      Naoto
>      >>      >
>      >>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
>      >>      >
>      >>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      >>      >      > Hi Naoto,
>      >>      >      >
>      >>      >      > Thank you for the clarification!
>      >>      >      >
>      >>      >      > Xin from my team has filed a JBS and uploaded my webrev:
>      >>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      >>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >>      >      >
>      >>      >      > Letu
>      >>      >      >
>      >>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >>      >      >
>      >>      >      >      Letu,
>      >>      >      >
>      >>      >      >      Please go ahead and fix the issue in English resource. As to the
>      >>      >      >      translation, Oracle l10n will translate it in appropriate locales.
>      >>      >      >
>      >>      >      >      Naoto
>      >>      >      >
>      >>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >>      >      >      > Hi Naoto
>      >>      >      >      >
>      >>      >      >      > Thank you for the quick response! We will file a ticket later today.
>      >>      >      >      >
>      >>      >      >      > Shall we make an effort on fixing and translating the strings, or you
>      >>      >      >      > prefer to take care of it at Oracle?
>      >>      >      >      >
>      >>      >      >      > Letu
>      >>      >      >      >
>      >>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >>      >      >      > Hi Letu,
>      >>      >      >      >
>      >>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >>      >      >      > java.util:i18n).
>      >>      >      >      >
>      >>      >      >      > Naoto
>      >>      >      >      >
>      >>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >>      >      >      >> Hi,
>      >>      >      >      >>
>      >>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been  updated yet:
>      >>      >      >      >>
>      >>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >>      >      >      >>
>      >>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul".  This also need to  be updated for other locales. I can create a JBS
>      > issue for this, but I
>      >>      >      >      > am not sure whether we should fix this bug, or there is an existing
>      >>      >      >      > procedure for this kind of bug which requires language translation.
>      >>      >      >      >>
>      >>      >      >      >> Letu
>      >>      >      >      >>
>      >>      >      >      >>
>      >>      >      >      >>
>      >>      >      >
>      >>      >      >
>      >>      >
>      >>      >
>      >>
>      >>
>      
> 

From naoto.sato at oracle.com  Thu Dec  5 18:49:26 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 5 Dec 2019 10:49:26 -0800
Subject: <i18n dev> [14] RFR: 8222756: Plural support in
	CompactNumberFormat
In-Reply-To: <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
 <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
Message-ID: <b2f95018-c03b-cd8b-ac0f-4f2cdedba3c7@oracle.com>

Thanks, Joe and Roger, for the reviews. Here is the updated webrev:

http://cr.openjdk.java.net/~naoto/8222756/webrev.02/

These are the changes since v.01:

CompactNumberFormat.java:

- Reflected the CSR changes (thank you, JoeD, for the quick 
turnaround!), and misc typos in the spec.

- Added length limitation to the "pluralRules" argument in the new 
constructor. Throws IllegalArgumentException if the input is too long 
(>2,048 chars).

- Added validation to plural rules, and throws IllegalArgumentException 
if the given rules' syntax is incorrect.

- Consolidated the same pattern to get the affixes into a utility method 
(getAffix())

- Directly find NaN and Infinity in the number string, parse the number 
with regex otherwise.

TestEquality.java: Tidied the test array up.

CLDRConverter.java: Added String::trim so that the generated 
PluralRules.java will not have extra spaces.

TestPlurals.java: Added test cases for invalid cases, i.e., invalid 
syntax and length limit exceeding rules in the constructor.

Not addressed:

- ResourceBundleGenerator.java exists in the webrev as it does have a 
modification (only seen in "patch" link, as the mod is only the indentation)

- Using "==" for double values: As Roger mentioned, it is in fact 
comparing integers (the only reason to use double is to deal with NaN 
and Infinity)

- Possible performance improvement: Could be addressed later if it is 
regarded as an issue. But since the effective plural rules are 
simple/short enough, I would not expect it as a problem.

Naoto



On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote:
> I modified CompactNumberFormat.java to simplify the syntax parsing:
> 
> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/
> 
> Please review this webrev instead.
> 
> Naoto
> 
> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> CompactNumberFormat has been added since JDK 12 to support compact 
>> number formatting, such as 10_000 being formatted as "10K." [1] It 
>> works fine for English, however, not for other languages that take 
>> plural forms in formatted number prefixes/suffixes. In order to fix 
>> this, I filed the following CSR to extend the current 
>> CompactNumberFormat spec:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8232633
>>
>> It basically accommodates the plural prefix/suffix forms into the 
>> existing compact patterns array, so that the existing compact number 
>> format works compatibly. The plural rules are solely based on the 
>> CLDR's plural language rules [2]
>>
>> Here is the implementation of the CSR:
>>
>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/
>>
>> Please review the CSR as well as its implementation.
>>
>> Naoto
>>
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552
>> [2] 
>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules

From Roger.Riggs at oracle.com  Thu Dec  5 20:13:57 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 5 Dec 2019 15:13:57 -0500
Subject: <i18n dev> [14] RFR: 8222756: Plural support in
	CompactNumberFormat
In-Reply-To: <b2f95018-c03b-cd8b-ac0f-4f2cdedba3c7@oracle.com>
References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
 <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
 <b2f95018-c03b-cd8b-ac0f-4f2cdedba3c7@oracle.com>
Message-ID: <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com>

Hi Naoto,

Thanks for the updates.

Looks fine.

Roger


On 12/5/19 1:49 PM, naoto.sato at oracle.com wrote:
> Thanks, Joe and Roger, for the reviews. Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8222756/webrev.02/
>
> These are the changes since v.01:
>
> CompactNumberFormat.java:
>
> - Reflected the CSR changes (thank you, JoeD, for the quick 
> turnaround!), and misc typos in the spec.
>
> - Added length limitation to the "pluralRules" argument in the new 
> constructor. Throws IllegalArgumentException if the input is too long 
> (>2,048 chars).
>
> - Added validation to plural rules, and throws 
> IllegalArgumentException if the given rules' syntax is incorrect.
>
> - Consolidated the same pattern to get the affixes into a utility 
> method (getAffix())
>
> - Directly find NaN and Infinity in the number string, parse the 
> number with regex otherwise.
>
> TestEquality.java: Tidied the test array up.
>
> CLDRConverter.java: Added String::trim so that the generated 
> PluralRules.java will not have extra spaces.
>
> TestPlurals.java: Added test cases for invalid cases, i.e., invalid 
> syntax and length limit exceeding rules in the constructor.
>
> Not addressed:
>
> - ResourceBundleGenerator.java exists in the webrev as it does have a 
> modification (only seen in "patch" link, as the mod is only the 
> indentation)
>
> - Using "==" for double values: As Roger mentioned, it is in fact 
> comparing integers (the only reason to use double is to deal with NaN 
> and Infinity)
>
> - Possible performance improvement: Could be addressed later if it is 
> regarded as an issue. But since the effective plural rules are 
> simple/short enough, I would not expect it as a problem.
>
> Naoto
>
>
>
> On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote:
>> I modified CompactNumberFormat.java to simplify the syntax parsing:
>>
>> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/
>>
>> Please review this webrev instead.
>>
>> Naoto
>>
>> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> CompactNumberFormat has been added since JDK 12 to support compact 
>>> number formatting, such as 10_000 being formatted as "10K." [1] It 
>>> works fine for English, however, not for other languages that take 
>>> plural forms in formatted number prefixes/suffixes. In order to fix 
>>> this, I filed the following CSR to extend the current 
>>> CompactNumberFormat spec:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8232633
>>>
>>> It basically accommodates the plural prefix/suffix forms into the 
>>> existing compact patterns array, so that the existing compact number 
>>> format works compatibly. The plural rules are solely based on the 
>>> CLDR's plural language rules [2]
>>>
>>> Here is the implementation of the CSR:
>>>
>>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/
>>>
>>> Please review the CSR as well as its implementation.
>>>
>>> Naoto
>>>
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552
>>> [2] 
>>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules 
>>>


From huizhe.wang at oracle.com  Thu Dec  5 21:02:39 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 5 Dec 2019 13:02:39 -0800
Subject: <i18n dev> [14] RFR: 8222756: Plural support in
	CompactNumberFormat
In-Reply-To: <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com>
References: <350d65d3-1c97-bba9-485c-b393fbbb899d@oracle.com>
 <90096b6b-f652-af97-7651-fa3791795f8e@oracle.com>
 <b2f95018-c03b-cd8b-ac0f-4f2cdedba3c7@oracle.com>
 <8902cbf4-6abf-493f-cf4f-f50fe622c520@oracle.com>
Message-ID: <a22a010e-1835-13b1-81b1-6150ba166719@oracle.com>

+1, looks good!


Best regards,
Joe


On 12/5/19 12:13 PM, Roger Riggs wrote:
> Hi Naoto,
>
> Thanks for the updates.
>
> Looks fine.
>
> Roger
>
>
> On 12/5/19 1:49 PM, naoto.sato at oracle.com wrote:
>> Thanks, Joe and Roger, for the reviews. Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8222756/webrev.02/
>>
>> These are the changes since v.01:
>>
>> CompactNumberFormat.java:
>>
>> - Reflected the CSR changes (thank you, JoeD, for the quick 
>> turnaround!), and misc typos in the spec.
>>
>> - Added length limitation to the "pluralRules" argument in the new 
>> constructor. Throws IllegalArgumentException if the input is too long 
>> (>2,048 chars).
>>
>> - Added validation to plural rules, and throws 
>> IllegalArgumentException if the given rules' syntax is incorrect.
>>
>> - Consolidated the same pattern to get the affixes into a utility 
>> method (getAffix())
>>
>> - Directly find NaN and Infinity in the number string, parse the 
>> number with regex otherwise.
>>
>> TestEquality.java: Tidied the test array up.
>>
>> CLDRConverter.java: Added String::trim so that the generated 
>> PluralRules.java will not have extra spaces.
>>
>> TestPlurals.java: Added test cases for invalid cases, i.e., invalid 
>> syntax and length limit exceeding rules in the constructor.
>>
>> Not addressed:
>>
>> - ResourceBundleGenerator.java exists in the webrev as it does have a 
>> modification (only seen in "patch" link, as the mod is only the 
>> indentation)
>>
>> - Using "==" for double values: As Roger mentioned, it is in fact 
>> comparing integers (the only reason to use double is to deal with NaN 
>> and Infinity)
>>
>> - Possible performance improvement: Could be addressed later if it is 
>> regarded as an issue. But since the effective plural rules are 
>> simple/short enough, I would not expect it as a problem.
>>
>> Naoto
>>
>>
>>
>> On 11/26/19 1:35 PM, naoto.sato at oracle.com wrote:
>>> I modified CompactNumberFormat.java to simplify the syntax parsing:
>>>
>>> https://cr.openjdk.java.net/~naoto/8222756/webrev.01/
>>>
>>> Please review this webrev instead.
>>>
>>> Naoto
>>>
>>> On 11/25/19 1:16 PM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> CompactNumberFormat has been added since JDK 12 to support compact 
>>>> number formatting, such as 10_000 being formatted as "10K." [1] It 
>>>> works fine for English, however, not for other languages that take 
>>>> plural forms in formatted number prefixes/suffixes. In order to fix 
>>>> this, I filed the following CSR to extend the current 
>>>> CompactNumberFormat spec:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8232633
>>>>
>>>> It basically accommodates the plural prefix/suffix forms into the 
>>>> existing compact patterns array, so that the existing compact 
>>>> number format works compatibly. The plural rules are solely based 
>>>> on the CLDR's plural language rules [2]
>>>>
>>>> Here is the implementation of the CSR:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8222756/webrev.00/
>>>>
>>>> Please review the CSR as well as its implementation.
>>>>
>>>> Naoto
>>>>
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8177552
>>>> [2] 
>>>> https://unicode.org/reports/tr35/tr35-numbers.html#Language_Plural_Rules 
>>>>
>


From letuyang at amazon.com  Mon Dec  9 18:04:46 2019
From: letuyang at amazon.com (Yang, Letu)
Date: Mon, 9 Dec 2019 18:04:46 +0000
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
 <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>
 <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com>
 <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com>
Message-ID: <B3BCE271-102B-42AE-A26B-653C1997B82A@amazon.com>

Thanks Naoto!

Is there a separate ticket for the translation to other locales?

Letu

?On 12/4/19, 12:36 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:

    Looks good, assuming the change between 03 and 04 is to fix "no new line..."
    
    Naoto
    
    On 12/4/19 11:38 AM, Yang, Letu wrote:
    > Hi Naoto,
    > 
    > Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/
    > 
    > Letu
    > 
    > On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    > 
    >      Looks good.
    >      
    >      Naoto
    >      
    >      On 11/22/19 9:55 PM, Yang, Letu wrote:
    >      > Hi Naoto,
    >      >
    >      > Added it in the new webrev
    >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!
    >      >
    >      > Letu
    >      >
    >      >
    >      > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
    >      > Hi Letu,
    >      >
    >      > You might want to add lines for "Turkey" zone as well in LocaleData?
    >      >
    >      > Naoto
    >      >
    >      > On 11/22/19 4:16 PM, Yang, Letu wrote:
    >      >> Hi Naoto,
    >      >>
    >      >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
    >      >>
    >      >> Letu
    >      >>
    >      >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >      >>
    >      >>      Hi Letu,
    >      >>
    >      >>      The change in the resource bundle file looks good.
    >      >>
    >      >>      As to the regression test, I would avoid adding a separate file, instead
    >      >>      add some variations for
    >      >>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
    >      >>      some lines in "LocaleData" file, which contains the expected resources
    >      >>      for the COMPAT locale provider.
    >      >>
    >      >>      Naoto
    >      >>
    >      >>      On 11/20/19 9:43 PM, Yang, Letu wrote:
    >      >>      > Hi Naoto,
    >      >>      >
    >      >>      > Thank you for the suggestions!
    >      >>      >
    >      >>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
    >      >>      >
    >      >>      > Letu
    >      >>      >
    >      >>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >      >>      >
    >      >>      >      Hi Letu,
    >      >>      >
    >      >>      >      Here are my comments to your changes:
    >      >>      >
    >      >>      >      - You will need a regression test for this fix. Take a look at
    >      >>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
    >      >>      >      test cases.
    >      >>      >
    >      >>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
    >      >>      >
    >      >>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
    >      >>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
    >      >>      >      DST, names in those slots should reflect the DST (consistent to other names)
    >      >>      >
    >      >>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
    >      >>      >
    >      >>      >      Naoto
    >      >>      >
    >      >>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
    >      >>      >
    >      >>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
    >      >>      >      > Hi Naoto,
    >      >>      >      >
    >      >>      >      > Thank you for the clarification!
    >      >>      >      >
    >      >>      >      > Xin from my team has filed a JBS and uploaded my webrev:
    >      >>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
    >      >>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
    >      >>      >      >
    >      >>      >      > Letu
    >      >>      >      >
    >      >>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
    >      >>      >      >
    >      >>      >      >      Letu,
    >      >>      >      >
    >      >>      >      >      Please go ahead and fix the issue in English resource. As to the
    >      >>      >      >      translation, Oracle l10n will translate it in appropriate locales.
    >      >>      >      >
    >      >>      >      >      Naoto
    >      >>      >      >
    >      >>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
    >      >>      >      >      > Hi Naoto
    >      >>      >      >      >
    >      >>      >      >      > Thank you for the quick response! We will file a ticket later today.
    >      >>      >      >      >
    >      >>      >      >      > Shall we make an effort on fixing and translating the strings, or you
    >      >>      >      >      > prefer to take care of it at Oracle?
    >      >>      >      >      >
    >      >>      >      >      > Letu
    >      >>      >      >      >
    >      >>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
    >      >>      >      >      > Hi Letu,
    >      >>      >      >      >
    >      >>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
    >      >>      >      >      > java.util:i18n).
    >      >>      >      >      >
    >      >>      >      >      > Naoto
    >      >>      >      >      >
    >      >>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
    >      >>      >      >      >> Hi,
    >      >>      >      >      >>
    >      >>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been  updated yet:
    >      >>      >      >      >>
    >      >>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
    >      >>      >      >      >>
    >      >>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul".  This also need to  be updated for other locales. I can create a JBS
    >      > issue for this, but I
    >      >>      >      >      > am not sure whether we should fix this bug, or there is an existing
    >      >>      >      >      > procedure for this kind of bug which requires language translation.
    >      >>      >      >      >>
    >      >>      >      >      >> Letu
    >      >>      >      >      >>
    >      >>      >      >      >>
    >      >>      >      >      >>
    >      >>      >      >
    >      >>      >      >
    >      >>      >
    >      >>      >
    >      >>
    >      >>
    >      
    > 
    


From naoto.sato at oracle.com  Mon Dec  9 18:19:13 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 9 Dec 2019 10:19:13 -0800
Subject: <i18n dev> Turkish Time Zone name string and translation
In-Reply-To: <B3BCE271-102B-42AE-A26B-653C1997B82A@amazon.com>
References: <5129CE88-0769-4818-AE91-6F7A2E31B55A@amazon.com>
 <cee1b02d-d252-3127-0c37-8065e64a7b13@oracle.com>
 <8b72d6d1-3997-42a6-a196-f60a5130bc49@amazon.com>
 <7a9733d5-b9fd-a068-702c-f5b0ed903e5e@oracle.com>
 <B4624C9F-CEE6-47ED-A590-7221301D3610@amazon.com>
 <95b0ed5b-8e44-7aad-3f64-4bb00c2fa4f5@oracle.com>
 <99070CC7-3197-4E3D-BC25-4CC0A459CBBA@amazon.com>
 <863d66ad-deaf-1ffc-aded-d1485cf8b213@oracle.com>
 <862256B3-5F3F-45C5-9591-8BAAC641D22C@amazon.com>
 <d036620c-eb50-164b-1589-d3247cf71835@oracle.com>
 <32588966-0750-4916-8583-a4af328ecbcd@amazon.com>
 <0f89d195-5c5e-8a70-ab08-a0aa87e3a0e5@oracle.com>
 <8DF196E0-B8A9-4F43-AF7C-28B8693B4F6F@amazon.com>
 <808652e1-9df7-c2f0-e937-864bbb99835a@oracle.com>
 <B3BCE271-102B-42AE-A26B-653C1997B82A@amazon.com>
Message-ID: <0492c002-6698-7646-ed58-f98a9b85724a@oracle.com>

Hi Letu,

Those translation drops are usually integrated at the end of the 
development cycle, such as (for JDK 13):

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

And I don't think the issue is created for JDK 14 yet.

Naoto

On 12/9/19 10:04 AM, Yang, Letu wrote:
> Thanks Naoto!
> 
> Is there a separate ticket for the translation to other locales?
> 
> Letu
> 
> ?On 12/4/19, 12:36 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
> 
>      Looks good, assuming the change between 03 and 04 is to fix "no new line..."
>      
>      Naoto
>      
>      On 12/4/19 11:38 AM, Yang, Letu wrote:
>      > Hi Naoto,
>      >
>      > Can you review and approve the webrev? Thanks! https://cr.openjdk.java.net/~xliu/8234288/webrev.04/
>      >
>      > Letu
>      >
>      > On 11/23/19, 6:09 PM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >
>      >      Looks good.
>      >
>      >      Naoto
>      >
>      >      On 11/22/19 9:55 PM, Yang, Letu wrote:
>      >      > Hi Naoto,
>      >      >
>      >      > Added it in the new webrev
>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.03/ . Thanks!
>      >      >
>      >      > Letu
>      >      >
>      >      >
>      >      > On Nov 22, 2019 4:40 PM, naoto.sato at oracle.com wrote:
>      >      > Hi Letu,
>      >      >
>      >      > You might want to add lines for "Turkey" zone as well in LocaleData?
>      >      >
>      >      > Naoto
>      >      >
>      >      > On 11/22/19 4:16 PM, Yang, Letu wrote:
>      >      >> Hi Naoto,
>      >      >>
>      >      >> Thank you for the advice! I've uploaded a new version: https://cr.openjdk.java.net/~xliu/8234288/webrev.02/webrev/
>      >      >>
>      >      >> Letu
>      >      >>
>      >      >> On 11/21/19, 9:18 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >      >>
>      >      >>      Hi Letu,
>      >      >>
>      >      >>      The change in the resource bundle file looks good.
>      >      >>
>      >      >>      As to the regression test, I would avoid adding a separate file, instead
>      >      >>      add some variations for
>      >      >>      open/test/jdk/sun/text/resources/LocaleDataTest.java as I mentioned. Add
>      >      >>      some lines in "LocaleData" file, which contains the expected resources
>      >      >>      for the COMPAT locale provider.
>      >      >>
>      >      >>      Naoto
>      >      >>
>      >      >>      On 11/20/19 9:43 PM, Yang, Letu wrote:
>      >      >>      > Hi Naoto,
>      >      >>      >
>      >      >>      > Thank you for the suggestions!
>      >      >>      >
>      >      >>      > I've added a new webrev: https://cr.openjdk.java.net/~xliu/8234288/webrev.01/
>      >      >>      >
>      >      >>      > Letu
>      >      >>      >
>      >      >>      > On 11/18/19, 9:09 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >      >>      >
>      >      >>      >      Hi Letu,
>      >      >>      >
>      >      >>      >      Here are my comments to your changes:
>      >      >>      >
>      >      >>      >      - You will need a regression test for this fix. Take a look at
>      >      >>      >      test/jdk/sun/text/resources/LocaleDataTest.java, and add appropriate
>      >      >>      >      test cases.
>      >      >>      >
>      >      >>      >      - Fix comment should follow the OpenJDK changeset guideline [1]
>      >      >>      >
>      >      >>      >      - As to the change itself, I would put "Turkey Summer Time"/"TRST" for
>      >      >>      >      the 3rd and 4th array elements. Even though Turkey time do not observe
>      >      >>      >      DST, names in those slots should reflect the DST (consistent to other names)
>      >      >>      >
>      >      >>      >      - time zone id "Turkey" (line 1050) should also point to TRT array.
>      >      >>      >
>      >      >>      >      Naoto
>      >      >>      >
>      >      >>      >      [1] http://openjdk.java.net/guide/producingChangeset.html
>      >      >>      >
>      >      >>      >      On 11/17/19 8:54 PM, Yang, Letu wrote:
>      >      >>      >      > Hi Naoto,
>      >      >>      >      >
>      >      >>      >      > Thank you for the clarification!
>      >      >>      >      >
>      >      >>      >      > Xin from my team has filed a JBS and uploaded my webrev:
>      >      >>      >      > https://bugs.openjdk.java.net/browse/JDK-8234288
>      >      >>      >      > https://cr.openjdk.java.net/~xliu/8234288/webrev.00/
>      >      >>      >      >
>      >      >>      >      > Letu
>      >      >>      >      >
>      >      >>      >      > On 11/16/19, 6:44 AM, "naoto.sato at oracle.com" <naoto.sato at oracle.com> wrote:
>      >      >>      >      >
>      >      >>      >      >      Letu,
>      >      >>      >      >
>      >      >>      >      >      Please go ahead and fix the issue in English resource. As to the
>      >      >>      >      >      translation, Oracle l10n will translate it in appropriate locales.
>      >      >>      >      >
>      >      >>      >      >      Naoto
>      >      >>      >      >
>      >      >>      >      >      On 11/15/19 5:56 PM, Yang, Letu wrote:
>      >      >>      >      >      > Hi Naoto
>      >      >>      >      >      >
>      >      >>      >      >      > Thank you for the quick response! We will file a ticket later today.
>      >      >>      >      >      >
>      >      >>      >      >      > Shall we make an effort on fixing and translating the strings, or you
>      >      >>      >      >      > prefer to take care of it at Oracle?
>      >      >>      >      >      >
>      >      >>      >      >      > Letu
>      >      >>      >      >      >
>      >      >>      >      >      > On Nov 15, 2019 4:29 PM, naoto.sato at oracle.com wrote:
>      >      >>      >      >      > Hi Letu,
>      >      >>      >      >      >
>      >      >>      >      >      > Please file a JBS issue for this (component: core-libs, subcomponent:
>      >      >>      >      >      > java.util:i18n).
>      >      >>      >      >      >
>      >      >>      >      >      > Naoto
>      >      >>      >      >      >
>      >      >>      >      >      > On 11/15/19 3:19 PM, Yang, Letu wrote:
>      >      >>      >      >      >> Hi,
>      >      >>      >      >      >>
>      >      >>      >      >      >> We recently found an issue with the Time Zone name for ?Europe/Istanbul? and "Asian/Istanbul". Since Turkey moved to their own Turkish Time (TRT) zone in 2016, although the tzdata had been updated, the Time Zone name string has not been  updated yet:
>      >      >>      >      >      >>
>      >      >>      >      >      >> https://hg.openjdk.java.net/jdk/jdk/file/8e7f29b1ad4a/src/java.base/share/classes/sun/util/resources/TimeZoneNames.java#l836
>      >      >>      >      >      >>
>      >      >>      >      >      >> It still returns "Eastern European Time" for the TimeZone.getDisplayName call, which has a summer time while Turkish Time does not. An entry for TRT need to be added to this file, and assign to both "Europe/Istanbul" and "Asian/Istanbul".  This also need to  be updated for other locales. I can create a JBS
>      >      > issue for this, but I
>      >      >>      >      >      > am not sure whether we should fix this bug, or there is an existing
>      >      >>      >      >      > procedure for this kind of bug which requires language translation.
>      >      >>      >      >      >>
>      >      >>      >      >      >> Letu
>      >      >>      >      >      >>
>      >      >>      >      >      >>
>      >      >>      >      >      >>
>      >      >>      >      >
>      >      >>      >      >
>      >      >>      >
>      >      >>      >
>      >      >>
>      >      >>
>      >
>      >
>      
> 

From naoto.sato at oracle.com  Wed Dec 11 21:21:17 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 11 Dec 2019 13:21:17 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any custom
 TimeZoneNameProvider
Message-ID: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>

Hi,

Please review the fix for the following issue:

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

The proposed changeset is located at:

https://cr.openjdk.java.net/~naoto/8235238/webrev.00/

The fix will retrieve the custom zone names from the time zone name 
provider, for the custom ZoneRulesProvider implementations.

Naoto

From huizhe.wang at oracle.com  Thu Dec 12 19:32:03 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 12 Dec 2019 11:32:03 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
Message-ID: <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>

Hi Naoto,

Does the new code block, 4156 - 4174, need a conditional statement, that 
is when it's for a standard timezon? Before this change, or before a 
custom TimeZoneNameProvider is attempted, the process didn't need to 
loop through regionIds to add display names.

Thanks,
Joe

On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8235238
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>
> The fix will retrieve the custom zone names from the time zone name 
> provider, for the custom ZoneRulesProvider implementations.
>
> Naoto


From naoto.sato at oracle.com  Thu Dec 12 20:31:32 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 12 Dec 2019 12:31:32 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
 <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
Message-ID: <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>

Hi Joe,

Thank you for the review.

The original code loops through zoneStrings array, and if the id exists 
in regionIds, then adds their display names in the tree (4142-4154). 
This process is not altered with my change. My change made regionIds 
mutable (line 4127) so that after the loop, it only contains custom ids 
by calling remove() (line 4144). Thus the new added block will only 
retrieve names for custom ids. Or am I missing something in your comment?

Naoto

On 12/12/19 11:32 AM, Joe Wang wrote:
> Hi Naoto,
> 
> Does the new code block, 4156 - 4174, need a conditional statement, that 
> is when it's for a standard timezon? Before this change, or before a 
> custom TimeZoneNameProvider is attempted, the process didn't need to 
> loop through regionIds to add display names.
> 
> Thanks,
> Joe
> 
> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8235238
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>>
>> The fix will retrieve the custom zone names from the time zone name 
>> provider, for the custom ZoneRulesProvider implementations.
>>
>> Naoto
> 

From huizhe.wang at oracle.com  Thu Dec 12 20:42:58 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 12 Dec 2019 12:42:58 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
 <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
 <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>
Message-ID: <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com>



On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thank you for the review.
>
> The original code loops through zoneStrings array, and if the id 
> exists in regionIds, then adds their display names in the tree 
> (4142-4154). This process is not altered with my change. My change 
> made regionIds mutable (line 4127) so that after the loop, it only 
> contains custom ids by calling remove() (line 4144). Thus the new 
> added block will only retrieve names for custom ids. Or am I missing 
> something in your comment?

Ok, that's what I was looking for. Thanks for the explanation. The 
changes look good to me then.

Best,
Joe

>
> Naoto
>
> On 12/12/19 11:32 AM, Joe Wang wrote:
>> Hi Naoto,
>>
>> Does the new code block, 4156 - 4174, need a conditional statement, 
>> that is when it's for a standard timezon? Before this change, or 
>> before a custom TimeZoneNameProvider is attempted, the process didn't 
>> need to loop through regionIds to add display names.
>>
>> Thanks,
>> Joe
>>
>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix for the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8235238
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>>>
>>> The fix will retrieve the custom zone names from the time zone name 
>>> provider, for the custom ZoneRulesProvider implementations.
>>>
>>> Naoto
>>


From naoto.sato at oracle.com  Thu Dec 12 22:07:15 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 12 Dec 2019 14:07:15 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
 <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
 <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>
 <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com>
 <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com>
Message-ID: <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com>

Sorry, I seem to have posted an old webrev, which included unnecessary 
retrieval of the generic name (4168-4173 in v.00). Here is the correct 
webrev:

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

Naoto



On 12/12/19 1:37 PM, Roger Riggs wrote:
> +1
> 
> There's quite a bit of work being done to get the eligible stings
> as part of each parse but it doesn't look easy to re-use it acrosses 
> parses.
> 
> Roger
> 
> 
> On 12/12/19 3:42 PM, Joe Wang wrote:
>>
>>
>> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for the review.
>>>
>>> The original code loops through zoneStrings array, and if the id 
>>> exists in regionIds, then adds their display names in the tree 
>>> (4142-4154). This process is not altered with my change. My change 
>>> made regionIds mutable (line 4127) so that after the loop, it only 
>>> contains custom ids by calling remove() (line 4144). Thus the new 
>>> added block will only retrieve names for custom ids. Or am I missing 
>>> something in your comment?
>>
>> Ok, that's what I was looking for. Thanks for the explanation. The 
>> changes look good to me then.
>>
>> Best,
>> Joe
>>
>>>
>>> Naoto
>>>
>>> On 12/12/19 11:32 AM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> Does the new code block, 4156 - 4174, need a conditional statement, 
>>>> that is when it's for a standard timezon? Before this change, or 
>>>> before a custom TimeZoneNameProvider is attempted, the process 
>>>> didn't need to loop through regionIds to add display names.
>>>>
>>>> Thanks,
>>>> Joe
>>>>
>>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix for the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8235238
>>>>>
>>>>> The proposed changeset is located at:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>>>>>
>>>>> The fix will retrieve the custom zone names from the time zone name 
>>>>> provider, for the custom ZoneRulesProvider implementations.
>>>>>
>>>>> Naoto
>>>>
>>
> 

From huizhe.wang at oracle.com  Fri Dec 13 00:38:25 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 12 Dec 2019 16:38:25 -0800
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
 <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
 <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>
 <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com>
 <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com>
 <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com>
Message-ID: <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com>

+1

-Joe

On 12/12/19 2:07 PM, naoto.sato at oracle.com wrote:
> Sorry, I seem to have posted an old webrev, which included unnecessary 
> retrieval of the generic name (4168-4173 in v.00). Here is the correct 
> webrev:
>
> http://cr.openjdk.java.net/~naoto/8235238/webrev.01/
>
> Naoto
>
>
>
> On 12/12/19 1:37 PM, Roger Riggs wrote:
>> +1
>>
>> There's quite a bit of work being done to get the eligible stings
>> as part of each parse but it doesn't look easy to re-use it acrosses 
>> parses.
>>
>> Roger
>>
>>
>> On 12/12/19 3:42 PM, Joe Wang wrote:
>>>
>>>
>>> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote:
>>>> Hi Joe,
>>>>
>>>> Thank you for the review.
>>>>
>>>> The original code loops through zoneStrings array, and if the id 
>>>> exists in regionIds, then adds their display names in the tree 
>>>> (4142-4154). This process is not altered with my change. My change 
>>>> made regionIds mutable (line 4127) so that after the loop, it only 
>>>> contains custom ids by calling remove() (line 4144). Thus the new 
>>>> added block will only retrieve names for custom ids. Or am I 
>>>> missing something in your comment?
>>>
>>> Ok, that's what I was looking for. Thanks for the explanation. The 
>>> changes look good to me then.
>>>
>>> Best,
>>> Joe
>>>
>>>>
>>>> Naoto
>>>>
>>>> On 12/12/19 11:32 AM, Joe Wang wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> Does the new code block, 4156 - 4174, need a conditional 
>>>>> statement, that is when it's for a standard timezon? Before this 
>>>>> change, or before a custom TimeZoneNameProvider is attempted, the 
>>>>> process didn't need to loop through regionIds to add display names.
>>>>>
>>>>> Thanks,
>>>>> Joe
>>>>>
>>>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the fix for the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235238
>>>>>>
>>>>>> The proposed changeset is located at:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>>>>>>
>>>>>> The fix will retrieve the custom zone names from the time zone 
>>>>>> name provider, for the custom ZoneRulesProvider implementations.
>>>>>>
>>>>>> Naoto
>>>>>
>>>
>>


From Roger.Riggs at oracle.com  Fri Dec 13 16:02:25 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 13 Dec 2019 11:02:25 -0500
Subject: <i18n dev> RFR 8235238: Parsing a time string ignores any
 custom TimeZoneNameProvider
In-Reply-To: <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com>
References: <9898004b-5baa-0742-1618-b6f01d870b53@oracle.com>
 <6c9f7efe-05b6-db6a-f9b3-f6b52cdd87a6@oracle.com>
 <423f53cc-4f34-a501-29d6-f1380be15d6f@oracle.com>
 <0af76911-a739-8e0f-388b-e1150706cfad@oracle.com>
 <575d2d94-b0e6-2380-9520-95ae2c3d2e30@oracle.com>
 <9e8bd341-ab69-1a85-6c4f-3a9252b8ecc7@oracle.com>
 <47fd5e55-5ed7-08a8-75c2-a2b2d145dde2@oracle.com>
Message-ID: <15352625-2b93-d56e-c0c8-31ab5f288dbb@oracle.com>

+1

On 12/12/19 7:38 PM, Joe Wang wrote:
> +1
>
> -Joe
>
> On 12/12/19 2:07 PM, naoto.sato at oracle.com wrote:
>> Sorry, I seem to have posted an old webrev, which included 
>> unnecessary retrieval of the generic name (4168-4173 in v.00). Here 
>> is the correct webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8235238/webrev.01/
>>
>> Naoto
>>
>>
>>
>> On 12/12/19 1:37 PM, Roger Riggs wrote:
>>> +1
>>>
>>> There's quite a bit of work being done to get the eligible stings
>>> as part of each parse but it doesn't look easy to re-use it acrosses 
>>> parses.
>>>
>>> Roger
>>>
>>>
>>> On 12/12/19 3:42 PM, Joe Wang wrote:
>>>>
>>>>
>>>> On 12/12/19 12:31 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Thank you for the review.
>>>>>
>>>>> The original code loops through zoneStrings array, and if the id 
>>>>> exists in regionIds, then adds their display names in the tree 
>>>>> (4142-4154). This process is not altered with my change. My change 
>>>>> made regionIds mutable (line 4127) so that after the loop, it only 
>>>>> contains custom ids by calling remove() (line 4144). Thus the new 
>>>>> added block will only retrieve names for custom ids. Or am I 
>>>>> missing something in your comment?
>>>>
>>>> Ok, that's what I was looking for. Thanks for the explanation. The 
>>>> changes look good to me then.
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 12/12/19 11:32 AM, Joe Wang wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> Does the new code block, 4156 - 4174, need a conditional 
>>>>>> statement, that is when it's for a standard timezon? Before this 
>>>>>> change, or before a custom TimeZoneNameProvider is attempted, the 
>>>>>> process didn't need to loop through regionIds to add display names.
>>>>>>
>>>>>> Thanks,
>>>>>> Joe
>>>>>>
>>>>>> On 12/11/19 1:21 PM, naoto.sato at oracle.com wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the fix for the following issue:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235238
>>>>>>>
>>>>>>> The proposed changeset is located at:
>>>>>>>
>>>>>>> https://cr.openjdk.java.net/~naoto/8235238/webrev.00/
>>>>>>>
>>>>>>> The fix will retrieve the custom zone names from the time zone 
>>>>>>> name provider, for the custom ZoneRulesProvider implementations.
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>
>>>
>


From naoto.sato at oracle.com  Fri Dec 20 20:57:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 20 Dec 2019 12:57:00 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping separator
 in DecimalFormat/DecimalFormatSymbols
Message-ID: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>

Hi,

Please review the fix for the following issue:

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

The proposed CSR and changeset are located at:

https://bugs.openjdk.java.net/browse/JDK-8235942
https://cr.openjdk.java.net/~naoto/8227313/webrev.00/

The change introduces the new monetary grouping separator in 
DecimalFormatSymbols, and it is used if a DecimalFormat instance 
designates currency formatting where its pattern includes the currency 
symbol (U+00A5). The change makes use of the CLDR data which provides 
two distinct grouping separators (one for generic, the other for 
currency) in some locales. It also addresses the similar cases for the 
decimal separator.

Naoto

From huizhe.wang at oracle.com  Tue Dec 24 01:20:41 2019
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 23 Dec 2019 17:20:41 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
Message-ID: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>

Hi Naoto,

Is there a need for an APINote to note the relationship between the new 
get/setMonetaryGroupingSeparator and get/setGroupingSeparator methods. 
The new method did state it "May be different from {@code grouping 
separator} in some locales", but that may be insufficient. For example, 
does setting one method affects the other (seems it should since the 
monetaryGroupingSeparator may be initialized by the groupingSeparator as 
the impl shows)? If yes, how it's affected?

If no, is there a compatibility concern? In the current impl, the new 
get method is used when "isCurrencyFormat" is true while the new set 
method doesn't affect the existing 'groupingSeparator'. For existing 
applications that have a custom grouping separator set through 
setGroupingSeparator, it seems to me the custom separator won't be used 
moving onto the new JDK impl.


A minor comment about the definition statement in the following:

 ??? Add the following new serializable field 
in|java.text.DecimalFormatSymbols|class:

|/** * The grouping separator used when formatting currency values. * * 
@serial * @since 15 */ private char monetaryGroupingSeparator;|


and that for the new get method:
 ??????? Gets the character used for thousands separator for currencies.


While the meanings are clear, they were not as consistent as that 
between the existing groupingSeparator and its get method, that is:
 ??????? Character used for thousands separator.

 ?? and then the get method states:

 ??????? Gets the character used for thousands separator.


But this is minor, your call whether to change it or not.

Best,? and have a great Christmas! :-)
Joe

On 12/20/19 12:57 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8227313
>
> The proposed CSR and changeset are located at:
>
> https://bugs.openjdk.java.net/browse/JDK-8235942
> https://cr.openjdk.java.net/~naoto/8227313/webrev.00/
>
> The change introduces the new monetary grouping separator in 
> DecimalFormatSymbols, and it is used if a DecimalFormat instance 
> designates currency formatting where its pattern includes the currency 
> symbol (U+00A5). The change makes use of the CLDR data which provides 
> two distinct grouping separators (one for generic, the other for 
> currency) in some locales. It also addresses the similar cases for the 
> decimal separator.
>
> Naoto