From naoto.sato at oracle.com  Tue Sep  4 18:14:45 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 4 Sep 2018 11:14:45 -0700
Subject: <i18n dev> [12] RFR: 8210142: java.util.Calendar.clone() doesn't
 respect sharedZone flag
Message-ID: <4adbd990-dee9-1c86-b859-c2a63a59f111@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed fix is located at:

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

The fix is a simple one line change, which is to make the sharedZone 
field consistent with the cloned TimeZone instance in Calendar.clone().

Naoto

From naoto.sato at oracle.com  Mon Sep 10 21:34:41 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 10 Sep 2018 14:34:41 -0700
Subject: <i18n dev> [12]: RFR: Use CLDR's time zone mappings for Windows
Message-ID: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

This fix is to remove the hand crafted map file (lib/tzmappings) on 
Windows, which maps Windows time zones to Java's tzid. It is now 
dynamically generated at the build time, using CLDR's data file 
(windowsZones.xml)

Naoto

From erik.joelsson at oracle.com  Mon Sep 10 21:43:15 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 10 Sep 2018 14:43:15 -0700
Subject: <i18n dev> [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
Message-ID: <f08f18d0-1920-10d7-8819-9a60898439b4@oracle.com>

Looks good.

/Erik


On 2018-09-10 14:34, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209167
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>
> This fix is to remove the hand crafted map file (lib/tzmappings) on 
> Windows, which maps Windows time zones to Java's tzid. It is now 
> dynamically generated at the build time, using CLDR's data file 
> (windowsZones.xml)
>
> Naoto


From magnus.ihse.bursie at oracle.com  Wed Sep 12 10:19:59 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 12 Sep 2018 12:19:59 +0200
Subject: <i18n dev> [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
Message-ID: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>



On 2018-09-10 23:34, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209167
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/

Some comments:
In make/copy/Copy-java.base.gmk:
+ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)

The findstring construct is hard to read and only needed when we test 
more than one OS. Please rewrite as a single ifeq test for aix.

In GensrcCLDR.gmk:
I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
generate it, there's just a dependency..?

The removal of the duplicate "common", that seems like a separate bug fix?

/Magnus

>
> This fix is to remove the hand crafted map file (lib/tzmappings) on 
> Windows, which maps Windows time zones to Java's tzid. It is now 
> dynamically generated at the build time, using CLDR's data file 
> (windowsZones.xml)
>
> Naoto


From magnus.ihse.bursie at oracle.com  Wed Sep 12 10:32:14 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 12 Sep 2018 12:32:14 +0200
Subject: <i18n dev> [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
Message-ID: <fd707ac4-5de1-64bb-bdd1-9baaa10c14ba@oracle.com>


On 2018-09-12 12:19, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-10 23:34, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/

Oh, and there's a typo in CLDRConverter.java: " Note: the entries are 
alphabetically soreted, *except* the "world" region".

/Magnus

From erik.joelsson at oracle.com  Wed Sep 12 16:08:52 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Sep 2018 09:08:52 -0700
Subject: <i18n dev> [12]: RFR: Use CLDR's time zone mappings for Windows
In-Reply-To: <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
Message-ID: <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>

On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>
>
> On 2018-09-10 23:34, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>
> Some comments:
> In make/copy/Copy-java.base.gmk:
> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>
> The findstring construct is hard to read and only needed when we test 
> more than one OS. Please rewrite as a single ifeq test for aix.
>
> In GensrcCLDR.gmk:
> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
> generate it, there's just a dependency..?
>
It's generated by the same rule as the other file. This is the easiest 
workaround for two files generated from the same rule. It sort of works 
(for clean builds and if the input is chagned), but won't handle all 
cases where one file is removed externally and the other is not. I 
suggested this construct to Naoto. Perhaps a comment explaining this 
would be good.
> The removal of the duplicate "common", that seems like a separate bug 
> fix?
>
It does indeed. Before this fix, the wildcards must have returned empty.

/Erik
> /Magnus
>
>>
>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>> Windows, which maps Windows time zones to Java's tzid. It is now 
>> dynamically generated at the build time, using CLDR's data file 
>> (windowsZones.xml)
>>
>> Naoto
>


From naoto.sato at oracle.com  Wed Sep 12 17:33:44 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 12 Sep 2018 10:33:44 -0700
Subject: <i18n dev> [12]: RFR: 8209167: Use CLDR's time zone mappings
	for Windows
In-Reply-To: <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
Message-ID: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>

Hi Magnus, Erik,

Thank you for your comments. I updated the webrev according to your 
suggestions:

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

As to the duplicated "common" in the dependency, yes that's a separate 
issue. Since it's obvious, I included the fix with this changeset (it 
was actually described as a comment in the jira issue).

Naoto

On 9/12/18 9:08 AM, Erik Joelsson wrote:
> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>
>>
>> On 2018-09-10 23:34, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix to the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>
>>> The proposed changeset is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>
>> Some comments:
>> In make/copy/Copy-java.base.gmk:
>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>
>> The findstring construct is hard to read and only needed when we test 
>> more than one OS. Please rewrite as a single ifeq test for aix.
>>
>> In GensrcCLDR.gmk:
>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>> generate it, there's just a dependency..?
>>
> It's generated by the same rule as the other file. This is the easiest 
> workaround for two files generated from the same rule. It sort of works 
> (for clean builds and if the input is chagned), but won't handle all 
> cases where one file is removed externally and the other is not. I 
> suggested this construct to Naoto. Perhaps a comment explaining this 
> would be good.
>> The removal of the duplicate "common", that seems like a separate bug 
>> fix?
>>
> It does indeed. Before this fix, the wildcards must have returned empty.
> 
> /Erik
>> /Magnus
>>
>>>
>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>> dynamically generated at the build time, using CLDR's data file 
>>> (windowsZones.xml)
>>>
>>> Naoto
>>
> 

From erik.joelsson at oracle.com  Wed Sep 12 17:34:59 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 12 Sep 2018 10:34:59 -0700
Subject: <i18n dev> [12]: RFR: 8209167: Use CLDR's time zone mappings
	for Windows
In-Reply-To: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
 <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
Message-ID: <f73ea10e-74cf-3d4a-0760-deafe9fef400@oracle.com>

Looks good.

/Erik


On 2018-09-12 10:33, naoto.sato at oracle.com wrote:
> Hi Magnus, Erik,
>
> Thank you for your comments. I updated the webrev according to your 
> suggestions:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
>
> As to the duplicated "common" in the dependency, yes that's a separate 
> issue. Since it's obvious, I included the fix with this changeset (it 
> was actually described as a comment in the jira issue).
>
> Naoto
>
> On 9/12/18 9:08 AM, Erik Joelsson wrote:
>> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-09-10 23:34, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>>
>>> Some comments:
>>> In make/copy/Copy-java.base.gmk:
>>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>>
>>> The findstring construct is hard to read and only needed when we 
>>> test more than one OS. Please rewrite as a single ifeq test for aix.
>>>
>>> In GensrcCLDR.gmk:
>>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>>> generate it, there's just a dependency..?
>>>
>> It's generated by the same rule as the other file. This is the 
>> easiest workaround for two files generated from the same rule. It 
>> sort of works (for clean builds and if the input is chagned), but 
>> won't handle all cases where one file is removed externally and the 
>> other is not. I suggested this construct to Naoto. Perhaps a comment 
>> explaining this would be good.
>>> The removal of the duplicate "common", that seems like a separate 
>>> bug fix?
>>>
>> It does indeed. Before this fix, the wildcards must have returned empty.
>>
>> /Erik
>>> /Magnus
>>>
>>>>
>>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>>> dynamically generated at the build time, using CLDR's data file 
>>>> (windowsZones.xml)
>>>>
>>>> Naoto
>>>
>>


From magnus.ihse.bursie at oracle.com  Thu Sep 13 19:22:33 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 13 Sep 2018 21:22:33 +0200
Subject: <i18n dev> [12]: RFR: 8209167: Use CLDR's time zone mappings
	for Windows
In-Reply-To: <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
References: <522db1f0-0456-21f5-1ab7-d9fff694e00a@oracle.com>
 <a801cebe-5c0b-62a5-6432-f7e0b281a801@oracle.com>
 <d36b7633-89b2-59bf-2628-e8a3af64ff4d@oracle.com>
 <8cc0cc61-bc5f-e6fa-5488-7d18e426858b@oracle.com>
Message-ID: <09fb76fa-3924-8968-aae0-ce86520a8950@oracle.com>



On 2018-09-12 19:33, naoto.sato at oracle.com wrote:
> Hi Magnus, Erik,
>
> Thank you for your comments. I updated the webrev according to your 
> suggestions:
>
> http://cr.openjdk.java.net/~naoto/8209167/webrev.02/
Looks good to me.

/Magnus

>
> As to the duplicated "common" in the dependency, yes that's a separate 
> issue. Since it's obvious, I included the fix with this changeset (it 
> was actually described as a comment in the jira issue).
>
> Naoto
>
> On 9/12/18 9:08 AM, Erik Joelsson wrote:
>> On 2018-09-12 03:19, Magnus Ihse Bursie wrote:
>>>
>>>
>>> On 2018-09-10 23:34, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8209167
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8209167/webrev.01/
>>>
>>> Some comments:
>>> In make/copy/Copy-java.base.gmk:
>>> +ifneq ($(findstring $(OPENJDK_TARGET_OS), aix),)
>>>
>>> The findstring construct is hard to read and only needed when we 
>>> test more than one OS. Please rewrite as a single ifeq test for aix.
>>>
>>> In GensrcCLDR.gmk:
>>> I don't understand the CLDR_WINTZMAPPINGS file? There's no rule to 
>>> generate it, there's just a dependency..?
>>>
>> It's generated by the same rule as the other file. This is the 
>> easiest workaround for two files generated from the same rule. It 
>> sort of works (for clean builds and if the input is chagned), but 
>> won't handle all cases where one file is removed externally and the 
>> other is not. I suggested this construct to Naoto. Perhaps a comment 
>> explaining this would be good.
>>> The removal of the duplicate "common", that seems like a separate 
>>> bug fix?
>>>
>> It does indeed. Before this fix, the wildcards must have returned empty.
>>
>> /Erik
>>> /Magnus
>>>
>>>>
>>>> This fix is to remove the hand crafted map file (lib/tzmappings) on 
>>>> Windows, which maps Windows time zones to Java's tzid. It is now 
>>>> dynamically generated at the build time, using CLDR's data file 
>>>> (windowsZones.xml)
>>>>
>>>> Naoto
>>>
>>


From rachna.goel at oracle.com  Fri Sep 14 12:54:57 2018
From: rachna.goel at oracle.com (Rachna Goel)
Date: Fri, 14 Sep 2018 18:24:57 +0530
Subject: <i18n dev> [12] RFR:8210490:TimeZone.getDisplayName given Locale.US
 doesn't always honor the Locale
Message-ID: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>

Hi,

Kindly review fix to JDK-8210490.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210490

Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/

This is a regression caused by JDK-8202537, where for timezones such as 
Etc/GMT-5, display names got formatted according to default locale.

Fix is to specify locale, which was specified in 
timezone.getDisplayName() method.

-- 
Thanks,
Rachna


From naoto.sato at oracle.com  Fri Sep 14 18:06:20 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 14 Sep 2018 11:06:20 -0700
Subject: <i18n dev> [12] RFR:8210490:TimeZone.getDisplayName given
 Locale.US doesn't always honor the Locale
In-Reply-To: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>
References: <a026f160-556f-08d5-544c-d57db168388d@oracle.com>
Message-ID: <98da49f4-541a-3626-504c-41d30eb6848c@oracle.com>

Looks good.

Naoto

On 9/14/18 5:54 AM, Rachna Goel wrote:
> Hi,
> 
> Kindly review fix to JDK-8210490.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210490
> 
> Webrev: http://cr.openjdk.java.net/~rgoel/JDK-8210490/webrev.05/
> 
> This is a regression caused by JDK-8202537, where for timezones such as 
> Etc/GMT-5, display names got formatted according to default locale.
> 
> Fix is to specify locale, which was specified in 
> timezone.getDisplayName() method.
> 

From naoto.sato at oracle.com  Tue Sep 18 17:41:22 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 18 Sep 2018 10:41:22 -0700
Subject: <i18n dev> [12] RFR: 8209880: tzdb.dat is not reproducibly built
Message-ID: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

The fix is to remove the use of HashSet/Map which is not guaranteed to 
preserve the same order on iteration.

Naoto

From erik.joelsson at oracle.com  Tue Sep 18 18:22:32 2018
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 18 Sep 2018 11:22:32 -0700
Subject: <i18n dev> [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
Message-ID: <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>

Looks good to me.

I guess it's hard to prove that the output is now stable, but time will 
tell.

/Erik


On 2018-09-18 10:41, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209880
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
>
> The fix is to remove the use of HashSet/Map which is not guaranteed to 
> preserve the same order on iteration.
>
> Naoto


From akashche at redhat.com  Tue Sep 18 20:35:05 2018
From: akashche at redhat.com (Alex Kashchenko)
Date: Tue, 18 Sep 2018 21:35:05 +0100
Subject: <i18n dev> [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
 <8a64ed37-a1c5-8906-12da-0abb54d14932@oracle.com>
Message-ID: <b133cc4e-bada-ec78-fbb1-55f0ff5a66e5@redhat.com>

Hi,

On 09/18/2018 07:22 PM, Erik Joelsson wrote:
> Looks good to me.
> 
> I guess it's hard to prove that the output is now stable, but time will 
> tell.
> 
> /Erik
> 
> 
> On 2018-09-18 10:41, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8209880
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
>>
>> The fix is to remove the use of HashSet/Map which is not guaranteed to 
>> preserve the same order on iteration.

+1 to this change, I've got bitten by this some years ago - 
http://mail.openjdk.java.net/pipermail/i18n-dev/2015-April/001671.html


-- 
-Alex

From magnus.ihse.bursie at oracle.com  Wed Sep 19 08:01:43 2018
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 19 Sep 2018 10:01:43 +0200
Subject: <i18n dev> [12] RFR: 8209880: tzdb.dat is not reproducibly built
In-Reply-To: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
References: <cd53e5c8-4398-c7ed-2ce2-b04e86889135@oracle.com>
Message-ID: <568016a9-4332-f2fd-4942-fc3a0cda7f91@oracle.com>


On 2018-09-18 19:41, Naoto Sato wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8209880
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8209880/webrev.00/
Looks good. Thank you for fixing this!

/Magnus

>
> The fix is to remove the use of HashSet/Map which is not guaranteed to 
> preserve the same order on iteration.
>
> Naoto


From naoto.sato at oracle.com  Thu Sep 20 21:30:38 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 20 Sep 2018 14:30:38 -0700
Subject: <i18n dev> [12] RFR: 8210633: Cannot parse JapaneseDate string with
 DateTimeFormatterBuilder Mapped-values
Message-ID: <42915822-2f87-268b-2ebc-6cf59236a1d9@oracle.com>

Hello,

Please review the fix to the following issue:

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

The proposed changeset is located at:

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

As the submitter pointed out, the overload method that takes Chronology 
needs to be overridden in the anonymous DateTimeTextProvider class.

Naoto

From dan.z.zhou at oracle.com  Mon Sep 24 12:57:19 2018
From: dan.z.zhou at oracle.com (Dora Zhou)
Date: Mon, 24 Sep 2018 20:57:19 +0800
Subject: <i18n dev> [12]RFR 8210443: Migrate Locale matching tests to JDK
	Repo.
Message-ID: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>

Hello,

Please help review the fix for migrating GS-auto Locale matching tests 
to JDK repository. Please refer to the bug description for details.

Bug: https://bugs.openjdk.java.net/browse/JDK-8210443

Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ 
<http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/>

Regards,
Dora

From naoto.sato at oracle.com  Mon Sep 24 17:34:23 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 24 Sep 2018 10:34:23 -0700
Subject: <i18n dev> [12]RFR 8210443: Migrate Locale matching tests to
 JDK Repo.
In-Reply-To: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
References: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
Message-ID: <da796843-f244-16c0-f890-b21b200e2783@oracle.com>

Looks good to me.

Naoto

On 9/24/18 5:57 AM, Dora Zhou wrote:
> Hello,
> 
> Please help review the fix for migrating GS-auto Locale matching tests 
> to JDK repository. Please refer to the bug description for details.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8210443
> 
> Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ 
> <http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/>
> 
> Regards,
> Dora

From nishit.jain at oracle.com  Mon Sep 24 17:51:39 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 24 Sep 2018 23:21:39 +0530
Subject: <i18n dev> [12]RFR 8210443: Migrate Locale matching tests to
 JDK Repo.
In-Reply-To: <da796843-f244-16c0-f890-b21b200e2783@oracle.com>
References: <ab023408-2b56-c48a-7033-b5810bb7c554@oracle.com>
 <da796843-f244-16c0-f890-b21b200e2783@oracle.com>
Message-ID: <b4204b10-8365-524a-db17-37bc5d4eb2dd@oracle.com>

+1

On 24-09-2018 23:04, Naoto Sato wrote:
> Looks good to me.
>
> Naoto
>
> On 9/24/18 5:57 AM, Dora Zhou wrote:
>> Hello,
>>
>> Please help review the fix for migrating GS-auto Locale matching 
>> tests to JDK repository. Please refer to the bug description for 
>> details.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8210443
>>
>> Webrev: http://cr.openjdk.java.net/~dzhou/8210443/webrev.04/ 
>> <http://cr.openjdk.java.net/%7Edzhou/8210443/webrev.04/>
>>
>> Regards,
>> Dora


From naoto.sato at oracle.com  Wed Sep 26 20:27:06 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 26 Sep 2018 13:27:06 -0700
Subject: <i18n dev> RFR: JDK-8211161: java.lang.ArithmeticException:
 divide by zero from java.text.DecimalFormat.format()
In-Reply-To: <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
 <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
 <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
Message-ID: <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>

Hi, Nasser, Joe,

I agree with Joe as to the assessment on DecimalFormat code. The 
existing code looks correct. Unless there is any obvious need to replace 
the piece with bit operation, I'd just leave it as is. The jira issue 
can be transferred to HotSpot, though.

Naoto

On 9/26/18 11:14 AM, joe darcy wrote:
> Hi Nasser,
> 
> 
> On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
>> Hi Joe,
>>
>> Thank you for your review comments.
>>
>> I agree with you that the specification says that "The floating-point 
>> operations of the Java Virtual Machine do not throw exceptions, trap, 
>> or otherwise signal the IEEE 754 exceptional conditions of invalid 
>> operation, division by zero, overflow, underflow, or inexact." as per 
>> the JVM specification 
>> https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1. 
>>
>>
>> I noticed that the SIGFPE is consumed and no exception is thrown when 
>> SIGFPE is enabled before create JVM. Hence, there is an inconsistency 
>> in the hotspot behavior when the SIGFPE is enabled before and after 
>> create JVM. If the trap is enabled before create JVM, it just catch 
>> the exception and continue where as if the trap is enabled after 
>> create JVM, then it result in the ArithmeticException.Hence, the JVM 
>> behavior needs to be fixed to make the behavior consistent.
>>
>> Still, I feel it makes more sense to check the sign bit to decide a 
>> number is negative or positive rather than divide-by-zro to make 
>> infinity and compare with zero. If you agree with my view, a separate 
>> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we 
>> can change the component of this bug. Please comment.
> 
> Here is my rephrasing of the situation:
> 
> If someone deliberately misconfigures a CPU such that its floating-point 
> behavior does not conform to the JVM specification, Java library code 
> throws unexpected exceptions.
> 
> In that case, it is not a bug in the library code, it is a problem 
> stemming from the deliberate CPU misconfiguration.
> 
> One could make a case that the new code is better in some way, perhaps 
> faster on some platforms, but it is functionally correct as is and 
> should not be described otherwise. The i18n team can weigh in with their 
> assessment of the proposed patch from a maintenance perspective.
> 
> The HotSpot team could evaluate if the VM implementation should be 
> further hardened against hostile changes to the FPU control word(s), but 
> I would be content if this issue were closed as not a bug.
> 
> Cheers,
> 
> -Joe

From enasser at in.ibm.com  Thu Sep 27 05:42:07 2018
From: enasser at in.ibm.com (Nasser Ebrahim)
Date: Thu, 27 Sep 2018 05:42:07 +0000
Subject: <i18n dev> RFR: JDK-8211161: java.lang.ArithmeticException:
 divide by zero from java.text.DecimalFormat.format()
In-Reply-To: <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>
References: <OF420D6F37.3A404BB2-ON00258314.00549BC0-65258314.005AFD9B@notes.na.collabserv.com>
 <1152bfbc-fea9-3f5e-f93f-67da78b9d91c@oracle.com>
 <OF63F2B067.B163DAD8-ON00258314.005F660F-65258314.006171D8@notes.na.collabserv.com>
 <63b3e2dd-403b-0a91-0ddf-9e027e26fb2c@oracle.com>
 <1e2350db-d296-313f-c9ee-e9dc341eb859@oracle.com>
Message-ID: <OF06D5763F.3F238A9A-ON00258315.001E04D6-65258315.001F5267@notes.na.collabserv.com>

Hi Joe, Naoto,

Thank you for your review comments. I agree with you that as per the VM 
specification, divide-by-zero in DecimalFormat is allowed and hence the 
current fix is more of a good to have rather than a defect fix. As Joe 
suggested, I will see whether the new fix give better performance in any 
platforms.

I think the current bug description may not be directly applicable to 
hotspot and a new bug explaining the behavior difference between before 
and after create JVM while handing SIGFPE may be better.

Regards, 
Nasser




From:   naoto.sato at oracle.com
To:     joe darcy <joe.darcy at oracle.com>, Nasser Ebrahim 
<enasser at in.ibm.com>, core-libs-dev Libs <core-libs-dev at openjdk.java.net>, 
"i18n-dev at openjdk.java.net" <i18n-dev at openjdk.java.net>
Date:   09/27/2018 01:55 AM
Subject:        Re: RFR: JDK-8211161: java.lang.ArithmeticException: 
divide by zero from java.text.DecimalFormat.format()



Hi, Nasser, Joe,

I agree with Joe as to the assessment on DecimalFormat code. The 
existing code looks correct. Unless there is any obvious need to replace 
the piece with bit operation, I'd just leave it as is. The jira issue 
can be transferred to HotSpot, though.

Naoto

On 9/26/18 11:14 AM, joe darcy wrote:
> Hi Nasser,
> 
> 
> On 9/26/2018 10:44 AM, Nasser Ebrahim wrote:
>> Hi Joe,
>>
>> Thank you for your review comments.
>>
>> I agree with you that the specification says that "The floating-point 
>> operations of the Java Virtual Machine do not throw exceptions, trap, 
>> or otherwise signal the IEEE 754 exceptional conditions of invalid 
>> operation, division by zero, overflow, underflow, or inexact." as per 
>> the JVM specification 
>> 
https://docs.oracle.com/javase/specs/jvms/se10/html/jvms-2.html#jvms-2.8.1
. 
>>
>>
>> I noticed that the SIGFPE is consumed and no exception is thrown when 
>> SIGFPE is enabled before create JVM. Hence, there is an inconsistency 
>> in the hotspot behavior when the SIGFPE is enabled before and after 
>> create JVM. If the trap is enabled before create JVM, it just catch 
>> the exception and continue where as if the trap is enabled after 
>> create JVM, then it result in the ArithmeticException.Hence, the JVM 
>> behavior needs to be fixed to make the behavior consistent.
>>
>> Still, I feel it makes more sense to check the sign bit to decide a 
>> number is negative or positive rather than divide-by-zro to make 
>> infinity and compare with zero. If you agree with my view, a separate 
>> bug can be opened to fix the JVM inconsistent behavior. Otherwise, we 
>> can change the component of this bug. Please comment.
> 
> Here is my rephrasing of the situation:
> 
> If someone deliberately misconfigures a CPU such that its floating-point 

> behavior does not conform to the JVM specification, Java library code 
> throws unexpected exceptions.
> 
> In that case, it is not a bug in the library code, it is a problem 
> stemming from the deliberate CPU misconfiguration.
> 
> One could make a case that the new code is better in some way, perhaps 
> faster on some platforms, but it is functionally correct as is and 
> should not be described otherwise. The i18n team can weigh in with their 

> assessment of the proposed patch from a maintenance perspective.
> 
> The HotSpot team could evaluate if the VM implementation should be 
> further hardened against hostile changes to the FPU control word(s), but 

> I would be content if this issue were closed as not a bug.
> 
> Cheers,
> 
> -Joe