From naoto.sato at oracle.com  Thu Jan  2 20:50:35 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 2 Jan 2020 12:50:35 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
Message-ID: <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>

Hi Joe,

Happy new year and thanks for your comments. Please see my replies below:

On 12/23/19 5:20 PM, Joe Wang wrote:
> 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?

Setting the custom monetary grouping separator will not affect the 
existing normal grouping separator. I added the explanation in the 
method description.

> 
> 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.

Good point. Modified the compatibility risk from minimum to low with the 
explanation.

> 
> 
> 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.

Consistency is important. I replaced all occurrences of "thousands 
separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
separator(s)."

Here are the modified changeset:

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

as well as the modified CSR at the same URL.

Naoto

> 
> 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
> 

From huizhe.wang at oracle.com  Thu Jan  2 22:19:53 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Thu, 2 Jan 2020 14:19:53 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
 <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
Message-ID: <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>

Happy New Year, Naoto!

Thanks for the explanation and changes. The changeset looks good to me.

-Joe

On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Happy new year and thanks for your comments. Please see my replies below:
>
> On 12/23/19 5:20 PM, Joe Wang wrote:
>> 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?
>
> Setting the custom monetary grouping separator will not affect the 
> existing normal grouping separator. I added the explanation in the 
> method description.
>
>>
>> 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.
>
> Good point. Modified the compatibility risk from minimum to low with 
> the explanation.
>
>>
>>
>> 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.
>
> Consistency is important. I replaced all occurrences of "thousands 
> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
> separator(s)."
>
> Here are the modified changeset:
>
> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/
>
> as well as the modified CSR at the same URL.
>
> Naoto
>
>>
>> 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
>>


From naoto.sato at oracle.com  Fri Jan  3 17:23:55 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 3 Jan 2020 09:23:55 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
 <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
 <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>
Message-ID: <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com>

Hi Joe,

I revised the changeset, as the cached hash code in DecimalFormatSymbols 
needs to be recalculated when any of the relevant fields is mutated. 
Here is the updated webrev:

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

Naoto

On 1/2/20 2:19 PM, Joe Wang wrote:
> Happy New Year, Naoto!
> 
> Thanks for the explanation and changes. The changeset looks good to me.
> 
> -Joe
> 
> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> Happy new year and thanks for your comments. Please see my replies below:
>>
>> On 12/23/19 5:20 PM, Joe Wang wrote:
>>> 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?
>>
>> Setting the custom monetary grouping separator will not affect the 
>> existing normal grouping separator. I added the explanation in the 
>> method description.
>>
>>>
>>> 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.
>>
>> Good point. Modified the compatibility risk from minimum to low with 
>> the explanation.
>>
>>>
>>>
>>> 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.
>>
>> Consistency is important. I replaced all occurrences of "thousands 
>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
>> separator(s)."
>>
>> Here are the modified changeset:
>>
>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/
>>
>> as well as the modified CSR at the same URL.
>>
>> Naoto
>>
>>>
>>> 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
>>>
> 

From huizhe.wang at oracle.com  Fri Jan  3 19:40:59 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 3 Jan 2020 11:40:59 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
 <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
 <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>
 <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com>
Message-ID: <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com>

Hi Naoto,

The change looks fine to me as only monetaryGroupingSeparator was added 
to equals.

I can't help to note though that, all fields participated in the equals 
calculation except exponential. Some of the other fields are in similar 
situations (one is public and the other not), e.g. percent and 
percentText, perMill and perMillText, minusSign and minusSignText, and 
also the currency related fields, but they all are included. It looks 
like exponential was never publicly accessible, but the (1.6) added 
exponentialSeparator became public. It's probably not necessary to 
include all of them in the first place as they are in sync. that is, 
changing one would change the other -- and in this regard, exponential 
is an exception: setExponentialSymbol won't change exponential.

I understand this is all historical and it doesn't affect your 
changeset. If the reason is known, it won't hurt to add some notes as 
the other setXxxText clearly stated the relationship with their non-Text 
representation. If not, it's fine to me to not have to spend the extra time.

Best,
Joe

On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> I revised the changeset, as the cached hash code in 
> DecimalFormatSymbols needs to be recalculated when any of the relevant 
> fields is mutated. Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8227313/webrev.02/
>
> Naoto
>
> On 1/2/20 2:19 PM, Joe Wang wrote:
>> Happy New Year, Naoto!
>>
>> Thanks for the explanation and changes. The changeset looks good to me.
>>
>> -Joe
>>
>> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Happy new year and thanks for your comments. Please see my replies 
>>> below:
>>>
>>> On 12/23/19 5:20 PM, Joe Wang wrote:
>>>> 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?
>>>
>>> Setting the custom monetary grouping separator will not affect the 
>>> existing normal grouping separator. I added the explanation in the 
>>> method description.
>>>
>>>>
>>>> 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.
>>>
>>> Good point. Modified the compatibility risk from minimum to low with 
>>> the explanation.
>>>
>>>>
>>>>
>>>> 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.
>>>
>>> Consistency is important. I replaced all occurrences of "thousands 
>>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
>>> separator(s)."
>>>
>>> Here are the modified changeset:
>>>
>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/
>>>
>>> as well as the modified CSR at the same URL.
>>>
>>> Naoto
>>>
>>>>
>>>> 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
>>>>
>>


From naoto.sato at oracle.com  Fri Jan  3 21:24:35 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 3 Jan 2020 13:24:35 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
 <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
 <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>
 <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com>
 <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com>
Message-ID: <ef69349b-b285-044f-ca48-0c03c8852950@oracle.com>

Hi Joe,

Thanks again for the review. The reason the way it is is all historical. 
percent/perMill/minusSign all had public APIs for the 'char' version 
since inception, and text version APIs were added later (JDK13). Thus 
they had to be in sync (both fields are accessible through API). On the 
other hand, exponential was private till JDK6, and at that time I guess 
the engineer decided only to expose public access to its text version, 
i.e., effectively deprecate 'char' version interface and field. I guess 
that's why he/she did not bother make them in sync, IMO. So there seems 
to be no explicit reason (to be noted in the source code) for not syncing.

My $.02

Naoto

On 1/3/20 11:40 AM, Joe Wang wrote:
> Hi Naoto,
> 
> The change looks fine to me as only monetaryGroupingSeparator was added 
> to equals.
> 
> I can't help to note though that, all fields participated in the equals 
> calculation except exponential. Some of the other fields are in similar 
> situations (one is public and the other not), e.g. percent and 
> percentText, perMill and perMillText, minusSign and minusSignText, and 
> also the currency related fields, but they all are included. It looks 
> like exponential was never publicly accessible, but the (1.6) added 
> exponentialSeparator became public. It's probably not necessary to 
> include all of them in the first place as they are in sync. that is, 
> changing one would change the other -- and in this regard, exponential 
> is an exception: setExponentialSymbol won't change exponential.
> 
> I understand this is all historical and it doesn't affect your 
> changeset. If the reason is known, it won't hurt to add some notes as 
> the other setXxxText clearly stated the relationship with their non-Text 
> representation. If not, it's fine to me to not have to spend the extra 
> time.
> 
> Best,
> Joe
> 
> On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote:
>> Hi Joe,
>>
>> I revised the changeset, as the cached hash code in 
>> DecimalFormatSymbols needs to be recalculated when any of the relevant 
>> fields is mutated. Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8227313/webrev.02/
>>
>> Naoto
>>
>> On 1/2/20 2:19 PM, Joe Wang wrote:
>>> Happy New Year, Naoto!
>>>
>>> Thanks for the explanation and changes. The changeset looks good to me.
>>>
>>> -Joe
>>>
>>> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote:
>>>> Hi Joe,
>>>>
>>>> Happy new year and thanks for your comments. Please see my replies 
>>>> below:
>>>>
>>>> On 12/23/19 5:20 PM, Joe Wang wrote:
>>>>> 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?
>>>>
>>>> Setting the custom monetary grouping separator will not affect the 
>>>> existing normal grouping separator. I added the explanation in the 
>>>> method description.
>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Good point. Modified the compatibility risk from minimum to low with 
>>>> the explanation.
>>>>
>>>>>
>>>>>
>>>>> 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.
>>>>
>>>> Consistency is important. I replaced all occurrences of "thousands 
>>>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
>>>> separator(s)."
>>>>
>>>> Here are the modified changeset:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/
>>>>
>>>> as well as the modified CSR at the same URL.
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> 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
>>>>>
>>>
> 

From huizhe.wang at oracle.com  Fri Jan  3 22:28:06 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 3 Jan 2020 14:28:06 -0800
Subject: <i18n dev> [15] RFR: 8227313: Support monetary grouping
 separator in DecimalFormat/DecimalFormatSymbols
In-Reply-To: <ef69349b-b285-044f-ca48-0c03c8852950@oracle.com>
References: <f5b9fc50-a82d-a3fa-e190-a6c4c9262ac5@oracle.com>
 <5817e6c2-a48a-84ce-0343-21d66fe80f2f@oracle.com>
 <3aebf6fd-377a-5668-51ea-157d2bdffaf8@oracle.com>
 <1e38f3c4-2dbb-a234-603e-aeef29cfd906@oracle.com>
 <8faa0ca2-4eb9-e98a-75ca-e3450cdbbd15@oracle.com>
 <4af9713b-b283-3fe5-f30d-16961d9cda26@oracle.com>
 <ef69349b-b285-044f-ca48-0c03c8852950@oracle.com>
Message-ID: <c45f74af-4c7c-ff8a-8374-b69dc332cfc1@oracle.com>

Hi Naoto,

Historical indeed, and true, it was not exposed prior to JDK6. Just need 
to make sure other classes within the package won't accidentally use its 
set method or mark it if it's 'deprecated'. But it's a minor issue. I'm 
fine with your changeset as is.

Best,
Joe

On 1/3/20 1:24 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thanks again for the review. The reason the way it is is all 
> historical. percent/perMill/minusSign all had public APIs for the 
> 'char' version since inception, and text version APIs were added later 
> (JDK13). Thus they had to be in sync (both fields are accessible 
> through API). On the other hand, exponential was private till JDK6, 
> and at that time I guess the engineer decided only to expose public 
> access to its text version, i.e., effectively deprecate 'char' version 
> interface and field. I guess that's why he/she did not bother make 
> them in sync, IMO. So there seems to be no explicit reason (to be 
> noted in the source code) for not syncing.
>
> My $.02
>
> Naoto
>
> On 1/3/20 11:40 AM, Joe Wang wrote:
>> Hi Naoto,
>>
>> The change looks fine to me as only monetaryGroupingSeparator was 
>> added to equals.
>>
>> I can't help to note though that, all fields participated in the 
>> equals calculation except exponential. Some of the other fields are 
>> in similar situations (one is public and the other not), e.g. percent 
>> and percentText, perMill and perMillText, minusSign and 
>> minusSignText, and also the currency related fields, but they all are 
>> included. It looks like exponential was never publicly accessible, 
>> but the (1.6) added exponentialSeparator became public. It's probably 
>> not necessary to include all of them in the first place as they are 
>> in sync. that is, changing one would change the other -- and in this 
>> regard, exponential is an exception: setExponentialSymbol won't 
>> change exponential.
>>
>> I understand this is all historical and it doesn't affect your 
>> changeset. If the reason is known, it won't hurt to add some notes as 
>> the other setXxxText clearly stated the relationship with their 
>> non-Text representation. If not, it's fine to me to not have to spend 
>> the extra time.
>>
>> Best,
>> Joe
>>
>> On 1/3/20 9:23 AM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> I revised the changeset, as the cached hash code in 
>>> DecimalFormatSymbols needs to be recalculated when any of the 
>>> relevant fields is mutated. Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.02/
>>>
>>> Naoto
>>>
>>> On 1/2/20 2:19 PM, Joe Wang wrote:
>>>> Happy New Year, Naoto!
>>>>
>>>> Thanks for the explanation and changes. The changeset looks good to 
>>>> me.
>>>>
>>>> -Joe
>>>>
>>>> On 1/2/20 12:50 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Happy new year and thanks for your comments. Please see my replies 
>>>>> below:
>>>>>
>>>>> On 12/23/19 5:20 PM, Joe Wang wrote:
>>>>>> 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?
>>>>>
>>>>> Setting the custom monetary grouping separator will not affect the 
>>>>> existing normal grouping separator. I added the explanation in the 
>>>>> method description.
>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Good point. Modified the compatibility risk from minimum to low 
>>>>> with the explanation.
>>>>>
>>>>>>
>>>>>>
>>>>>> 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.
>>>>>
>>>>> Consistency is important. I replaced all occurrences of "thousands 
>>>>> separator(s)" in DecimalFormat/DecimalFormatSymbols with "grouping 
>>>>> separator(s)."
>>>>>
>>>>> Here are the modified changeset:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8227313/webrev.01/
>>>>>
>>>>> as well as the modified CSR at the same URL.
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> 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
>>>>>>
>>>>
>>


From naoto.sato at oracle.com  Mon Jan  6 17:05:20 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 6 Jan 2020 09:05:20 -0800
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
Message-ID: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

The test case for the fix to 8232860 was only intended for the US 
locale. Simply adding the default locale check will fix the test case.

Naoto

From lance.andersen at oracle.com  Mon Jan  6 17:14:25 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Jan 2020 12:14:25 -0500
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
In-Reply-To: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
Message-ID: <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com>

Hi Naoto,

The change looks OK.  One thought was whether any thought was given to use SkippedException in the else block starting at line 370 within LocaleProviders.

Best
Lance

> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com wrote:
> 
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8236495
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/
> 
> The test case for the fix to 8232860 was only intended for the US locale. Simply adding the default locale check will fix the test case.
> 
> Naoto

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Mon Jan  6 17:55:02 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 6 Jan 2020 09:55:02 -0800
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
In-Reply-To: <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com>
References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
 <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com>
Message-ID: <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com>

Hi Lance,

Thank you for the prompt review.

On 1/6/20 9:14 AM, Lance Andersen wrote:
> Hi Naoto,
> 
> The change looks OK. ?One thought was whether any thought was given to 
> use?SkippedException in the else block starting at line 370 within 
> LocaleProviders.

I am not familiar with that exception. Is it jtreg.SkippedException? I 
searched for the exception, and one example is:

jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java

where it requires the platform is linux with the directive "@requires 
os.family == "linux"", so throwing the exception does work as an 
assertion. However in this LocaleProviders.java, it will need to simply 
ignore the case and should succeed. So I am not sure SkippedException 
can be applied here.

Naoto

> 
> Best
> Lance
> 
>> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com> wrote:
>>
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8236495
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/
>>
>> The test case for the fix to 8232860 was only intended for the US 
>> locale. Simply adding the default locale check will fix the test case.
>>
>> Naoto
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From lance.andersen at oracle.com  Mon Jan  6 18:06:39 2020
From: lance.andersen at oracle.com (Lance Andersen)
Date: Mon, 6 Jan 2020 13:06:39 -0500
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
In-Reply-To: <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com>
References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
 <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com>
 <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com>
Message-ID: <EA227BEA-5A98-44D1-AD66-692CFFA39399@oracle.com>

Hi Naoto

> On Jan 6, 2020, at 12:55 PM, naoto.sato at oracle.com wrote:
> 
> Hi Lance,
> 
> Thank you for the prompt review.
> 
> On 1/6/20 9:14 AM, Lance Andersen wrote:
>> Hi Naoto,
>> The change looks OK.  One thought was whether any thought was given to use SkippedException in the else block starting at line 370 within LocaleProviders.
> 
> I am not familiar with that exception. Is it jtreg.SkippedException?

Yes I am, sorry for not being clearer.   

You can throw that in the else block where you print the message about skipping the test and it will be tracked as a skip vs a pass.

Not a big deal either way but gives you extra granularity as to why the test was not run and easier to see vs just a print statement?  I just wanted to point this out as something to consider going forward.

Have a good rest of your day!

> I searched for the exception, and one example is:
> 
> jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java
> 
> where it requires the platform is linux with the directive "@requires os.family == "linux"", so throwing the exception does work as an assertion. However in this LocaleProviders.java, it will need to simply ignore the case and should succeed. So I am not sure SkippedException can be applied here.
> 
> Naoto
> 
>> Best
>> Lance
>>> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com <mailto:naoto.sato at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Please review the fix to the following issue:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8236495
>>> 
>>> The proposed changeset is located at:
>>> 
>>> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/
>>> 
>>> The test case for the fix to 8232860 was only intended for the US locale. Simply adding the default locale check will fix the test case.
>>> 
>>> Naoto
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>

 <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
 <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>




From naoto.sato at oracle.com  Mon Jan  6 18:28:15 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Mon, 6 Jan 2020 10:28:15 -0800
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
In-Reply-To: <EA227BEA-5A98-44D1-AD66-692CFFA39399@oracle.com>
References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
 <65578150-BF5E-42F2-B0D7-345B8D9996B8@oracle.com>
 <0ea21045-ca5b-e823-00a3-572839fbb10d@oracle.com>
 <EA227BEA-5A98-44D1-AD66-692CFFA39399@oracle.com>
Message-ID: <9e66d926-9cfb-f57e-8799-b5b26e05b441@oracle.com>

Thanks, Lance, for the explanation.

I explored your suggestion. Unfortunately, the test invokes a Java 
process where each test is performed (LocaleProvidersRun.testRun() 
method), and it only checks the exit code of the Java process. So 
throwing SkippedException in each test will not be handled in the 
expected manner (skip vs pass). Of course this could be improved, but I 
would rather not do it for this simple test case change :-)

Naoto

On 1/6/20 10:06 AM, Lance Andersen wrote:
> Hi Naoto
> 
>> On Jan 6, 2020, at 12:55 PM, naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com> wrote:
>>
>> Hi Lance,
>>
>> Thank you for the prompt review.
>>
>> On 1/6/20 9:14 AM, Lance Andersen wrote:
>>> Hi Naoto,
>>> The change looks OK. ?One thought was whether any thought was given 
>>> to use?SkippedException in the else block starting at line 370 within 
>>> LocaleProviders.
>>
>> I am not familiar with that exception. Is it jtreg.SkippedException? 
> 
> Yes I am, sorry for not being clearer.
> 
> You can throw that in the else block where you print the message about 
> skipping the test and it will be tracked as a skip vs a pass.
> 
> Not a big deal either way but gives you extra granularity as to why the 
> test was not run and easier to see vs just a print statement? ?I just 
> wanted to point this out as something to consider going forward.
> 
> Have a good rest of your day!
> 
>> I searched for the exception, and one example is:
>>
>> jdk/java/nio/channels/DatagramChannel/PromiscuousIPv6.java
>>
>> where it requires the platform is linux with the directive "@requires 
>> os.family == "linux"", so throwing the exception does work as an 
>> assertion. However in this LocaleProviders.java, it will need to 
>> simply ignore the case and should succeed. So I am not sure 
>> SkippedException can be applied here.
>>
>> Naoto
>>
>>> Best
>>> Lance
>>>> On Jan 6, 2020, at 12:05 PM, naoto.sato at oracle.com 
>>>> <mailto:naoto.sato at oracle.com> <mailto:naoto.sato at oracle.com> wrote:
>>>>
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8236495
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/
>>>>
>>>> The test case for the fix to 8232860 was only intended for the US 
>>>> locale. Simply adding the default locale check will fix the test case.
>>>>
>>>> Naoto
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
>>> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance 
>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037
>>> Oracle?Java Engineering
>>> 1 Network Drive
>>> Burlington, MA 01803
>>> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com> 
>>> <mailto:Lance.Andersen at oracle.com>
> 
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif><http://oracle.com/us/design/oracle-email-sig-198324.gif>
> <http://oracle.com/us/design/oracle-email-sig-198324.gif>Lance Andersen| 
> Principal Member of Technical Staff | +1.781.442.2037
> Oracle?Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com <mailto:Lance.Andersen at oracle.com>
> 
> 
> 

From christoph.langer at sap.com  Mon Jan  6 22:25:24 2020
From: christoph.langer at sap.com (Langer, Christoph)
Date: Mon, 6 Jan 2020 22:25:24 +0000
Subject: <i18n dev> [14] RFR: 8236495,
 open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on
 mac 10.14 with de_DE locale.
In-Reply-To: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
References: <799d7c3b-0acf-eea6-649d-8a61e7495590@oracle.com>
Message-ID: <AM6PR02MB4984A53B8F34C6907AF99EAF8A3C0@AM6PR02MB4984.eurprd02.prod.outlook.com>

Hi Naoto,

The change looks good. Thanks for fixing this. We're seeing it regularly in our test infrastructure where we're running Mac systems with German locale.

Best regards
Christoph

> -----Original Message-----
> From: i18n-dev <i18n-dev-bounces at openjdk.java.net> On Behalf Of
> naoto.sato at oracle.com
> Sent: Montag, 6. Januar 2020 18:05
> To: i18n-dev at openjdk.java.net; core-libs-dev <core-libs-
> dev at openjdk.java.net>
> Subject: <i18n dev> [14] RFR: 8236495,
> open/test/jdk/java/util/Locale/LocaleProvidersRun.java failed on mac 10.14
> with de_DE locale.
> 
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8236495
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8236495/webrev.00/
> 
> The test case for the fix to 8232860 was only intended for the US
> locale. Simply adding the default locale check will fix the test case.
> 
> Naoto

From gennady.g.gerasimov.alfa at gmail.com  Thu Jan  9 10:24:12 2020
From: gennady.g.gerasimov.alfa at gmail.com (Gennady Gerasimov)
Date: Thu, 9 Jan 2020 13:24:12 +0300
Subject: <i18n dev> Short month name values for ru locale
In-Reply-To: <D7C38008-34B6-49E8-B39D-68614972CD15@gmail.com>
References: <D7C38008-34B6-49E8-B39D-68614972CD15@gmail.com>
Message-ID: <0232CEC6-EA67-4C59-A248-AA86653796E4@gmail.com>

Any updates regarding this?

Btw, probably I found another one bug which can be easily reproduced using an example below

final DateTimeFormatter FORMATTER =
        DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"));
final LocalDate startDate = LocalDate.of(2020, 12, 31)
final String formatted = FORMATTER.format(startDate)
formatted == startDate.toString()
Where formatted is 31 ???. 2021
Could you please take a look?

> On 17 Jun 2019, at 17:42, Gennady Gerasimov <gennady.g.gerasimov.alfa at gmail.com> wrote:
> 
> Hi
> 
> I have a question about metaValue_MonthAbbreviations values in FormatData_ru class.
> Prior to https://bugs.openjdk.java.net/browse/JDK-8043554 <https://bugs.openjdk.java.net/browse/JDK-8043554> short names of months in ru locale do not contain dot at the end of word.
> Since that issue is closed and CLDR is used by default all values in metaValue_MonthAbbreviations have it
> 
> final String[] metaValue_MonthAbbreviations = new String[] {
>        "\u044f\u043d\u0432.",
>        "\u0444\u0435\u0432\u0440.",
>        "\u043c\u0430\u0440.",
>        "\u0430\u043f\u0440.",
>        "\u043c\u0430\u044f",
>        "\u0438\u044e\u043d.",
>        "\u0438\u044e\u043b.",
>        "\u0430\u0432\u0433.",
>        "\u0441\u0435\u043d\u0442.",
>        "\u043e\u043a\u0442.",
>        "\u043d\u043e\u044f\u0431.",
>        "\u0434\u0435\u043a.",
>        "",
>     };
> 
> 
> It looks unusual for me. E.g. DateTimeFormatter defined like 
> DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"))
> applied to some date object returns line like that "????????? c 30 ???. 2018 ?? 30 ???. 2030? which is unexpected for me because there are no dots in formatter pattern
> 
> Are these values defined correctly?
> 
> 
> 
>  
> 


From naoto.sato at oracle.com  Thu Jan  9 17:18:17 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 9 Jan 2020 09:18:17 -0800
Subject: <i18n dev> Short month name values for ru locale
In-Reply-To: <0232CEC6-EA67-4C59-A248-AA86653796E4@gmail.com>
References: <D7C38008-34B6-49E8-B39D-68614972CD15@gmail.com>
 <0232CEC6-EA67-4C59-A248-AA86653796E4@gmail.com>
Message-ID: <1c096da9-fd70-a67f-fff2-93f4caf3e5f8@oracle.com>

Hi Gennady,

I must've overlooked your original question. As to the Russian 
abbreviated month names, they all come from CLDR. For example, CLDR's 
abbreviated formatting month name for October in Russian is "???." as in 
(look for "?ru?" in that chart):

http://unicode.org/cldr/charts/36/by_type/date_&_time.gregorian.html#5bea9c642ffb717

So, even if there is no dot involved in the pattern, formatted text 
should have dot as a Russian localized text.

As to th 2020/2021 difference, that comes from the fact that the pattern 
uses "YYYY" instead of "yyyy", where "Y" designates the week-based-year, 
where the first week should satisfy minimum number of days. In this case 
12/31 belongs to the next week-based-year, thus 2021 is printed as week 
based year.

Naoto


On 1/9/20 2:24 AM, Gennady Gerasimov wrote:
> Any updates regarding this?
> 
> Btw, probably I found another one bug which can be easily reproduced using an example below
> 
> final DateTimeFormatter FORMATTER =
>          DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"));
> final LocalDate startDate = LocalDate.of(2020, 12, 31)
> final String formatted = FORMATTER.format(startDate)
> formatted == startDate.toString()
> Where formatted is 31 ???. 2021
> Could you please take a look?
> 
>> On 17 Jun 2019, at 17:42, Gennady Gerasimov <gennady.g.gerasimov.alfa at gmail.com> wrote:
>>
>> Hi
>>
>> I have a question about metaValue_MonthAbbreviations values in FormatData_ru class.
>> Prior to https://bugs.openjdk.java.net/browse/JDK-8043554 <https://bugs.openjdk.java.net/browse/JDK-8043554> short names of months in ru locale do not contain dot at the end of word.
>> Since that issue is closed and CLDR is used by default all values in metaValue_MonthAbbreviations have it
>>
>> final String[] metaValue_MonthAbbreviations = new String[] {
>>         "\u044f\u043d\u0432.",
>>         "\u0444\u0435\u0432\u0440.",
>>         "\u043c\u0430\u0440.",
>>         "\u0430\u043f\u0440.",
>>         "\u043c\u0430\u044f",
>>         "\u0438\u044e\u043d.",
>>         "\u0438\u044e\u043b.",
>>         "\u0430\u0432\u0433.",
>>         "\u0441\u0435\u043d\u0442.",
>>         "\u043e\u043a\u0442.",
>>         "\u043d\u043e\u044f\u0431.",
>>         "\u0434\u0435\u043a.",
>>         "",
>>      };
>>
>>
>> It looks unusual for me. E.g. DateTimeFormatter defined like
>> DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"))
>> applied to some date object returns line like that "????????? c 30 ???. 2018 ?? 30 ???. 2030? which is unexpected for me because there are no dots in formatter pattern
>>
>> Are these values defined correctly?
>>
>>
>>
>>   
>>
> 

From srl at icu-project.org  Thu Jan  9 17:48:40 2020
From: srl at icu-project.org (Steven R. Loomis)
Date: Thu, 9 Jan 2020 09:48:40 -0800
Subject: <i18n dev> Short month name values for ru locale
In-Reply-To: <1c096da9-fd70-a67f-fff2-93f4caf3e5f8@oracle.com>
References: <D7C38008-34B6-49E8-B39D-68614972CD15@gmail.com>
 <0232CEC6-EA67-4C59-A248-AA86653796E4@gmail.com>
 <1c096da9-fd70-a67f-fff2-93f4caf3e5f8@oracle.com>
Message-ID: <DDC8E1EF-3085-4554-838E-B4DC0B5B88BE@icu-project.org>

Hi, I can confirm that the abbreviated months are ????.? and ????.? in Russian for CLDR. I think this specific string been stable for some time (since about 2012), recently re-confirmed by multiple linguist participants.

--
Steven R. Loomis | @srl295 | git.io/srl295



> El ene. 9, 2020, a las 9:18 a. m., naoto.sato at oracle.com escribi?:
> 
> Hi Gennady,
> 
> I must've overlooked your original question. As to the Russian abbreviated month names, they all come from CLDR. For example, CLDR's abbreviated formatting month name for October in Russian is "???." as in (look for "?ru?" in that chart):
> 
> http://unicode.org/cldr/charts/36/by_type/date_&_time.gregorian.html#5bea9c642ffb717
> 
> So, even if there is no dot involved in the pattern, formatted text should have dot as a Russian localized text.
> 
> As to th 2020/2021 difference, that comes from the fact that the pattern uses "YYYY" instead of "yyyy", where "Y" designates the week-based-year, where the first week should satisfy minimum number of days. In this case 12/31 belongs to the next week-based-year, thus 2021 is printed as week based year.
> 
> Naoto
> 
> 
> On 1/9/20 2:24 AM, Gennady Gerasimov wrote:
>> Any updates regarding this?
>> Btw, probably I found another one bug which can be easily reproduced using an example below
>> final DateTimeFormatter FORMATTER =
>>         DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"));
>> final LocalDate startDate = LocalDate.of(2020, 12, 31)
>> final String formatted = FORMATTER.format(startDate)
>> formatted == startDate.toString()
>> Where formatted is 31 ???. 2021
>> Could you please take a look?
>>> On 17 Jun 2019, at 17:42, Gennady Gerasimov <gennady.g.gerasimov.alfa at gmail.com> wrote:
>>> 
>>> Hi
>>> 
>>> I have a question about metaValue_MonthAbbreviations values in FormatData_ru class.
>>> Prior to https://bugs.openjdk.java.net/browse/JDK-8043554 <https://bugs.openjdk.java.net/browse/JDK-8043554> short names of months in ru locale do not contain dot at the end of word.
>>> Since that issue is closed and CLDR is used by default all values in metaValue_MonthAbbreviations have it
>>> 
>>> final String[] metaValue_MonthAbbreviations = new String[] {
>>>        "\u044f\u043d\u0432.",
>>>        "\u0444\u0435\u0432\u0440.",
>>>        "\u043c\u0430\u0440.",
>>>        "\u0430\u043f\u0440.",
>>>        "\u043c\u0430\u044f",
>>>        "\u0438\u044e\u043d.",
>>>        "\u0438\u044e\u043b.",
>>>        "\u0430\u0432\u0433.",
>>>        "\u0441\u0435\u043d\u0442.",
>>>        "\u043e\u043a\u0442.",
>>>        "\u043d\u043e\u044f\u0431.",
>>>        "\u0434\u0435\u043a.",
>>>        "",
>>>     };
>>> 
>>> 
>>> It looks unusual for me. E.g. DateTimeFormatter defined like
>>> DateTimeFormatter.ofPattern("dd MMM YYYY", new Locale("ru"))
>>> applied to some date object returns line like that "????????? c 30 ???. 2018 ?? 30 ???. 2030? which is unexpected for me because there are no dots in formatter pattern
>>> 
>>> Are these values defined correctly?
>>> 
>>> 
>>> 
>>>  


From takiguc at linux.vnet.ibm.com  Fri Jan 10 13:13:37 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Fri, 10 Jan 2020 22:13:37 +0900
Subject: <i18n dev> RFR: CSR JDK-8233385 Align some one-way conversion in
 MS950 charset with Windows
Message-ID: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>

Hello.

Could you review CSR JDK-8233385 [1] ?

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

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From naoto.sato at oracle.com  Fri Jan 10 22:02:20 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 14:02:20 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
	location
Message-ID: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

Although the number of modified files are huge, the change is simply 
moving the scattered ICU sources in various locations under 
jdk.internal.icu package, keeping the original ICU's source tree structure.

Naoto

From srl at icu-project.org  Fri Jan 10 22:26:25 2020
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 10 Jan 2020 14:26:25 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
Message-ID: <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>

in Norm2AllModes.java and UBiDiProps.java  and UCharacterProperty.java the stub name (icudt64b) should be calculated from the version number.  At least put ?icudt64b? in one place and refer to it.

OR keep the data file names unversioned, such as src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm

otherwise looks good

--
Steven R. Loomis | @srl295 | git.io/srl295



> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com escribi?:
> 
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8174270
> 
> The proposed changeset is located at:
> 
> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
> 
> Although the number of modified files are huge, the change is simply moving the scattered ICU sources in various locations under jdk.internal.icu package, keeping the original ICU's source tree structure.
> 
> Naoto


From huizhe.wang at oracle.com  Fri Jan 10 22:57:48 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 10 Jan 2020 14:57:48 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
	location
In-Reply-To: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
Message-ID: <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>

Is there a reason why uidna.spp was left out of the move?

-Joe

On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8174270
>
> The proposed changeset is located at:
>
> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>
> Although the number of modified files are huge, the change is simply 
> moving the scattered ICU sources in various locations under 
> jdk.internal.icu package, keeping the original ICU's source tree 
> structure.
>
> Naoto


From naoto.sato at oracle.com  Sat Jan 11 00:02:57 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 16:02:57 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
 <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
Message-ID: <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>

Hi Steven,

On 1/10/20 2:26 PM, Steven R. Loomis wrote:
> in?Norm2AllModes.java and?UBiDiProps.java ?and?UCharacterProperty.java 
> the stub name (icudt64b) should be calculated from the version number. 
>  ?At least put ?icudt64b? in one place and refer to it.

Good point. Modified as suggested:

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

Naoto

> 
> OR keep the data file names unversioned, such 
> as?src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm
> 
> otherwise looks good
> 
> --
> Steven R. Loomis | @srl295 | git.io/srl295 <http://git.io/srl295>
> 
> 
> 
>> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com 
>> <mailto:naoto.sato at oracle.com> escribi?:
>>
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>
>> Although the number of modified files are huge, the change is simply 
>> moving the scattered ICU sources in various locations under 
>> jdk.internal.icu package, keeping the original ICU's source tree 
>> structure.
>>
>> Naoto
> 

From naoto.sato at oracle.com  Sat Jan 11 00:04:22 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 10 Jan 2020 16:04:22 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
	location
In-Reply-To: <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
 <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
Message-ID: <a262123a-4f46-62df-c5b6-a714724048d9@oracle.com>

Hi Joe,

That data file seems no longer included in the ICU4J package (as of 
64.2), thus I left it as it is.

Naoto

On 1/10/20 2:57 PM, Joe Wang wrote:
> Is there a reason why uidna.spp was left out of the move?
> 
> -Joe
> 
> On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>
>> The proposed changeset is located at:
>>
>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>
>> Although the number of modified files are huge, the change is simply 
>> moving the scattered ICU sources in various locations under 
>> jdk.internal.icu package, keeping the original ICU's source tree 
>> structure.
>>
>> Naoto
> 

From srl at icu-project.org  Sat Jan 11 00:23:20 2020
From: srl at icu-project.org (Steven R. Loomis)
Date: Fri, 10 Jan 2020 16:23:20 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
 location
In-Reply-To: <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
 <7F2A6774-6B71-47D1-B0DA-65FB014D455A@icu-project.org>
 <835cc98d-fa1c-9e7d-c1b9-0a5e075dd683@oracle.com>
Message-ID: <CE744B33-384D-4BB1-AA4E-355AB796EC16@icu-project.org>

approve

--
Steven R. Loomis | @srl295 | git.io/srl295



> El ene. 10, 2020, a las 4:02 p. m., naoto.sato at oracle.com escribi?:
> 
> Hi Steven,
> 
> On 1/10/20 2:26 PM, Steven R. Loomis wrote:
>> in Norm2AllModes.java and UBiDiProps.java  and UCharacterProperty.java the stub name (icudt64b) should be calculated from the version number.   At least put ?icudt64b? in one place and refer to it.
> 
> Good point. Modified as suggested:
> 
> https://cr.openjdk.java.net/~naoto/8174270/webrev.01/
> 
> Naoto
> 
>> OR keep the data file names unversioned, such as src/java.base/share/classes/jdk/internal/icu/impl/data/nfc.nrm
>> otherwise looks good
>> --
>> Steven R. Loomis | @srl295 | git.io/srl295 <http://git.io/srl295>
>>> El ene. 10, 2020, a las 2:02 p. m., naoto.sato at oracle.com <mailto:naoto.sato at oracle.com> escribi?:
>>> 
>>> Hi,
>>> 
>>> Please review the fix to the following issue:
>>> 
>>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>> 
>>> The proposed changeset is located at:
>>> 
>>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>> 
>>> Although the number of modified files are huge, the change is simply moving the scattered ICU sources in various locations under jdk.internal.icu package, keeping the original ICU's source tree structure.
>>> 
>>> Naoto


From huizhe.wang at oracle.com  Sat Jan 11 04:21:49 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Fri, 10 Jan 2020 20:21:49 -0800
Subject: <i18n dev> [15] RFR: 8174270: Consolidate ICU sources in one
	location
In-Reply-To: <a262123a-4f46-62df-c5b6-a714724048d9@oracle.com>
References: <b6fe7a40-6aa0-cb6d-2e62-3bdf3f0adae3@oracle.com>
 <1ce70cf2-a405-dc99-4843-78d032924cf4@oracle.com>
 <a262123a-4f46-62df-c5b6-a714724048d9@oracle.com>
Message-ID: <39bfd4c6-fe4f-3967-9fb8-5ba9bcd7e804@oracle.com>

I see. It's all good to me then.

Best,
Joe

On 1/10/20 4:04 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> That data file seems no longer included in the ICU4J package (as of 
> 64.2), thus I left it as it is.
>
> Naoto
>
> On 1/10/20 2:57 PM, Joe Wang wrote:
>> Is there a reason why uidna.spp was left out of the move?
>>
>> -Joe
>>
>> On 1/10/20 2:02 PM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8174270
>>>
>>> The proposed changeset is located at:
>>>
>>> https://cr.openjdk.java.net/~naoto/8174270/webrev.00/
>>>
>>> Although the number of modified files are huge, the change is simply 
>>> moving the scattered ICU sources in various locations under 
>>> jdk.internal.icu package, keeping the original ICU's source tree 
>>> structure.
>>>
>>> Naoto
>>


From naoto.sato at oracle.com  Tue Jan 14 16:35:47 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 14 Jan 2020 08:35:47 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure custom
 variants in HijrahChronology
Message-ID: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>

Hi,

Please review the fix to the following issue:

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

The proposed CSR and changeset are located at:

CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/

The spec of java.time.chrono.HijrahChronology suggests that it could 
load custom variants of Hijirah calendar type using properties files. 
However it does not work as designed. This change intends to make it work.

Naoto

From huizhe.wang at oracle.com  Tue Jan 14 23:35:56 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 15:35:56 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
Message-ID: <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>

Hi Naoto,

Since it's dealing with non-standard properties files, is there a need 
to verify the files? The constructor (HijrahChronology) does check 
whether the id or type is empty. If there is no existing process to 
validate, it's probably not worth it to spend time as it's rare and it's 
config time.

The test summary states "Test image creation", it may be better to say 
sth. like verifies custom configuration?

Best,
Joe

On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
> Hi,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8187987
>
> The proposed CSR and changeset are located at:
>
> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>
> The spec of java.time.chrono.HijrahChronology suggests that it could 
> load custom variants of Hijirah calendar type using properties files. 
> However it does not work as designed. This change intends to make it 
> work.
>
> Naoto


From naoto.sato at oracle.com  Wed Jan 15 02:04:57 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 14 Jan 2020 18:04:57 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
Message-ID: <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>

Hi Joe,

Thank you for the review. Please find my comments below:

On 1/14/20 3:35 PM, Joe Wang wrote:
> Hi Naoto,
> 
> Since it's dealing with non-standard properties files, is there a need 
> to verify the files? The constructor (HijrahChronology) does check 
> whether the id or type is empty. If there is no existing process to 
> validate, it's probably not worth it to spend time as it's rare and it's 
> config time.

IIUC, the idea is to create the instance at class loading time (thus the 
faster the better) and cache it, then check the validity later at actual 
method invocation (cf. checkCalendarInit() method).

> 
> The test summary states "Test image creation", it may be better to say 
> sth. like verifies custom configuration?

Good catch! I was simply copying some portion from other test case. 
Corrected:

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

Naoto

> 
> Best,
> Joe
> 
> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>
>> The proposed CSR and changeset are located at:
>>
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>
>> The spec of java.time.chrono.HijrahChronology suggests that it could 
>> load custom variants of Hijirah calendar type using properties files. 
>> However it does not work as designed. This change intends to make it 
>> work.
>>
>> Naoto
> 

From huizhe.wang at oracle.com  Wed Jan 15 02:37:21 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Tue, 14 Jan 2020 18:37:21 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
Message-ID: <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>



On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
> Hi Joe,
>
> Thank you for the review. Please find my comments below:
>
> On 1/14/20 3:35 PM, Joe Wang wrote:
>> Hi Naoto,
>>
>> Since it's dealing with non-standard properties files, is there a 
>> need to verify the files? The constructor (HijrahChronology) does 
>> check whether the id or type is empty. If there is no existing 
>> process to validate, it's probably not worth it to spend time as it's 
>> rare and it's config time.
>
> IIUC, the idea is to create the instance at class loading time (thus 
> the faster the better) and cache it, then check the validity later at 
> actual method invocation (cf. checkCalendarInit() method).

Make sense.
>
>>
>> The test summary states "Test image creation", it may be better to 
>> say sth. like verifies custom configuration?
>
> Good catch! I was simply copying some portion from other test case. 
> Corrected:
>
> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/

Looks good to me.

Best regards,
Joe

>
> Naoto
>
>>
>> Best,
>> Joe
>>
>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>> Hi,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>
>>> The proposed CSR and changeset are located at:
>>>
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>
>>> The spec of java.time.chrono.HijrahChronology suggests that it could 
>>> load custom variants of Hijirah calendar type using properties 
>>> files. However it does not work as designed. This change intends to 
>>> make it work.
>>>
>>> Naoto
>>


From naoto.sato at oracle.com  Wed Jan 15 20:06:12 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jan 2020 12:06:12 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
Message-ID: <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>

Hi Roger,

Thank you for the review. Please find my comments below:

On 1/15/20 10:30 AM, Roger Riggs wrote:
> Hi Naoto,
> 
> Is it correct to say that there is no impact on startup until there is 
> an explicit reference to HijrahChronology?
> It would seem that the registering HijrahChronology would trigger all 
> the work and that happens when Chronology is initialized. (see below)

What I meant in the reply to Joe's email was that the data validity 
check done in loadCalendarData(), e.g., year value check, etc. which are 
not done at class init. But you are correct that the properties files 
are read twice (below). I thought it was fine as this is not a common 
case (not happened before, to be precise).

> 
> HijrahChronology.java:
> 
> 291-295: Since registerCustomChrono is the only place where CONF_PATH is 
> used,
>  ?? do all the work, including the property lookup in that method.
> 836:? If other chronologies are built-in this code will need to be changed.
>  ?? Can it do the getResourceAsStream first in all cases and fall back 
> to /conf/chronology?

Yes, it would have to be changed if we support built-in type other than 
umalqura. But I would think other code would have to anyways. I think we 
can take advantage of the fact that umalqura is the only built-in, and 
others come from /conf/chronology so that extra fallback is avoided.

> 
> 855: Since all the loading is triggered from a static initializer, is 
> there really any point in throwing an exception.
>  ? More useful would be a logging message (assuming logging is allowed 
> early in startup when Chronology is initialized)

Good point. I will replace UncheckedIOException with logging.

> 
> 1054: readConfigProperties: The case for the other HijrahChronologies 
> delays loading the data until it is needed.
> This is doing the work to read the file and create the properties 
> instance but then discards it to be read a second time later.
> 
> Perhaps we need to specify that the config file name includes both the 
> id and type so it can be registered without reading the file.

Should the file name like "Hijrah-config-<id>_<type>.properties" work?

Naoto

> 
> Regards, Roger
> 
> 
> On 1/14/20 9:37 PM, Joe Wang wrote:
>>
>>
>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>> Hi Joe,
>>>
>>> Thank you for the review. Please find my comments below:
>>>
>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>> Hi Naoto,
>>>>
>>>> Since it's dealing with non-standard properties files, is there a 
>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>> check whether the id or type is empty. If there is no existing 
>>>> process to validate, it's probably not worth it to spend time as 
>>>> it's rare and it's config time.
>>>
>>> IIUC, the idea is to create the instance at class loading time (thus 
>>> the faster the better) and cache it, then check the validity later at 
>>> actual method invocation (cf. checkCalendarInit() method).
>>
>> Make sense.
>>>
>>>>
>>>> The test summary states "Test image creation", it may be better to 
>>>> say sth. like verifies custom configuration?
>>>
>>> Good catch! I was simply copying some portion from other test case. 
>>> Corrected:
>>>
>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>
>> Looks good to me.
>>
>> Best regards,
>> Joe
>>
>>>
>>> Naoto
>>>
>>>>
>>>> Best,
>>>> Joe
>>>>
>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the fix to the following issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>
>>>>> The proposed CSR and changeset are located at:
>>>>>
>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>
>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>> could load custom variants of Hijirah calendar type using 
>>>>> properties files. However it does not work as designed. This change 
>>>>> intends to make it work.
>>>>>
>>>>> Naoto
>>>>
>>
> 

From roger.riggs at oracle.com  Wed Jan 15 20:37:41 2020
From: roger.riggs at oracle.com (Roger Riggs)
Date: Wed, 15 Jan 2020 15:37:41 -0500
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
Message-ID: <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>

Hi,

On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thank you for the review. Please find my comments below:
>
> On 1/15/20 10:30 AM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> Is it correct to say that there is no impact on startup until there 
>> is an explicit reference to HijrahChronology?
>> It would seem that the registering HijrahChronology would trigger all 
>> the work and that happens when Chronology is initialized. (see below)
>
> What I meant in the reply to Joe's email was that the data validity 
> check done in loadCalendarData(), e.g., year value check, etc. which 
> are not done at class init. But you are correct that the properties 
> files are read twice (below). I thought it was fine as this is not a 
> common case (not happened before, to be precise).
Until it get used, there will still be a probe of the filesystem to see 
if a config directory/file exists
that would impact every startup. I don't see a way to mitigate that 
without making the config? more complex.
>
>>
>> HijrahChronology.java:
>>
>> 291-295: Since registerCustomChrono is the only place where CONF_PATH 
>> is used,
>> ??? do all the work, including the property lookup in that method.
>> 836:? If other chronologies are built-in this code will need to be 
>> changed.
>> ??? Can it do the getResourceAsStream first in all cases and fall 
>> back to /conf/chronology?
>
> Yes, it would have to be changed if we support built-in type other 
> than umalqura. But I would think other code would have to anyways. I 
> think we can take advantage of the fact that umalqura is the only 
> built-in, and others come from /conf/chronology so that extra fallback 
> is avoided.
Possibly, but could/would be more localized and consist of only the 
registerChronology call.
>
>>
>> 855: Since all the loading is triggered from a static initializer, is 
>> there really any point in throwing an exception.
>> ?? More useful would be a logging message (assuming logging is 
>> allowed early in startup when Chronology is initialized)
>
> Good point. I will replace UncheckedIOException with logging.
>
>>
>> 1054: readConfigProperties: The case for the other HijrahChronologies 
>> delays loading the data until it is needed.
>> This is doing the work to read the file and create the properties 
>> instance but then discards it to be read a second time later.
>>
>> Perhaps we need to specify that the config file name includes both 
>> the id and type so it can be registered without reading the file.
>
> Should the file name like "Hijrah-config-<id>_<type>.properties" work?
yes, its worth checking the valid characters in id and type.

Thanks, Roger

BTW, the test drive can be implemented using testng, only the test 
itself is easier as main().

>
> Naoto
>
>>
>> Regards, Roger
>>
>>
>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>
>>>
>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>> Hi Joe,
>>>>
>>>> Thank you for the review. Please find my comments below:
>>>>
>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> Since it's dealing with non-standard properties files, is there a 
>>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>>> check whether the id or type is empty. If there is no existing 
>>>>> process to validate, it's probably not worth it to spend time as 
>>>>> it's rare and it's config time.
>>>>
>>>> IIUC, the idea is to create the instance at class loading time 
>>>> (thus the faster the better) and cache it, then check the validity 
>>>> later at actual method invocation (cf. checkCalendarInit() method).
>>>
>>> Make sense.
>>>>
>>>>>
>>>>> The test summary states "Test image creation", it may be better to 
>>>>> say sth. like verifies custom configuration?
>>>>
>>>> Good catch! I was simply copying some portion from other test case. 
>>>> Corrected:
>>>>
>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>
>>> Looks good to me.
>>>
>>> Best regards,
>>> Joe
>>>
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Best,
>>>>> Joe
>>>>>
>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>
>>>>>> The proposed CSR and changeset are located at:
>>>>>>
>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>
>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>> properties files. However it does not work as designed. This 
>>>>>> change intends to make it work.
>>>>>>
>>>>>> Naoto
>>>>>
>>>
>>


From naoto.sato at oracle.com  Thu Jan 16 00:49:15 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 15 Jan 2020 16:49:15 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>
Message-ID: <e342651f-65d6-2758-d3b3-e2bf75fdaf73@oracle.com>

Updated:

https://cr.openjdk.java.net/~naoto/8187987/webrev.02/

The change includes the new naming convention, reduction of properties 
files reading to once, and utilization of logging.

Naoto

On 1/15/20 12:37 PM, Roger Riggs wrote:
> Hi,
> 
> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>> Hi Roger,
>>
>> Thank you for the review. Please find my comments below:
>>
>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>> Hi Naoto,
>>>
>>> Is it correct to say that there is no impact on startup until there 
>>> is an explicit reference to HijrahChronology?
>>> It would seem that the registering HijrahChronology would trigger all 
>>> the work and that happens when Chronology is initialized. (see below)
>>
>> What I meant in the reply to Joe's email was that the data validity 
>> check done in loadCalendarData(), e.g., year value check, etc. which 
>> are not done at class init. But you are correct that the properties 
>> files are read twice (below). I thought it was fine as this is not a 
>> common case (not happened before, to be precise).
> Until it get used, there will still be a probe of the filesystem to see 
> if a config directory/file exists
> that would impact every startup. I don't see a way to mitigate that 
> without making the config? more complex.
>>
>>>
>>> HijrahChronology.java:
>>>
>>> 291-295: Since registerCustomChrono is the only place where CONF_PATH 
>>> is used,
>>> ??? do all the work, including the property lookup in that method.
>>> 836:? If other chronologies are built-in this code will need to be 
>>> changed.
>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>> back to /conf/chronology?
>>
>> Yes, it would have to be changed if we support built-in type other 
>> than umalqura. But I would think other code would have to anyways. I 
>> think we can take advantage of the fact that umalqura is the only 
>> built-in, and others come from /conf/chronology so that extra fallback 
>> is avoided.
> Possibly, but could/would be more localized and consist of only the 
> registerChronology call.
>>
>>>
>>> 855: Since all the loading is triggered from a static initializer, is 
>>> there really any point in throwing an exception.
>>> ?? More useful would be a logging message (assuming logging is 
>>> allowed early in startup when Chronology is initialized)
>>
>> Good point. I will replace UncheckedIOException with logging.
>>
>>>
>>> 1054: readConfigProperties: The case for the other HijrahChronologies 
>>> delays loading the data until it is needed.
>>> This is doing the work to read the file and create the properties 
>>> instance but then discards it to be read a second time later.
>>>
>>> Perhaps we need to specify that the config file name includes both 
>>> the id and type so it can be registered without reading the file.
>>
>> Should the file name like "Hijrah-config-<id>_<type>.properties" work?
> yes, its worth checking the valid characters in id and type.
> 
> Thanks, Roger
> 
> BTW, the test drive can be implemented using testng, only the test 
> itself is easier as main().
> 
>>
>> Naoto
>>
>>>
>>> Regards, Roger
>>>
>>>
>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>
>>>>
>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Joe,
>>>>>
>>>>> Thank you for the review. Please find my comments below:
>>>>>
>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> Since it's dealing with non-standard properties files, is there a 
>>>>>> need to verify the files? The constructor (HijrahChronology) does 
>>>>>> check whether the id or type is empty. If there is no existing 
>>>>>> process to validate, it's probably not worth it to spend time as 
>>>>>> it's rare and it's config time.
>>>>>
>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>> (thus the faster the better) and cache it, then check the validity 
>>>>> later at actual method invocation (cf. checkCalendarInit() method).
>>>>
>>>> Make sense.
>>>>>
>>>>>>
>>>>>> The test summary states "Test image creation", it may be better to 
>>>>>> say sth. like verifies custom configuration?
>>>>>
>>>>> Good catch! I was simply copying some portion from other test case. 
>>>>> Corrected:
>>>>>
>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>
>>>> Looks good to me.
>>>>
>>>> Best regards,
>>>> Joe
>>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Best,
>>>>>> Joe
>>>>>>
>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please review the fix to the following issue:
>>>>>>>
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>
>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>
>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>
>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>> properties files. However it does not work as designed. This 
>>>>>>> change intends to make it work.
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>
>>>
> 

From Roger.Riggs at oracle.com  Thu Jan 16 20:06:01 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Thu, 16 Jan 2020 15:06:01 -0500
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <e342651f-65d6-2758-d3b3-e2bf75fdaf73@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>
 <e342651f-65d6-2758-d3b3-e2bf75fdaf73@oracle.com>
Message-ID: <eefc7c75-98bd-a3af-5912-0486f8c81391@oracle.com>

Hi Naoto,

A couple of comments in the tests.

HijrahConfigTest:

72:? Since onExit() starts a task in some executor and in some context,
 ?? its not clear that an exception thrown in that task will be reported.
 ? Use the normal p.waitFor() and check the exit code.

73: include the failed exit value in the exception; It may have some use 
in debugging.

HijrahConfigCheck:

41: The data structure is a set; no entry can appear twice; there's no 
point to the text
 ? or the value of count should be included in the exception

44: typo: Instatiation

48: if they are different, print the two chronologies

hijrah-config-Hijrah-test_islamic-test.properties:
 ?I would include a comment to say the data does not represent an actual 
calendar.

Roger

p.s.
!! tests.Helper is a very uninformative class name (but that's not your 
doing).






On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
> Updated:
>
> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>
> The change includes the new naming convention, reduction of properties 
> files reading to once, and utilization of logging.
>
> Naoto
>
> On 1/15/20 12:37 PM, Roger Riggs wrote:
>> Hi,
>>
>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>> Hi Roger,
>>>
>>> Thank you for the review. Please find my comments below:
>>>
>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> Is it correct to say that there is no impact on startup until there 
>>>> is an explicit reference to HijrahChronology?
>>>> It would seem that the registering HijrahChronology would trigger 
>>>> all the work and that happens when Chronology is initialized. (see 
>>>> below)
>>>
>>> What I meant in the reply to Joe's email was that the data validity 
>>> check done in loadCalendarData(), e.g., year value check, etc. which 
>>> are not done at class init. But you are correct that the properties 
>>> files are read twice (below). I thought it was fine as this is not a 
>>> common case (not happened before, to be precise).
>> Until it get used, there will still be a probe of the filesystem to 
>> see if a config directory/file exists
>> that would impact every startup. I don't see a way to mitigate that 
>> without making the config? more complex.
>>>
>>>>
>>>> HijrahChronology.java:
>>>>
>>>> 291-295: Since registerCustomChrono is the only place where 
>>>> CONF_PATH is used,
>>>> ??? do all the work, including the property lookup in that method.
>>>> 836:? If other chronologies are built-in this code will need to be 
>>>> changed.
>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>> back to /conf/chronology?
>>>
>>> Yes, it would have to be changed if we support built-in type other 
>>> than umalqura. But I would think other code would have to anyways. I 
>>> think we can take advantage of the fact that umalqura is the only 
>>> built-in, and others come from /conf/chronology so that extra 
>>> fallback is avoided.
>> Possibly, but could/would be more localized and consist of only the 
>> registerChronology call.
>>>
>>>>
>>>> 855: Since all the loading is triggered from a static initializer, 
>>>> is there really any point in throwing an exception.
>>>> ?? More useful would be a logging message (assuming logging is 
>>>> allowed early in startup when Chronology is initialized)
>>>
>>> Good point. I will replace UncheckedIOException with logging.
>>>
>>>>
>>>> 1054: readConfigProperties: The case for the other 
>>>> HijrahChronologies delays loading the data until it is needed.
>>>> This is doing the work to read the file and create the properties 
>>>> instance but then discards it to be read a second time later.
>>>>
>>>> Perhaps we need to specify that the config file name includes both 
>>>> the id and type so it can be registered without reading the file.
>>>
>>> Should the file name like "Hijrah-config-<id>_<type>.properties" work?
>> yes, its worth checking the valid characters in id and type.
>>
>> Thanks, Roger
>>
>> BTW, the test drive can be implemented using testng, only the test 
>> itself is easier as main().
>>
>>>
>>> Naoto
>>>
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>
>>>>>
>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>> Hi Joe,
>>>>>>
>>>>>> Thank you for the review. Please find my comments below:
>>>>>>
>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>> Hi Naoto,
>>>>>>>
>>>>>>> Since it's dealing with non-standard properties files, is there 
>>>>>>> a need to verify the files? The constructor (HijrahChronology) 
>>>>>>> does check whether the id or type is empty. If there is no 
>>>>>>> existing process to validate, it's probably not worth it to 
>>>>>>> spend time as it's rare and it's config time.
>>>>>>
>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>> validity later at actual method invocation (cf. 
>>>>>> checkCalendarInit() method).
>>>>>
>>>>> Make sense.
>>>>>>
>>>>>>>
>>>>>>> The test summary states "Test image creation", it may be better 
>>>>>>> to say sth. like verifies custom configuration?
>>>>>>
>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>> case. Corrected:
>>>>>>
>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>
>>>>> Looks good to me.
>>>>>
>>>>> Best regards,
>>>>> Joe
>>>>>
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>>>
>>>>>>> Best,
>>>>>>> Joe
>>>>>>>
>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> Please review the fix to the following issue:
>>>>>>>>
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>
>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>
>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>
>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>> change intends to make it work.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>
>>>>
>>


From naoto.sato at oracle.com  Thu Jan 16 21:08:53 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 16 Jan 2020 13:08:53 -0800
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <eefc7c75-98bd-a3af-5912-0486f8c81391@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>
 <e342651f-65d6-2758-d3b3-e2bf75fdaf73@oracle.com>
 <eefc7c75-98bd-a3af-5912-0486f8c81391@oracle.com>
Message-ID: <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>

Hi Roger,

Thanks. My comments are embedded below.

On 1/16/20 12:06 PM, Roger Riggs wrote:
> Hi Naoto,
> 
> A couple of comments in the tests.
> 
> HijrahConfigTest:
> 
> 72:? Since onExit() starts a task in some executor and in some context,
>  ?? its not clear that an exception thrown in that task will be reported.
>  ? Use the normal p.waitFor() and check the exit code.

Hmm, I was using the example in onExit() method, which reads:

---
API Note:
Using onExit is an alternative to waitFor that enables both additional 
concurrency and convenient access to the result of the Process.
---

So "alternative" is not "interchangeable" in this context?

> 
> 73: include the failed exit value in the exception; It may have some use 
> in debugging.

Anyway, I changed the above code to p.waitFor() for this reason.

> 
> HijrahConfigCheck:
> 
> 41: The data structure is a set; no entry can appear twice; there's no 
> point to the text
>  ? or the value of count should be included in the exception

At first I thought the same, but realized there could be a error case 
where "calendar type" in returned objects are the same, but objects 
themselves are different (thus the Set could accommodate both), so the test.

> 
> 44: typo: Instatiation
> 
> 48: if they are different, print the two chronologies
> 
> hijrah-config-Hijrah-test_islamic-test.properties:
>  ?I would include a comment to say the data does not represent an actual 
> calendar.

Corrected.

> 
> Roger
> 
> p.s.
> !! tests.Helper is a very uninformative class name (but that's not your 
> doing).

"Helper" is not helping in that regard :-)

Updated webrev: http://cr.openjdk.java.net/~naoto/8187987/webrev.03/

Naoto
> 
> 
> 
> 
> 
> 
> On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
>> Updated:
>>
>> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>>
>> The change includes the new naming convention, reduction of properties 
>> files reading to once, and utilization of logging.
>>
>> Naoto
>>
>> On 1/15/20 12:37 PM, Roger Riggs wrote:
>>> Hi,
>>>
>>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>>> Hi Roger,
>>>>
>>>> Thank you for the review. Please find my comments below:
>>>>
>>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>>> Hi Naoto,
>>>>>
>>>>> Is it correct to say that there is no impact on startup until there 
>>>>> is an explicit reference to HijrahChronology?
>>>>> It would seem that the registering HijrahChronology would trigger 
>>>>> all the work and that happens when Chronology is initialized. (see 
>>>>> below)
>>>>
>>>> What I meant in the reply to Joe's email was that the data validity 
>>>> check done in loadCalendarData(), e.g., year value check, etc. which 
>>>> are not done at class init. But you are correct that the properties 
>>>> files are read twice (below). I thought it was fine as this is not a 
>>>> common case (not happened before, to be precise).
>>> Until it get used, there will still be a probe of the filesystem to 
>>> see if a config directory/file exists
>>> that would impact every startup. I don't see a way to mitigate that 
>>> without making the config? more complex.
>>>>
>>>>>
>>>>> HijrahChronology.java:
>>>>>
>>>>> 291-295: Since registerCustomChrono is the only place where 
>>>>> CONF_PATH is used,
>>>>> ??? do all the work, including the property lookup in that method.
>>>>> 836:? If other chronologies are built-in this code will need to be 
>>>>> changed.
>>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>>> back to /conf/chronology?
>>>>
>>>> Yes, it would have to be changed if we support built-in type other 
>>>> than umalqura. But I would think other code would have to anyways. I 
>>>> think we can take advantage of the fact that umalqura is the only 
>>>> built-in, and others come from /conf/chronology so that extra 
>>>> fallback is avoided.
>>> Possibly, but could/would be more localized and consist of only the 
>>> registerChronology call.
>>>>
>>>>>
>>>>> 855: Since all the loading is triggered from a static initializer, 
>>>>> is there really any point in throwing an exception.
>>>>> ?? More useful would be a logging message (assuming logging is 
>>>>> allowed early in startup when Chronology is initialized)
>>>>
>>>> Good point. I will replace UncheckedIOException with logging.
>>>>
>>>>>
>>>>> 1054: readConfigProperties: The case for the other 
>>>>> HijrahChronologies delays loading the data until it is needed.
>>>>> This is doing the work to read the file and create the properties 
>>>>> instance but then discards it to be read a second time later.
>>>>>
>>>>> Perhaps we need to specify that the config file name includes both 
>>>>> the id and type so it can be registered without reading the file.
>>>>
>>>> Should the file name like "Hijrah-config-<id>_<type>.properties" work?
>>> yes, its worth checking the valid characters in id and type.
>>>
>>> Thanks, Roger
>>>
>>> BTW, the test drive can be implemented using testng, only the test 
>>> itself is easier as main().
>>>
>>>>
>>>> Naoto
>>>>
>>>>>
>>>>> Regards, Roger
>>>>>
>>>>>
>>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>>
>>>>>>
>>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>>> Hi Joe,
>>>>>>>
>>>>>>> Thank you for the review. Please find my comments below:
>>>>>>>
>>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>>> Hi Naoto,
>>>>>>>>
>>>>>>>> Since it's dealing with non-standard properties files, is there 
>>>>>>>> a need to verify the files? The constructor (HijrahChronology) 
>>>>>>>> does check whether the id or type is empty. If there is no 
>>>>>>>> existing process to validate, it's probably not worth it to 
>>>>>>>> spend time as it's rare and it's config time.
>>>>>>>
>>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>>> validity later at actual method invocation (cf. 
>>>>>>> checkCalendarInit() method).
>>>>>>
>>>>>> Make sense.
>>>>>>>
>>>>>>>>
>>>>>>>> The test summary states "Test image creation", it may be better 
>>>>>>>> to say sth. like verifies custom configuration?
>>>>>>>
>>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>>> case. Corrected:
>>>>>>>
>>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>>
>>>>>> Looks good to me.
>>>>>>
>>>>>> Best regards,
>>>>>> Joe
>>>>>>
>>>>>>>
>>>>>>> Naoto
>>>>>>>
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Joe
>>>>>>>>
>>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> Please review the fix to the following issue:
>>>>>>>>>
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>>
>>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>>
>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>>
>>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that it 
>>>>>>>>> could load custom variants of Hijirah calendar type using 
>>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>>> change intends to make it work.
>>>>>>>>>
>>>>>>>>> Naoto
>>>>>>>>
>>>>>>
>>>>>
>>>
> 

From Roger.Riggs at oracle.com  Fri Jan 17 21:07:37 2020
From: Roger.Riggs at oracle.com (Roger Riggs)
Date: Fri, 17 Jan 2020 16:07:37 -0500
Subject: <i18n dev> [15] RFR: 8187987: Add a mechanism to configure
 custom variants in HijrahChronology
In-Reply-To: <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>
References: <5f89a68c-9956-64c7-375f-07bd8024b836@oracle.com>
 <9cd6fdb6-7189-8737-3c1f-7d077ddf2930@oracle.com>
 <7a8628aa-f1ef-6020-8e5b-28a2493c642a@oracle.com>
 <765f4e2f-a4e3-586a-3273-79296acdc8d1@oracle.com>
 <eb7dcde9-a37d-1173-a1c8-fce3d26fa2cb@oracle.com>
 <16e2b4ee-b4c8-400f-02b3-eb0b09c6f749@oracle.com>
 <c413f9df-5986-9d02-9522-8ad4d5089567@oracle.com>
 <e342651f-65d6-2758-d3b3-e2bf75fdaf73@oracle.com>
 <eefc7c75-98bd-a3af-5912-0486f8c81391@oracle.com>
 <11107b9b-5c4f-8a60-642d-7341c63d7617@oracle.com>
Message-ID: <84fc0c00-a0af-d7e5-99f7-40649530c667@oracle.com>

Hi Naoto,

Looks good.? Thanks for the updates.

Roger


On 1/16/20 4:08 PM, naoto.sato at oracle.com wrote:
> Hi Roger,
>
> Thanks. My comments are embedded below.
>
> On 1/16/20 12:06 PM, Roger Riggs wrote:
>> Hi Naoto,
>>
>> A couple of comments in the tests.
>>
>> HijrahConfigTest:
>>
>> 72:? Since onExit() starts a task in some executor and in some context,
>> ??? its not clear that an exception thrown in that task will be 
>> reported.
>> ?? Use the normal p.waitFor() and check the exit code.
>
> Hmm, I was using the example in onExit() method, which reads:
>
> ---
> API Note:
> Using onExit is an alternative to waitFor that enables both additional 
> concurrency and convenient access to the result of the Process.
> ---
>
> So "alternative" is not "interchangeable" in this context?
onExit is useful to process the exit of a Process asynchronously.
>
>>
>> 73: include the failed exit value in the exception; It may have some 
>> use in debugging.
>
> Anyway, I changed the above code to p.waitFor() for this reason.
>
>>
>> HijrahConfigCheck:
>>
>> 41: The data structure is a set; no entry can appear twice; there's 
>> no point to the text
>> ?? or the value of count should be included in the exception
>
> At first I thought the same, but realized there could be a error case 
> where "calendar type" in returned objects are the same, but objects 
> themselves are different (thus the Set could accommodate both), so the 
> test.
I suppose that is up to the Chronology .equals method of each 
Chronology, I'd expect equals
to be checking all the fields of a Chronology.
>
>>
>> 44: typo: Instatiation
>>
>> 48: if they are different, print the two chronologies
>>
>> hijrah-config-Hijrah-test_islamic-test.properties:
>> ??I would include a comment to say the data does not represent an 
>> actual calendar.
>
> Corrected.
>
>>
>> Roger
>>
>> p.s.
>> !! tests.Helper is a very uninformative class name (but that's not 
>> your doing).
>
> "Helper" is not helping in that regard :-)
>
> Updated webrev: http://cr.openjdk.java.net/~naoto/8187987/webrev.03/
>
> Naoto
>>
>>
>>
>>
>>
>>
>> On 1/15/20 7:49 PM, naoto.sato at oracle.com wrote:
>>> Updated:
>>>
>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.02/
>>>
>>> The change includes the new naming convention, reduction of 
>>> properties files reading to once, and utilization of logging.
>>>
>>> Naoto
>>>
>>> On 1/15/20 12:37 PM, Roger Riggs wrote:
>>>> Hi,
>>>>
>>>> On 1/15/20 3:06 PM, naoto.sato at oracle.com wrote:
>>>>> Hi Roger,
>>>>>
>>>>> Thank you for the review. Please find my comments below:
>>>>>
>>>>> On 1/15/20 10:30 AM, Roger Riggs wrote:
>>>>>> Hi Naoto,
>>>>>>
>>>>>> Is it correct to say that there is no impact on startup until 
>>>>>> there is an explicit reference to HijrahChronology?
>>>>>> It would seem that the registering HijrahChronology would trigger 
>>>>>> all the work and that happens when Chronology is initialized. 
>>>>>> (see below)
>>>>>
>>>>> What I meant in the reply to Joe's email was that the data 
>>>>> validity check done in loadCalendarData(), e.g., year value check, 
>>>>> etc. which are not done at class init. But you are correct that 
>>>>> the properties files are read twice (below). I thought it was fine 
>>>>> as this is not a common case (not happened before, to be precise).
>>>> Until it get used, there will still be a probe of the filesystem to 
>>>> see if a config directory/file exists
>>>> that would impact every startup. I don't see a way to mitigate that 
>>>> without making the config? more complex.
>>>>>
>>>>>>
>>>>>> HijrahChronology.java:
>>>>>>
>>>>>> 291-295: Since registerCustomChrono is the only place where 
>>>>>> CONF_PATH is used,
>>>>>> ??? do all the work, including the property lookup in that method.
>>>>>> 836:? If other chronologies are built-in this code will need to 
>>>>>> be changed.
>>>>>> ??? Can it do the getResourceAsStream first in all cases and fall 
>>>>>> back to /conf/chronology?
>>>>>
>>>>> Yes, it would have to be changed if we support built-in type other 
>>>>> than umalqura. But I would think other code would have to anyways. 
>>>>> I think we can take advantage of the fact that umalqura is the 
>>>>> only built-in, and others come from /conf/chronology so that extra 
>>>>> fallback is avoided.
>>>> Possibly, but could/would be more localized and consist of only the 
>>>> registerChronology call.
>>>>>
>>>>>>
>>>>>> 855: Since all the loading is triggered from a static 
>>>>>> initializer, is there really any point in throwing an exception.
>>>>>> ?? More useful would be a logging message (assuming logging is 
>>>>>> allowed early in startup when Chronology is initialized)
>>>>>
>>>>> Good point. I will replace UncheckedIOException with logging.
>>>>>
>>>>>>
>>>>>> 1054: readConfigProperties: The case for the other 
>>>>>> HijrahChronologies delays loading the data until it is needed.
>>>>>> This is doing the work to read the file and create the properties 
>>>>>> instance but then discards it to be read a second time later.
>>>>>>
>>>>>> Perhaps we need to specify that the config file name includes 
>>>>>> both the id and type so it can be registered without reading the 
>>>>>> file.
>>>>>
>>>>> Should the file name like "Hijrah-config-<id>_<type>.properties" 
>>>>> work?
>>>> yes, its worth checking the valid characters in id and type.
>>>>
>>>> Thanks, Roger
>>>>
>>>> BTW, the test drive can be implemented using testng, only the test 
>>>> itself is easier as main().
>>>>
>>>>>
>>>>> Naoto
>>>>>
>>>>>>
>>>>>> Regards, Roger
>>>>>>
>>>>>>
>>>>>> On 1/14/20 9:37 PM, Joe Wang wrote:
>>>>>>>
>>>>>>>
>>>>>>> On 1/14/20 6:04 PM, naoto.sato at oracle.com wrote:
>>>>>>>> Hi Joe,
>>>>>>>>
>>>>>>>> Thank you for the review. Please find my comments below:
>>>>>>>>
>>>>>>>> On 1/14/20 3:35 PM, Joe Wang wrote:
>>>>>>>>> Hi Naoto,
>>>>>>>>>
>>>>>>>>> Since it's dealing with non-standard properties files, is 
>>>>>>>>> there a need to verify the files? The constructor 
>>>>>>>>> (HijrahChronology) does check whether the id or type is empty. 
>>>>>>>>> If there is no existing process to validate, it's probably not 
>>>>>>>>> worth it to spend time as it's rare and it's config time.
>>>>>>>>
>>>>>>>> IIUC, the idea is to create the instance at class loading time 
>>>>>>>> (thus the faster the better) and cache it, then check the 
>>>>>>>> validity later at actual method invocation (cf. 
>>>>>>>> checkCalendarInit() method).
>>>>>>>
>>>>>>> Make sense.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> The test summary states "Test image creation", it may be 
>>>>>>>>> better to say sth. like verifies custom configuration?
>>>>>>>>
>>>>>>>> Good catch! I was simply copying some portion from other test 
>>>>>>>> case. Corrected:
>>>>>>>>
>>>>>>>> https://cr.openjdk.java.net/~naoto/8187987/webrev.01/
>>>>>>>
>>>>>>> Looks good to me.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Joe
>>>>>>>
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Best,
>>>>>>>>> Joe
>>>>>>>>>
>>>>>>>>> On 1/14/20 8:35 AM, naoto.sato at oracle.com wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Please review the fix to the following issue:
>>>>>>>>>>
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8187987
>>>>>>>>>>
>>>>>>>>>> The proposed CSR and changeset are located at:
>>>>>>>>>>
>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8236810
>>>>>>>>>> Webrev: https://cr.openjdk.java.net/~naoto/8187987/webrev.00/
>>>>>>>>>>
>>>>>>>>>> The spec of java.time.chrono.HijrahChronology suggests that 
>>>>>>>>>> it could load custom variants of Hijirah calendar type using 
>>>>>>>>>> properties files. However it does not work as designed. This 
>>>>>>>>>> change intends to make it work.
>>>>>>>>>>
>>>>>>>>>> Naoto
>>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>


From takiguc at linux.vnet.ibm.com  Mon Jan 20 12:30:51 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 20 Jan 2020 21:30:51 +0900
Subject: <i18n dev> RFR: CSR JDK-8233385 Align some one-way conversion
 in MS950 charset with Windows
In-Reply-To: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
References: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
Message-ID: <ba86d6af16dc9328550e3a6b1b4758cb@linux.vnet.ibm.com>

Hello.
This is just a gentle reminder.

Could you review CSR JDK-8233385 [1] ?

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

Thanks,
Ichiroh Takiguchi

On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
> Hello.
> 
> Could you review CSR JDK-8233385 [1] ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From takiguc at linux.vnet.ibm.com  Mon Jan 20 12:40:54 2020
From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi)
Date: Mon, 20 Jan 2020 21:40:54 +0900
Subject: <i18n dev> 8236548 Concern about CLDR Timezone translated data
Message-ID: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>

Hello.

I have 2 concerns about CLDR Timezone translated data.
The detail information is in JDK-8236548 [1].

Can you show me how to solve this kind of ICU related issue ?

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

Thanks,
Ichiroh Takiguchi
IBM Japan, Ltd.

From naoto.sato at oracle.com  Tue Jan 21 17:47:35 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jan 2020 09:47:35 -0800
Subject: <i18n dev> RFR: CSR JDK-8233385 Align some one-way conversion
 in MS950 charset with Windows
In-Reply-To: <ba86d6af16dc9328550e3a6b1b4758cb@linux.vnet.ibm.com>
References: <5634595223da60582929579e7abb77f5@linux.vnet.ibm.com>
 <ba86d6af16dc9328550e3a6b1b4758cb@linux.vnet.ibm.com>
Message-ID: <5c110af7-15de-dce1-5396-0a1b96bf5221@oracle.com>

Looks good to me.

Naoto

On 1/20/20 4:30 AM, Ichiroh Takiguchi wrote:
> Hello.
> This is just a gentle reminder.
> 
> Could you review CSR JDK-8233385 [1] ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
> 
> Thanks,
> Ichiroh Takiguchi
> 
> On 2020-01-10 22:13, Ichiroh Takiguchi wrote:
>> Hello.
>>
>> Could you review CSR JDK-8233385 [1] ?
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8233385
>>
>> Thanks,
>> Ichiroh Takiguchi
>> IBM Japan, Ltd.

From naoto.sato at oracle.com  Tue Jan 21 17:52:21 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Tue, 21 Jan 2020 09:52:21 -0800
Subject: <i18n dev> 8236548 Concern about CLDR Timezone translated data
In-Reply-To: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>
References: <5351cf9432d980e9e1e86a9e6458bf2f@linux.vnet.ibm.com>
Message-ID: <b9e2d6cf-2518-3b06-39c6-084f73a0a6a2@oracle.com>

Hi Takiguchi-san,

We are aware of some discrepancy between English time zone display names 
and other languages' ones, as CLDR converter uses English display names 
of COMPAT provider, for performance/compatibility reasons.

Please assign the issue to me. I will look into it.

Naoto

On 1/20/20 4:40 AM, Ichiroh Takiguchi wrote:
> Hello.
> 
> I have 2 concerns about CLDR Timezone translated data.
> The detail information is in JDK-8236548 [1].
> 
> Can you show me how to solve this kind of ICU related issue ?
> 
> [1] https://bugs.openjdk.java.net/browse/JDK-8236548
> 
> Thanks,
> Ichiroh Takiguchi
> IBM Japan, Ltd.

From p.gomulka at hotmail.com  Wed Jan 22 13:37:25 2020
From: p.gomulka at hotmail.com (Przemyslaw Gomulka)
Date: Wed, 22 Jan 2020 13:37:25 +0000
Subject: <i18n dev> Defaulting Week Fields behaviour to ISO standard
Message-ID: <VI1PR06MB599839A4E3D6F753A2615E4EE70C0@VI1PR06MB5998.eurprd06.prod.outlook.com>

Hello,
I am not sure this is the right place to ask, but I couldn't find answers anywhere else.

I want my application to parse and format dates basing on start of the week being Monday and requiring 4days in the first week of the year.
This was the behaviour existing previously in joda.org library, but seems like this was now defaulted to start of the week Sunday and requires only 1day of the week - looks like basing on US locale
I understand that I can specify a locale and this will allow me to parse my dates with these rules.
However I have planty of formatters where I cannot tell what locale should be used, and wanted to use Locale.ROOT which sadly defaults to Sunday,1.

I can workaround this with unicode extension ?fw? for Locale.ROOT and default to ?sun?. I can?t find the extension for minimal days in the first week.
Loading a custom CalendarDataProvider works for me, but relies on a my Custom implementation to be present on a classpath.

Both workarounds were introduced in JDK9.
JDK8 do not allow me to load SPI implementation from a classpath - requires these classes to be placed in a jar in jre/lib/ext. Unfortunately I cannot control what a user of the application will have in their JRE. It would be great if https://bugs-stage.openjdk.java.net/browse/JDK-8167324 was also backported to 8.

--
How can I work around in JDK8? Is there any other preferred way to achieve this?
--

What was the reasoning to default to Sunday,1 ? I think it was incorrectly assumed that this is common. As per incorrect in my opinion javadoc in java.time.temporal.WeekFields.java:222 (jdk12)
* This week definition is in use in the US and other European countries.
*/
public static final WeekFields SUNDAY_START = WeekFields.of(DayOfWeek.SUNDAY, 1);


Thank you
Przemek Gomulka

From naoto.sato at oracle.com  Wed Jan 22 18:21:33 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 22 Jan 2020 10:21:33 -0800
Subject: <i18n dev> Defaulting Week Fields behaviour to ISO standard
In-Reply-To: <VI1PR06MB599839A4E3D6F753A2615E4EE70C0@VI1PR06MB5998.eurprd06.prod.outlook.com>
References: <VI1PR06MB599839A4E3D6F753A2615E4EE70C0@VI1PR06MB5998.eurprd06.prod.outlook.com>
Message-ID: <e56aa99b-5444-561d-7584-2bd88411cfa9@oracle.com>

Hi Przemek,

On 1/22/20 5:37 AM, Przemyslaw Gomulka wrote:
> Hello,
> I am not sure this is the right place to ask, but I couldn't find answers anywhere else.
> 
> I want my application to parse and format dates basing on start of the week being Monday and requiring 4days in the first week of the year.
> This was the behaviour existing previously in joda.org library, but seems like this was now defaulted to start of the week Sunday and requires only 1day of the week - looks like basing on US locale
> I understand that I can specify a locale and this will allow me to parse my dates with these rules.
> However I have planty of formatters where I cannot tell what locale should be used, and wanted to use Locale.ROOT which sadly defaults to Sunday,1.
> 
> I can workaround this with unicode extension ?fw? for Locale.ROOT and default to ?sun?. I can?t find the extension for minimal days in the first week.
> Loading a custom CalendarDataProvider works for me, but relies on a my Custom implementation to be present on a classpath.
> 
> Both workarounds were introduced in JDK9.
> JDK8 do not allow me to load SPI implementation from a classpath - requires these classes to be placed in a jar in jre/lib/ext. Unfortunately I cannot control what a user of the application will have in their JRE. It would be great if https://bugs-stage.openjdk.java.net/browse/JDK-8167324 was also backported to 8.
> 
> --
> How can I work around in JDK8? Is there any other preferred way to achieve this?
> --

Implementing your custom CalendarDataProvider is the right way to go. On 
JDK8, you can use the system property "java.ext.dirs" to specify the 
directory where extensions are loaded from, so that you will not need to 
modify customer's JRE installations.

> 
> What was the reasoning to default to Sunday,1 ? I think it was incorrectly assumed that this is common. As per incorrect in my opinion javadoc in java.time.temporal.WeekFields.java:222 (jdk12)
> * This week definition is in use in the US and other European countries.
> */
> public static final WeekFields SUNDAY_START = WeekFields.of(DayOfWeek.SUNDAY, 1);

I am not sure the reason as I am not the designer for this, but it is 
not surprising because Locale.US is the only required locale in the JDK:

https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/Locale.html#getAvailableLocales()

Naoto

From p.gomulka at hotmail.com  Tue Jan 28 18:08:07 2020
From: p.gomulka at hotmail.com (Przemyslaw Gomulka)
Date: Tue, 28 Jan 2020 18:08:07 +0000
Subject: <i18n dev> ODP:  Defaulting Week Fields behaviour to ISO standard
In-Reply-To: <e56aa99b-5444-561d-7584-2bd88411cfa9@oracle.com>
References: <VI1PR06MB599839A4E3D6F753A2615E4EE70C0@VI1PR06MB5998.eurprd06.prod.outlook.com>,
 <e56aa99b-5444-561d-7584-2bd88411cfa9@oracle.com>
Message-ID: <VI1PR06MB5998C4783862497A6244D652E70A0@VI1PR06MB5998.eurprd06.prod.outlook.com>

Hey Nato,
Thank you for a quick reply!

Regards,
Przemek
________________________________
Od: naoto.sato at oracle.com <naoto.sato at oracle.com>
Wys?ane: ?roda, 22 stycznia 2020 19:21
Do: Przemyslaw Gomulka <p.gomulka at hotmail.com>; i18n-dev at openjdk.java.net <i18n-dev at openjdk.java.net>
Temat: Re: <i18n dev> Defaulting Week Fields behaviour to ISO standard

Hi Przemek,

On 1/22/20 5:37 AM, Przemyslaw Gomulka wrote:
> Hello,
> I am not sure this is the right place to ask, but I couldn't find answers anywhere else.
>
> I want my application to parse and format dates basing on start of the week being Monday and requiring 4days in the first week of the year.
> This was the behaviour existing previously in joda.org library, but seems like this was now defaulted to start of the week Sunday and requires only 1day of the week - looks like basing on US locale
> I understand that I can specify a locale and this will allow me to parse my dates with these rules.
> However I have planty of formatters where I cannot tell what locale should be used, and wanted to use Locale.ROOT which sadly defaults to Sunday,1.
>
> I can workaround this with unicode extension ?fw? for Locale.ROOT and default to ?sun?. I can?t find the extension for minimal days in the first week.
> Loading a custom CalendarDataProvider works for me, but relies on a my Custom implementation to be present on a classpath.
>
> Both workarounds were introduced in JDK9.
> JDK8 do not allow me to load SPI implementation from a classpath - requires these classes to be placed in a jar in jre/lib/ext. Unfortunately I cannot control what a user of the application will have in their JRE. It would be great if https://bugs-stage.openjdk.java.net/browse/JDK-8167324 was also backported to 8.
>
> --
> How can I work around in JDK8? Is there any other preferred way to achieve this?
> --

Implementing your custom CalendarDataProvider is the right way to go. On
JDK8, you can use the system property "java.ext.dirs" to specify the
directory where extensions are loaded from, so that you will not need to
modify customer's JRE installations.

>
> What was the reasoning to default to Sunday,1 ? I think it was incorrectly assumed that this is common. As per incorrect in my opinion javadoc in java.time.temporal.WeekFields.java:222 (jdk12)
> * This week definition is in use in the US and other European countries.
> */
> public static final WeekFields SUNDAY_START = WeekFields.of(DayOfWeek.SUNDAY, 1);

I am not sure the reason as I am not the designer for this, but it is
not surprising because Locale.US is the only required locale in the JDK:

https://docs.oracle.com/en/java/javase/13/docs/api/java.base/java/util/Locale.html#getAvailableLocales()

Naoto

From suenaga at oss.nttdata.com  Wed Jan 29 07:51:10 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Wed, 29 Jan 2020 16:51:10 +0900
Subject: <i18n dev> Get UI language ID on Windows
Message-ID: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>

Hi all,

I checked how JDK detects default language on Windows, but I cannot understand the code
in below:

src/java.base/windows/native/libjava/java_props_md.c:
```
LCID userDefaultUILang = GetUserDefaultUILanguage();
```

According to MSDN [1], GetUserDefaultUILanguage() returns LANGID.
`userDefaultUILang` is used later as LCID. I think it is wrong.

I think we should be fix it as below.
If it is correct, I will file it to JBS and will send webrev.

```
diff --git a/src/java.base/windows/native/libjava/java_props_md.c b/src/java.base/windows/native/libjava/java_props_md.cindex 231f44ce2b..9068595dcf 100644
--- a/src/java.base/windows/native/libjava/java_props_md.c
+++ b/src/java.base/windows/native/libjava/java_props_md.c
@@ -641,7 +641,7 @@ GetJavaProperties(JNIEnv* env)
           */
          LCID userDefaultLCID = GetUserDefaultLCID();
          LCID systemDefaultLCID = GetSystemDefaultLCID();
-        LCID userDefaultUILang = GetUserDefaultUILanguage();
+        LANGID userDefaultUILang = GetUserDefaultUILanguage();

          {
              char * display_encoding;
@@ -655,8 +655,8 @@ GetJavaProperties(JNIEnv* env)
              // for the UI Language, if the "language" portion of those
              // two locales are the same.
              if (PRIMARYLANGID(LANGIDFROMLCID(userDefaultLCID)) ==
-                PRIMARYLANGID(LANGIDFROMLCID(userDefaultUILang))) {
-                userDefaultUILang = userDefaultLCID;
+                PRIMARYLANGID(userDefaultUILang)) {
+                userDefaultUILang = LANGIDFROMLCID(userDefaultLCID);
              }

              SetupI18nProps(userDefaultLCID,
@@ -665,7 +665,7 @@ GetJavaProperties(JNIEnv* env)
                             &sprops.format_country,
                             &sprops.format_variant,
                             &sprops.encoding);
-            SetupI18nProps(userDefaultUILang,
+            SetupI18nProps(MAKELCID(userDefaultUILang, SORT_DEFAULT),
                             &sprops.display_language,
                             &sprops.display_script,
                             &sprops.display_country,
```

Do you have any comments / suggestions?


Thanks,

Yasumasa


[1] https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultuilanguage

From naoto.sato at oracle.com  Wed Jan 29 18:15:40 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 29 Jan 2020 10:15:40 -0800
Subject: <i18n dev> Get UI language ID on Windows
In-Reply-To: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
Message-ID: <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>

Hi Suenaga-san,

I think your fix looks reasonable. Although currently sort id is not 
being used, I'd replace 'SORT_DEFAULT' with 
'SORTIDFROMLCID(userDefaultLCID)', which is more of a correct usage.

Naoto

On 1/28/20 11:51 PM, Yasumasa Suenaga wrote:
> Hi all,
> 
> I checked how JDK detects default language on Windows, but I cannot 
> understand the code
> in below:
> 
> src/java.base/windows/native/libjava/java_props_md.c:
> ```
> LCID userDefaultUILang = GetUserDefaultUILanguage();
> ```
> 
> According to MSDN [1], GetUserDefaultUILanguage() returns LANGID.
> `userDefaultUILang` is used later as LCID. I think it is wrong.
> 
> I think we should be fix it as below.
> If it is correct, I will file it to JBS and will send webrev.
> 
> ```
> diff --git a/src/java.base/windows/native/libjava/java_props_md.c 
> b/src/java.base/windows/native/libjava/java_props_md.cindex 
> 231f44ce2b..9068595dcf 100644
> --- a/src/java.base/windows/native/libjava/java_props_md.c
> +++ b/src/java.base/windows/native/libjava/java_props_md.c
> @@ -641,7 +641,7 @@ GetJavaProperties(JNIEnv* env)
>  ????????? */
>  ???????? LCID userDefaultLCID = GetUserDefaultLCID();
>  ???????? LCID systemDefaultLCID = GetSystemDefaultLCID();
> -??????? LCID userDefaultUILang = GetUserDefaultUILanguage();
> +??????? LANGID userDefaultUILang = GetUserDefaultUILanguage();
> 
>  ???????? {
>  ???????????? char * display_encoding;
> @@ -655,8 +655,8 @@ GetJavaProperties(JNIEnv* env)
>  ???????????? // for the UI Language, if the "language" portion of those
>  ???????????? // two locales are the same.
>  ???????????? if (PRIMARYLANGID(LANGIDFROMLCID(userDefaultLCID)) ==
> -??????????????? PRIMARYLANGID(LANGIDFROMLCID(userDefaultUILang))) {
> -??????????????? userDefaultUILang = userDefaultLCID;
> +??????????????? PRIMARYLANGID(userDefaultUILang)) {
> +??????????????? userDefaultUILang = LANGIDFROMLCID(userDefaultLCID);
>  ???????????? }
> 
>  ???????????? SetupI18nProps(userDefaultLCID,
> @@ -665,7 +665,7 @@ GetJavaProperties(JNIEnv* env)
>  ??????????????????????????? &sprops.format_country,
>  ??????????????????????????? &sprops.format_variant,
>  ??????????????????????????? &sprops.encoding);
> -??????????? SetupI18nProps(userDefaultUILang,
> +??????????? SetupI18nProps(MAKELCID(userDefaultUILang, SORT_DEFAULT),
>  ??????????????????????????? &sprops.display_language,
>  ??????????????????????????? &sprops.display_script,
>  ??????????????????????????? &sprops.display_country,
> ```
> 
> Do you have any comments / suggestions?
> 
> 
> Thanks,
> 
> Yasumasa
> 
> 
> [1] 
> https://docs.microsoft.com/en-us/windows/win32/api/winnls/nf-winnls-getuserdefaultuilanguage 
> 

From suenaga at oss.nttdata.com  Thu Jan 30 03:36:28 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Thu, 30 Jan 2020 12:36:28 +0900
Subject: <i18n dev> RFR: 8238203: Return value of GetUserDefaultUILanguage()
 should be handled as LANGID
In-Reply-To: <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
Message-ID: <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>

Hi Sato-san,

I filed it to JBS, and create webrev.
Could you review it?

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


Thanks,

Yasumasa


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

From naoto.sato at oracle.com  Thu Jan 30 19:23:57 2020
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Thu, 30 Jan 2020 11:23:57 -0800
Subject: <i18n dev> RFR: 8238203: Return value of
 GetUserDefaultUILanguage() should be handled as LANGID
In-Reply-To: <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
 <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
Message-ID: <ccfc310b-d655-47f7-ba30-3d894310f169@oracle.com>

Looks good to me. Thanks for fixing it.

Please add 'noreg-*' label to the JBS issue if you are not planning to 
provide a regression test.

Naoto

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

From suenaga at oss.nttdata.com  Thu Jan 30 22:38:28 2020
From: suenaga at oss.nttdata.com (Yasumasa Suenaga)
Date: Fri, 31 Jan 2020 07:38:28 +0900
Subject: <i18n dev> RFR: 8238203: Return value of
 GetUserDefaultUILanguage() should be handled as LANGID
In-Reply-To: <ccfc310b-d655-47f7-ba30-3d894310f169@oracle.com>
References: <37a7f2cf-ce7b-7907-ae5e-64ec8a114776@oss.nttdata.com>
 <c11ffd33-93f6-50fa-c89d-19a49d6d7e77@oracle.com>
 <9013a4ec-f725-5766-b948-28e04f3a097b@oss.nttdata.com>
 <ccfc310b-d655-47f7-ba30-3d894310f169@oracle.com>
Message-ID: <ae2fdf6b-ee0c-6c68-5fb4-760949c48ca0@oss.nttdata.com>

Thanks Sato-san!

I added 'noreg-hard' to the JBS issue.


Yasumasa


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