From naoto.sato at oracle.com  Fri Oct  4 22:54:57 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 4 Oct 2019 15:54:57 -0700
Subject: <i18n dev> [14] RFR: DecimalFormat.setGroupingSize(int) allows
 setting negative grouping size
Message-ID: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed CSR and changeset are located at:

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

Naoto

From naoto.sato at oracle.com  Wed Oct  9 17:47:36 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 10:47:36 -0700
Subject: <i18n dev> [14] RFR 8212749: DecimalFormat.setGroupingSize(int)
 allows setting negative grouping size,
 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)
In-Reply-To: <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
Message-ID: <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>

I revised the fix, incorporating the clarification of the value zero as 
the grouping size, which has separate JIRA issue and CSR as follows:

https://bugs.openjdk.java.net/browse/JDK-8231984
https://bugs.openjdk.java.net/browse/JDK-8232012

The merged changeset is as follows:

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

Please review.

Naoto

On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
> Hi Roger,
> 
> Thank you for the review. In fact, Joe commented about the validity of 
> zero on the CSR, so I will need to modify the method description such as:
> 
> diff -r 9576895d0f9a 
> src/java.base/share/classes/java/text/DecimalFormat.java
> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
> @@ -2770,10 +2770,13 @@
>  ???? /**
>  ????? * Set the grouping size. Grouping size is the number of digits 
> between
>  ????? * grouping separators in the integer portion of a number.? For 
> example,
> -???? * in the number "123,456.78", the grouping size is 3.
> -???? * <br>
> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
> size of
> +???? * zero designates that grouping is not used, which provides the same
> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
> +???? * setGroupingUsed(false)}.
> +???? * <p>
>  ????? * The value passed in is converted to a byte, which may lose 
> information.
> -???? * Invalid value, i.e., negative or greater than
> +???? * Values that are negative or greater than
>  ????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>  ????? * {@code IllegalArgumentException}.
>  ????? *
> 
> I will file a follow-on CSR and merge changesets.
> 
> Naoto
> 
> On 10/8/19 6:59 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>
>> Otherwise looks fine. No need for another webrev.
>>
>> Thanks, Roger
>>
>>
>>
>>
>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>
>>> The proposed CSR and changeset are located at:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>
>>> Naoto
>>

From naoto.sato at oracle.com  Wed Oct  9 22:39:50 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 15:39:50 -0700
Subject: <i18n dev> [14] RFR: 8231273: Upgrade CLDR to v36
Message-ID: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

The webrev is huge, but majority of the changes is just to replace the 
CLDR source locale data from version 35.1 to 36. The real code changes 
are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
handles aliases for currency/percent formats, and retrieves per-element 
fallback strings for compact number patterns. Also relevant tests are 
modified accordingly.

Naoto

From naoto.sato at oracle.com  Wed Oct  9 22:45:55 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 9 Oct 2019 15:45:55 -0700
Subject: <i18n dev> [14] RFR: 8225435: Upgrade IANA Language Subtag Registry
 to the latest for JDK14
Message-ID: <b86c7fa1-5c81-4d2f-3a4d-d6978216ceeb@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

The change is to upgrade the data file to the latest (dated 2019-09-16). 
A relevant test case is modified accordingly.

Naoto

From Roger.Riggs at oracle.com  Fri Oct 11 17:41:47 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 11 Oct 2019 13:41:47 -0400
Subject: <i18n dev> [14] RFR 8212749: DecimalFormat.setGroupingSize(int)
 allows setting negative grouping size,
 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)
In-Reply-To: <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
Message-ID: <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>

Hi Naoto,

The javadoc/spec comments look fine.

Code comments at DecimalFormat:4035 give some latitute for the value to be
out of range and since getGroupingSize returns the groupingSize byte
it would be cleaner if the value was always in the valid range
regardless of the isGroupingUsed boolean.

Can there be code in the readObject method to correct out of range
values, perhaps to the default = 3?

Thanks, Roger



On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
> I revised the fix, incorporating the clarification of the value zero 
> as the grouping size, which has separate JIRA issue and CSR as follows:
>
> https://bugs.openjdk.java.net/browse/JDK-8231984
> https://bugs.openjdk.java.net/browse/JDK-8232012
>
> The merged changeset is as follows:
>
> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>
> Please review.
>
> Naoto
>
> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>> Hi Roger,
>>
>> Thank you for the review. In fact, Joe commented about the validity 
>> of zero on the CSR, so I will need to modify the method description 
>> such as:
>>
>> diff -r 9576895d0f9a 
>> src/java.base/share/classes/java/text/DecimalFormat.java
>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>> @@ -2770,10 +2770,13 @@
>> ????? /**
>> ?????? * Set the grouping size. Grouping size is the number of digits 
>> between
>> ?????? * grouping separators in the integer portion of a number.? For 
>> example,
>> -???? * in the number "123,456.78", the grouping size is 3.
>> -???? * <br>
>> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
>> size of
>> +???? * zero designates that grouping is not used, which provides the 
>> same
>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>> +???? * setGroupingUsed(false)}.
>> +???? * <p>
>> ?????? * The value passed in is converted to a byte, which may lose 
>> information.
>> -???? * Invalid value, i.e., negative or greater than
>> +???? * Values that are negative or greater than
>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>> ?????? * {@code IllegalArgumentException}.
>> ?????? *
>>
>> I will file a follow-on CSR and merge changesets.
>>
>> Naoto
>>
>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>>
>>> Otherwise looks fine. No need for another webrev.
>>>
>>> Thanks, Roger
>>>
>>>
>>>
>>>
>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>
>>>> The proposed CSR and changeset are located at:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>
>>>> Naoto
>>>


From naoto.sato at oracle.com  Fri Oct 11 20:15:48 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 11 Oct 2019 13:15:48 -0700
Subject: <i18n dev> [14] RFR 8212749: DecimalFormat.setGroupingSize(int)
 allows setting negative grouping size,
 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)
In-Reply-To: <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
 <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
Message-ID: <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>

Thanks, Roger. Modified readObject() accordingly:

https://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.01/

Naoto

On 10/11/19 10:41 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> The javadoc/spec comments look fine.
> 
> Code comments at DecimalFormat:4035 give some latitute for the value to be
> out of range and since getGroupingSize returns the groupingSize byte
> it would be cleaner if the value was always in the valid range
> regardless of the isGroupingUsed boolean.
> 
> Can there be code in the readObject method to correct out of range
> values, perhaps to the default = 3?
> 
> Thanks, Roger
> 
> 
> 
> On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
>> I revised the fix, incorporating the clarification of the value zero 
>> as the grouping size, which has separate JIRA issue and CSR as follows:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231984
>> https://bugs.openjdk.java.net/browse/JDK-8232012
>>
>> The merged changeset is as follows:
>>
>> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>>
>> Please review.
>>
>> Naoto
>>
>> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>>> Hi Roger,
>>>
>>> Thank you for the review. In fact, Joe commented about the validity 
>>> of zero on the CSR, so I will need to modify the method description 
>>> such as:
>>>
>>> diff -r 9576895d0f9a 
>>> src/java.base/share/classes/java/text/DecimalFormat.java
>>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>>> @@ -2770,10 +2770,13 @@
>>> ????? /**
>>> ?????? * Set the grouping size. Grouping size is the number of digits 
>>> between
>>> ?????? * grouping separators in the integer portion of a number.? For 
>>> example,
>>> -???? * in the number "123,456.78", the grouping size is 3.
>>> -???? * <br>
>>> +???? * in the number "123,456.78", the grouping size is 3. Grouping 
>>> size of
>>> +???? * zero designates that grouping is not used, which provides the 
>>> same
>>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>>> +???? * setGroupingUsed(false)}.
>>> +???? * <p>
>>> ?????? * The value passed in is converted to a byte, which may lose 
>>> information.
>>> -???? * Invalid value, i.e., negative or greater than
>>> +???? * Values that are negative or greater than
>>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will throw an
>>> ?????? * {@code IllegalArgumentException}.
>>> ?????? *
>>>
>>> I will file a follow-on CSR and merge changesets.
>>>
>>> Naoto
>>>
>>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that are".
>>>>
>>>> Otherwise looks fine. No need for another webrev.
>>>>
>>>> Thanks, Roger
>>>>
>>>>
>>>>
>>>>
>>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>>
>>>>> The proposed CSR and changeset are located at:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>>
>>>>> Naoto
>>>>
> 

From takiguc at linux.vnet.ibm.com  Mon Oct 14 15:53:59 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 15 Oct 2019 00:53:59 +0900
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion entries on
 MS950 charset
Message-ID: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>

Hello.

Could you review the fix ?

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

I have a concern about 1-way trip conversion entries (4 entries) on 
MS950 charset.
The detail information is in JDK-8232161 [1]

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

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From Roger.Riggs at oracle.com  Tue Oct 15 15:55:25 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Tue, 15 Oct 2019 11:55:25 -0400
Subject: <i18n dev> [14] RFR 8212749: DecimalFormat.setGroupingSize(int)
 allows setting negative grouping size,
 8231984: Clarify semantics of DecimalFormat.getGroupingSize(0)
In-Reply-To: <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>
References: <d8220664-c085-fb00-adf8-ecdbe9422b33@oracle.com>
 <7754d088-931b-6e49-6d21-9d5bb0045f75@oracle.com>
 <8c08a899-6bbb-8e29-2136-9ba8c8f477b8@oracle.com>
 <ad93a9cd-c76f-f39c-c887-50d2fad51ed7@oracle.com>
 <67f885c4-1a96-9ca6-d3ba-703aed7deceb@oracle.com>
 <33618d5c-7696-f3ba-2f78-590b0802504e@oracle.com>
Message-ID: <b4470f69-df8b-fbdb-a66c-1e5a8b8a50b8@oracle.com>

Looks good.

Thanks,? Roger

On 10/11/19 4:15 PM, naoto.sato at oracle.com wrote:
> Thanks, Roger. Modified readObject() accordingly:
>
> https://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.01/
>
> Naoto
>
> On 10/11/19 10:41 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> The javadoc/spec comments look fine.
>>
>> Code comments at DecimalFormat:4035 give some latitute for the value 
>> to be
>> out of range and since getGroupingSize returns the groupingSize byte
>> it would be cleaner if the value was always in the valid range
>> regardless of the isGroupingUsed boolean.
>>
>> Can there be code in the readObject method to correct out of range
>> values, perhaps to the default = 3?
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/9/19 1:47 PM, naoto.sato at oracle.com wrote:
>>> I revised the fix, incorporating the clarification of the value zero 
>>> as the grouping size, which has separate JIRA issue and CSR as follows:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231984
>>> https://bugs.openjdk.java.net/browse/JDK-8232012
>>>
>>> The merged changeset is as follows:
>>>
>>> http://cr.openjdk.java.net/~naoto/8212749.8231984/webrev.00/
>>>
>>> Please review.
>>>
>>> Naoto
>>>
>>> On 10/8/19 8:59 AM, naoto.sato at oracle.com wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for the review. In fact, Joe commented about the validity 
>>>> of zero on the CSR, so I will need to modify the method description 
>>>> such as:
>>>>
>>>> diff -r 9576895d0f9a 
>>>> src/java.base/share/classes/java/text/DecimalFormat.java
>>>> --- a/src/java.base/share/classes/java/text/DecimalFormat.java
>>>> +++ b/src/java.base/share/classes/java/text/DecimalFormat.java
>>>> @@ -2770,10 +2770,13 @@
>>>> ????? /**
>>>> ?????? * Set the grouping size. Grouping size is the number of 
>>>> digits between
>>>> ?????? * grouping separators in the integer portion of a number.? 
>>>> For example,
>>>> -???? * in the number "123,456.78", the grouping size is 3.
>>>> -???? * <br>
>>>> +???? * in the number "123,456.78", the grouping size is 3. 
>>>> Grouping size of
>>>> +???? * zero designates that grouping is not used, which provides 
>>>> the same
>>>> +???? * formatting as if calling {@link #setGroupingUsed(boolean)
>>>> +???? * setGroupingUsed(false)}.
>>>> +???? * <p>
>>>> ?????? * The value passed in is converted to a byte, which may lose 
>>>> information.
>>>> -???? * Invalid value, i.e., negative or greater than
>>>> +???? * Values that are negative or greater than
>>>> ?????? * {@link java.lang.Byte#MAX_VALUE Byte.MAX_VALUE}, will 
>>>> throw an
>>>> ?????? * {@code IllegalArgumentException}.
>>>> ?????? *
>>>>
>>>> I will file a follow-on CSR and merge changesets.
>>>>
>>>> Naoto
>>>>
>>>> On 10/8/19 6:59 AM, Roger Riggs wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> DecimalFormat.java: 2776:? "Invalid value, i.e.," -> "Values that 
>>>>> are".
>>>>>
>>>>> Otherwise looks fine. No need for another webrev.
>>>>>
>>>>> Thanks, Roger
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 10/4/19 6:54 PM, naoto.sato at oracle.com wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8212749
>>>>>>
>>>>>> The proposed CSR and changeset are located at:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8231851
>>>>>> https://cr.openjdk.java.net/~naoto/8212749/webrev.00/
>>>>>>
>>>>>> Naoto
>>>>>
>>


From Alan.Bateman at oracle.com  Sat Oct 19 07:36:25 2019
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 19 Oct 2019 08:36:25 +0100
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
Message-ID: <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>

On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
> Hello.
>
> Could you review the fix ?
>
> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>
> I have a concern about 1-way trip conversion entries (4 entries) on 
> MS950 charset.
> The detail information is in JDK-8232161 [1]
>
Do you know any sense on the compatibility impact of changing this? I 
think Naoto has the same question and we aren't sure if this one with 
need a compatibility property. I think it will need a CSR.

-Alan


From naoto.sato at oracle.com  Fri Oct 25 00:51:47 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 24 Oct 2019 17:51:47 -0700
Subject: <i18n dev> [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
Message-ID: <4888a600-dfac-cd08-aa05-54255cdb4cfe@oracle.com>

Ping.

Naoto

On 10/9/19 3:39 PM, naoto.sato at oracle.com wrote:
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8231273
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
> 
> The webrev is huge, but majority of the changes is just to replace the 
> CLDR source locale data from version 35.1 to 36. The real code changes 
> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
> handles aliases for currency/percent formats, and retrieves per-element 
> fallback strings for compact number patterns. Also relevant tests are 
> modified accordingly.
> 
> Naoto

From Roger.Riggs at oracle.com  Fri Oct 25 18:57:50 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 25 Oct 2019 14:57:50 -0400
Subject: <i18n dev> [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
Message-ID: <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>

HI Naoto,

cldrconverter/Bundle.java:

233-246:? If there is a parent list, it seems to ignore/drop patterns 
greater than plist.size().
This would be clearer if it always processed all the patterns and used 
the parent
if the pattern[i] was empty and i < plist.size().? Switching around the 
range size leads to confusion.
(Or I misunderstand the intent).

Is the algorithm intended to produce the longest list (parent and pattern)?

Otherwise, looks fine.

Thanks, Roger



On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8231273
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>
> The webrev is huge, but majority of the changes is just to replace the 
> CLDR source locale data from version 35.1 to 36. The real code changes 
> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
> handles aliases for currency/percent formats, and retrieves 
> per-element fallback strings for compact number patterns. Also 
> relevant tests are modified accordingly.
>
> Naoto


From naoto.sato at oracle.com  Fri Oct 25 23:31:00 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 25 Oct 2019 16:31:00 -0700
Subject: <i18n dev> [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
 <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
Message-ID: <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>

Hi Roger,

Thanks for the review.

On 10/25/2019 AD 11:57 ??, Roger Riggs wrote:
> HI Naoto,
> 
> cldrconverter/Bundle.java:
> 
> 233-246:? If there is a parent list, it seems to ignore/drop patterns 
> greater than plist.size().
> This would be clearer if it always processed all the patterns and used 
> the parent
> if the pattern[i] was empty and i < plist.size().? Switching around the 
> range size leads to confusion.
> (Or I misunderstand the intent).

The code assumed that parents' lists are always longer than self, which 
is true, but you are right that it can be more readable. Corrected as 
follows:

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

Bundle:233-246 is the only change since 00.

> 
> Is the algorithm intended to produce the longest list (parent and pattern)?

Since at runtime, there's no way to fallback element by element basis, 
the array should always contain all the elements (i.e., longest) possible.

Naoto

> 
> Otherwise, looks fine.
> 
> Thanks, Roger
> 
> 
> 
> On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8231273
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>>
>> The webrev is huge, but majority of the changes is just to replace the 
>> CLDR source locale data from version 35.1 to 36. The real code changes 
>> are under make/jdk/src/classes/build/tools/cldrconverter, where it now 
>> handles aliases for currency/percent formats, and retrieves 
>> per-element fallback strings for compact number patterns. Also 
>> relevant tests are modified accordingly.
>>
>> Naoto
> 

From Roger.Riggs at oracle.com  Mon Oct 28 14:47:52 2019
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Mon, 28 Oct 2019 10:47:52 -0400
Subject: <i18n dev> [14] RFR: 8231273: Upgrade CLDR to v36
In-Reply-To: <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>
References: <170a669b-01c3-6b01-ad58-69f7d73ac79c@oracle.com>
 <8f28e989-cc23-23dc-efa4-2dd8ca8de284@oracle.com>
 <84da6f28-9c7b-7487-efe8-7e6ab47c5fa3@oracle.com>
Message-ID: <7f878ecf-2b13-6b81-437b-4b1a8eb7b7a8@oracle.com>

Hi Naoto,

Looks good

Thanks for the clarification, Roger

On 10/25/19 7:31 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thanks for the review.
>
> On 10/25/2019 AD 11:57 ??, Roger Riggs wrote:
>> HI Naoto,
>>
>> cldrconverter/Bundle.java:
>>
>> 233-246:? If there is a parent list, it seems to ignore/drop patterns 
>> greater than plist.size().
>> This would be clearer if it always processed all the patterns and 
>> used the parent
>> if the pattern[i] was empty and i < plist.size().? Switching around 
>> the range size leads to confusion.
>> (Or I misunderstand the intent).
>
> The code assumed that parents' lists are always longer than self, 
> which is true, but you are right that it can be more readable. 
> Corrected as follows:
>
> http://cr.openjdk.java.net/~naoto/8231273/webrev.01/
>
> Bundle:233-246 is the only change since 00.
>
>>
>> Is the algorithm intended to produce the longest list (parent and 
>> pattern)?
>
> Since at runtime, there's no way to fallback element by element basis, 
> the array should always contain all the elements (i.e., longest) 
> possible.
>
> Naoto
>
>>
>> Otherwise, looks fine.
>>
>> Thanks, Roger
>>
>>
>>
>> On 10/9/19 6:39 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8231273
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8231273/webrev.00/
>>>
>>> The webrev is huge, but majority of the changes is just to replace 
>>> the CLDR source locale data from version 35.1 to 36. The real code 
>>> changes are under make/jdk/src/classes/build/tools/cldrconverter, 
>>> where it now handles aliases for currency/percent formats, and 
>>> retrieves per-element fallback strings for compact number patterns. 
>>> Also relevant tests are modified accordingly.
>>>
>>> Naoto
>>


From takiguc at linux.vnet.ibm.com  Mon Oct 28 16:51:06 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Tue, 29 Oct 2019 01:51:06 +0900
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
Message-ID: <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>

Hello.

I have no idea about compatibility impact.

But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
These are BOX DRAWINGS characters.

2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
HORIZONTAL;;;;
255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
VERTICAL SINGLE AND RIGHT DOUBLE;;;;
2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
VERTICAL SINGLE AND LEFT DOUBLE;;;;
256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;

I don't think it was used as valuable data until now.
I think it's necessary to evaluate compatibility.

To Sato-san,
if you have any question and suggestion, please let me know.

To other reviewers,
please let me know if you have any question and concern.

Thanks,
Ichiroh Takiguchi

On 2019-10-19 16:36, Alan Bateman wrote:
> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> Could you review the fix ?
>> 
>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>> 
>> I have a concern about 1-way trip conversion entries (4 entries) on 
>> MS950 charset.
>> The detail information is in JDK-8232161 [1]
>> 
> Do you know any sense on the compatibility impact of changing this? I
> think Naoto has the same question and we aren't sure if this one with
> need a compatibility property. I think it will need a CSR.
> 
> -Alan

From naoto.sato at oracle.com  Mon Oct 28 18:03:52 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 28 Oct 2019 11:03:52 -0700
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
Message-ID: <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>

Hi Takiguchi-san,

On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> I have no idea about compatibility impact.
> 
> But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
> These are BOX DRAWINGS characters.
> 
> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
> HORIZONTAL;;;;
> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
> VERTICAL SINGLE AND RIGHT DOUBLE;;;;
> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
> VERTICAL SINGLE AND LEFT DOUBLE;;;;
> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
> 
> I don't think it was used as valuable data until now.
> I think it's necessary to evaluate compatibility.

What do you mean by "until now"? Are there customers claiming that it 
should be corrected? Since the current JDK's mapping is not incorrect 
per se (not just "best match"), I would like to know why this needs to 
be fixed now.

Naoto

> 
> To Sato-san,
> if you have any question and suggestion, please let me know.
> 
> To other reviewers,
> please let me know if you have any question and concern.
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-10-19 16:36, Alan Bateman wrote:
>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> Could you review the fix ?
>>>
>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>
>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>> MS950 charset.
>>> The detail information is in JDK-8232161 [1]
>>>
>> Do you know any sense on the compatibility impact of changing this? I
>> think Naoto has the same question and we aren't sure if this one with
>> need a compatibility property. I think it will need a CSR.
>>
>> -Alan

From takiguc at linux.vnet.ibm.com  Tue Oct 29 18:35:15 2019
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Wed, 30 Oct 2019 03:35:15 +0900
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
 <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
Message-ID: <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>

Thanks, Sato-san.

There is no special meaning to the word "until now".
I rewrote charset related testcases, then I found this issue.

I read "Frequently Asked Questions about the CSR" [1],
I tried "Create CSR" operation, but I could not determine it worked or 
not...
(Select "Create CSR" from "More" menu)
It worked ?

[1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs

Thanks,
Ichiroh Takiguchi

On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
> Hi Takiguchi-san,
> 
> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>> Hello.
>> 
>> I have no idea about compatibility impact.
>> 
>> But according to 
>> ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>> These are BOX DRAWINGS characters.
>> 
>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>> HORIZONTAL;;;;
>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT DOUBLE;So;0;ON;;;;;N;FORMS 
>> VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
>> VERTICAL SINGLE AND LEFT DOUBLE;;;;
>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>> 
>> I don't think it was used as valuable data until now.
>> I think it's necessary to evaluate compatibility.
> 
> What do you mean by "until now"? Are there customers claiming that it
> should be corrected? Since the current JDK's mapping is not incorrect
> per se (not just "best match"), I would like to know why this needs to
> be fixed now.
> 
> Naoto
> 
>> 
>> To Sato-san,
>> if you have any question and suggestion, please let me know.
>> 
>> To other reviewers,
>> please let me know if you have any question and concern.
>> 
>> Thanks,
>> Ichiroh Takiguchi
>> 
>> On 2019-10-19 16:36, Alan Bateman wrote:
>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>> Hello.
>>>> 
>>>> Could you review the fix ?
>>>> 
>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>> 
>>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>>> MS950 charset.
>>>> The detail information is in JDK-8232161 [1]
>>>> 
>>> Do you know any sense on the compatibility impact of changing this? I
>>> think Naoto has the same question and we aren't sure if this one with
>>> need a compatibility property. I think it will need a CSR.
>>> 
>>> -Alan

From naoto.sato at oracle.com  Wed Oct 30 16:25:21 2019
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 30 Oct 2019 09:25:21 -0700
Subject: <i18n dev> RFR: 8232161 Unexpected 1-way trip conversion
 entries on MS950 charset
In-Reply-To: <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>
References: <15742fda1558e881ca62792241b90d68@linux.vnet.ibm.com>
 <7182bb24-7e9d-c3e3-2246-a435c706fc60@oracle.com>
 <c7325c3fe01d3985cc879d2113bd9ce4@linux.vnet.ibm.com>
 <93bc5929-3995-764d-a39e-bafc7d82503a@oracle.com>
 <4573ea1e76d12d4a48f71c2536c18e62@linux.vnet.ibm.com>
Message-ID: <928774f8-9d20-bf75-fbc3-36c8a37b273c@oracle.com>

Takiguchi-san,

Personally I am reluctant to make this change. If we were to introduce 
this, it will be a different encoding from the existing MS950, so either 
1) we need a new encoding, or 2) make some switch between the encoding, 
possibly a system property. But neither seems worth doing, as :-

1) JDK's conversion is not a bug per se.
2) Seems that Unicode.org's "best fit" was introduced around 2006? (From 
the date on the unicode.org 
(https://unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit950.txt), 
so JDK's mapping predates it.
3) Those code points are not a common ones (BOX DRAWINGS), and no 
customer had a complaint about it.

Please let me know if there are some rationale for fixing it.

BTW, as to the CSR, I don't see it was created.

Naoto


On 10/29/19 11:35 AM, Ichiroh Takiguchi wrote:
> Thanks, Sato-san.
> 
> There is no special meaning to the word "until now".
> I rewrote charset related testcases, then I found this issue.
> 
> I read "Frequently Asked Questions about the CSR" [1],
> I tried "Create CSR" operation, but I could not determine it worked or 
> not...
> (Select "Create CSR" from "More" menu)
> It worked ?
> 
> [1] https://wiki.openjdk.java.net/display/csr/CSR+FAQs
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2019-10-29 03:03, naoto.sato at oracle.com wrote:
>> Hi Takiguchi-san,
>>
>> On 10/28/19 9:51 AM, Ichiroh Takiguchi wrote:
>>> Hello.
>>>
>>> I have no idea about compatibility impact.
>>>
>>> But according to ftp://ftp.unicode.org/Public/12.1.0/ucd/UnicodeData.txt
>>> These are BOX DRAWINGS characters.
>>>
>>> 2550;BOX DRAWINGS DOUBLE HORIZONTAL;So;0;ON;;;;;N;FORMS DOUBLE 
>>> HORIZONTAL;;;;
>>> 255E;BOX DRAWINGS VERTICAL SINGLE AND RIGHT 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND RIGHT DOUBLE;;;;
>>> 2561;BOX DRAWINGS VERTICAL SINGLE AND LEFT DOUBLE;So;0;ON;;;;;N;FORMS 
>>> VERTICAL SINGLE AND LEFT DOUBLE;;;;
>>> 256A;BOX DRAWINGS VERTICAL SINGLE AND HORIZONTAL 
>>> DOUBLE;So;0;ON;;;;;N;FORMS VERTICAL SINGLE AND HORIZONTAL DOUBLE;;;;
>>>
>>> I don't think it was used as valuable data until now.
>>> I think it's necessary to evaluate compatibility.
>>
>> What do you mean by "until now"? Are there customers claiming that it
>> should be corrected? Since the current JDK's mapping is not incorrect
>> per se (not just "best match"), I would like to know why this needs to
>> be fixed now.
>>
>> Naoto
>>
>>>
>>> To Sato-san,
>>> if you have any question and suggestion, please let me know.
>>>
>>> To other reviewers,
>>> please let me know if you have any question and concern.
>>>
>>> Thanks,
>>> Ichiroh Takiguchi
>>>
>>> On 2019-10-19 16:36, Alan Bateman wrote:
>>>> On 14/10/2019 16:53, Ichiroh Takiguchi wrote:
>>>>> Hello.
>>>>>
>>>>> Could you review the fix ?
>>>>>
>>>>> Bug:??? https://bugs.openjdk.java.net/browse/JDK-8232161
>>>>> Change: https://cr.openjdk.java.net/~itakiguchi/8232161/webrev.00/
>>>>>
>>>>> I have a concern about 1-way trip conversion entries (4 entries) on 
>>>>> MS950 charset.
>>>>> The detail information is in JDK-8232161 [1]
>>>>>
>>>> Do you know any sense on the compatibility impact of changing this? I
>>>> think Naoto has the same question and we aren't sure if this one with
>>>> need a compatibility property. I think it will need a CSR.
>>>>
>>>> -Alan