From nishit.jain at oracle.com  Mon May  2 05:57:33 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 2 May 2016 11:27:33 +0530
Subject: <i18n dev> Review Request for JDK-8154295 : Currency iso code is
 int and hence looses the preceeding zero.
Message-ID: <3c4ca1f7-c8ae-56e7-d4ca-029cc874cf17@oracle.com>

Hello All,

Please review the following fix for JDK-8154295

Bug: https://bugs.openjdk.java.net/browse/JDK-8154295
Webrev: http://cr.openjdk.java.net/~nishjain/8154295/webrev.04/
CCC: http://ccc.us.oracle.com/8154295

Fix: Added a new function "getNumericCodeAsString()" which will always 
return a 3 digit numeric code as a String

Regards,
Nishit Jain

From xueming.shen at oracle.com  Tue May  3 23:29:53 2016
From: xueming.shen at oracle.com (Xueming Shen)
Date: Tue, 03 May 2016 16:29:53 -0700
Subject: <i18n dev> RFR: regex changes
In-Reply-To: <56EC5F76.4080106@oracle.com>
References: <56EC5F76.4080106@oracle.com>
Message-ID: <57293471.8020503@oracle.com>

Hi,

This one has be out for review for a while. If there is no further 
comments and
feedback the changes will be pushed in shortly.

Thanks,
Sherman

On 3/18/16, 1:05 PM, Xueming Shen wrote:
> Hi,
>
> There are couple regex related changes waiting for review. I have pull 
> them
> together here (with the notes) to make it easy to review.
>
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/webrev/
>
> (1) Exponential backtracking
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/backtracking
>
> https://bugs.openjdk.java.net/browse/JDK-6328855
> https://bugs.openjdk.java.net/browse/JDK-6192895
> https://bugs.openjdk.java.net/browse/JDK-6345469
> https://bugs.openjdk.java.net/browse/JDK-6988218
> https://bugs.openjdk.java.net/browse/JDK-6693451
> https://bugs.openjdk.java.net/browse/JDK-7006761
> https://bugs.openjdk.java.net/browse/JDK-8140212
>
> (2) Anonymous class to lambda function cleanup
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/lambdafunction
>
> https://bugs.openjdk.java.net/browse/JDK-8151481
> https://bugs.openjdk.java.net/browse/JDK-6609854
>
> (3) Canonical Equivalents
>
> Note: 
> http://cr.openjdk.java.net/~sherman/regexBackTrack.Lamnda.CanonEQ/canonEQ
>
> https://bugs.openjdk.java.net/browse/JDK-4916384
> https://bugs.openjdk.java.net/browse/JDK-4867170
> https://bugs.openjdk.java.net/browse/JDK-6995635
> https://bugs.openjdk.java.net/browse/JDK-6728861
> https://bugs.openjdk.java.net/browse/JDK-6736245
> https://bugs.openjdk.java.net/browse/JDK-7080302
>
> Thanks
> Sherman


From nishit.jain at oracle.com  Fri May  6 06:19:39 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 6 May 2016 11:49:39 +0530
Subject: <i18n dev> Review Request for JDK-8154295 : Currency iso code
 is int and hence looses the preceeding zero.
In-Reply-To: <3c4ca1f7-c8ae-56e7-d4ca-029cc874cf17@oracle.com>
References: <3c4ca1f7-c8ae-56e7-d4ca-029cc874cf17@oracle.com>
Message-ID: <358f8690-d787-400d-7c20-06799454978f@oracle.com>

Hello All,

Please review the fix for JDK-8154295.

http://cr.openjdk.java.net/~nishjain/8154295/webrev.07/

Changes made to the webrev.04: Added a simple test case and some comments

Regards,
Nishit Jain
On 5/2/2016 11:27 AM, Nishit Jain wrote:
> Hello All,
>
> Please review the following fix for JDK-8154295
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8154295
> Webrev: http://cr.openjdk.java.net/~nishjain/8154295/webrev.04/
> CCC: http://ccc.us.oracle.com/8154295
>
> Fix: Added a new function "getNumericCodeAsString()" which will always 
> return a 3 digit numeric code as a String
>
> Regards,
> Nishit Jain


From masayoshi.okutsu at oracle.com  Fri May  6 06:34:49 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 6 May 2016 15:34:49 +0900
Subject: <i18n dev> Review Request for JDK-8154295 : Currency iso code
 is int and hence looses the preceeding zero.
In-Reply-To: <358f8690-d787-400d-7c20-06799454978f@oracle.com>
References: <3c4ca1f7-c8ae-56e7-d4ca-029cc874cf17@oracle.com>
	<358f8690-d787-400d-7c20-06799454978f@oracle.com>
Message-ID: <7e518db4-2f03-305c-262e-0b048bb61551@oracle.com>

Looks good to me.

Thanks,
Masayoshi

On 5/6/2016 3:19 PM, Nishit Jain wrote:
> Hello All,
>
> Please review the fix for JDK-8154295.
>
> http://cr.openjdk.java.net/~nishjain/8154295/webrev.07/
>
> Changes made to the webrev.04: Added a simple test case and some comments
>
> Regards,
> Nishit Jain
> On 5/2/2016 11:27 AM, Nishit Jain wrote:
>> Hello All,
>>
>> Please review the following fix for JDK-8154295
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154295
>> Webrev: http://cr.openjdk.java.net/~nishjain/8154295/webrev.04/
>> CCC: http://ccc.us.oracle.com/8154295
>>
>> Fix: Added a new function "getNumericCodeAsString()" which will 
>> always return a 3 digit numeric code as a String
>>
>> Regards,
>> Nishit Jain
>


From naoto.sato at oracle.com  Fri May  6 17:44:08 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 6 May 2016 10:44:08 -0700
Subject: <i18n dev> Review Request for JDK-8154295 : Currency iso code
 is int and hence looses the preceeding zero.
In-Reply-To: <358f8690-d787-400d-7c20-06799454978f@oracle.com>
References: <3c4ca1f7-c8ae-56e7-d4ca-029cc874cf17@oracle.com>
	<358f8690-d787-400d-7c20-06799454978f@oracle.com>
Message-ID: <572CD7E8.2040201@oracle.com>

+1

Naoto

On 5/5/16 11:19 PM, Nishit Jain wrote:
> Hello All,
>
> Please review the fix for JDK-8154295.
>
> http://cr.openjdk.java.net/~nishjain/8154295/webrev.07/
>
> Changes made to the webrev.04: Added a simple test case and some comments
>
> Regards,
> Nishit Jain
> On 5/2/2016 11:27 AM, Nishit Jain wrote:
>> Hello All,
>>
>> Please review the following fix for JDK-8154295
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8154295
>> Webrev: http://cr.openjdk.java.net/~nishjain/8154295/webrev.04/
>> CCC: http://ccc.us.oracle.com/8154295
>>
>> Fix: Added a new function "getNumericCodeAsString()" which will always
>> return a 3 digit numeric code as a String
>>
>> Regards,
>> Nishit Jain
>

From nishit.jain at oracle.com  Wed May 18 09:38:58 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 18 May 2016 15:08:58 +0530
Subject: <i18n dev> Review Request for JDK-8149452:
 j.t.SimpleDateFormat.getDateFormatSymbols().getZoneStrings() returns
 incorrect result for some time zones
Message-ID: <81ed9ce7-ff7e-2929-f182-e34df17bc020@oracle.com>

Hello All,

Please review the fix for JDK-8149452

Bug: https://bugs.openjdk.java.net/browse/JDK-8149452
Webrev: http://cr.openjdk.java.net/~nishjain/8149452/webrev.01/

Fix: Made some changes to the CLDRConverter.java to handle the condition 
of missing timezone name in CLDR

Regards,
Nishit Jain

From nishit.jain at oracle.com  Wed May 18 10:12:18 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Wed, 18 May 2016 15:42:18 +0530
Subject: <i18n dev> Review Request for JDK-7102969 and JDK-8157138:
 "currency.properties supercede..." and "Error while fetching currency
 instance..."
Message-ID: <3972607e-6307-673c-41b8-f70cc9ae449b@oracle.com>

Hello All,

Please review the fix for JDK-7102969 and JDK-8157138 (Fixing multiple 
bugs in the same changeset)

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

Webrev: http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.07

Fix:

   For JDK-7102969:
   - Changed the format of currency.data for easier loading into List 
data structure
   - Modified the currency replacement feature to handle some specific 
scenario of special case currencies

   For JDK-8157138:
   - Modified Currency.getInstance(String currencycode) and 
Currency.getAvailableCurrencies() to return the special case currency 
entries

Regards,
Nishit Jain

From nishit.jain at oracle.com  Thu May 19 07:04:49 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 19 May 2016 12:34:49 +0530
Subject: <i18n dev> Review Request for JDK-7102969 and JDK-8157138:
 "currency.properties supercede..." and "Error while fetching currency
 instance..."
In-Reply-To: <3972607e-6307-673c-41b8-f70cc9ae449b@oracle.com>
References: <3972607e-6307-673c-41b8-f70cc9ae449b@oracle.com>
Message-ID: <0f361bd1-d81a-9103-70f6-b02b1c91eb0b@oracle.com>

Hello All,

Please review the updated webrev synced with the latest repository.

http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.08/

Regards,
Nishit Jain
On 5/18/2016 3:42 PM, Nishit Jain wrote:
> Hello All,
>
> Please review the fix for JDK-7102969 and JDK-8157138 (Fixing multiple 
> bugs in the same changeset)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-7102969
>      https://bugs.openjdk.java.net/browse/JDK-8157138
>
> Webrev: 
> http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.07
>
> Fix:
>
>   For JDK-7102969:
>   - Changed the format of currency.data for easier loading into List 
> data structure
>   - Modified the currency replacement feature to handle some specific 
> scenario of special case currencies
>
>   For JDK-8157138:
>   - Modified Currency.getInstance(String currencycode) and 
> Currency.getAvailableCurrencies() to return the special case currency 
> entries
>
> Regards,
> Nishit Jain


From yuka.kamiya at oracle.com  Thu May 19 08:40:01 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 19 May 2016 17:40:01 +0900
Subject: <i18n dev> Review Request for JDK-7102969 and JDK-8157138:
 "currency.properties supercede..." and "Error while fetching currency
 instance..."
In-Reply-To: <0f361bd1-d81a-9103-70f6-b02b1c91eb0b@oracle.com>
References: <3972607e-6307-673c-41b8-f70cc9ae449b@oracle.com>
	<0f361bd1-d81a-9103-70f6-b02b1c91eb0b@oracle.com>
Message-ID: <14cfe14a-7ab1-fb52-a821-481fd782d285@oracle.com>

Hi Nishit,

The fix looks okay to me.

Thanks,
--
Yuka

On 2016/05/19 16:04, Nishit Jain wrote:
> Hello All,
>
> Please review the updated webrev synced with the latest repository.
>
> http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.08/
>
> Regards,
> Nishit Jain
> On 5/18/2016 3:42 PM, Nishit Jain wrote:
>> Hello All,
>>
>> Please review the fix for JDK-7102969 and JDK-8157138 (Fixing 
>> multiple bugs in the same changeset)
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-7102969
>>      https://bugs.openjdk.java.net/browse/JDK-8157138
>>
>> Webrev: 
>> http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.07
>>
>> Fix:
>>
>>   For JDK-7102969:
>>   - Changed the format of currency.data for easier loading into List 
>> data structure
>>   - Modified the currency replacement feature to handle some specific 
>> scenario of special case currencies
>>
>>   For JDK-8157138:
>>   - Modified Currency.getInstance(String currencycode) and 
>> Currency.getAvailableCurrencies() to return the special case currency 
>> entries
>>
>> Regards,
>> Nishit Jain
>


From masayoshi.okutsu at oracle.com  Thu May 19 08:40:23 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 19 May 2016 17:40:23 +0900
Subject: <i18n dev> Review Request for JDK-7102969 and JDK-8157138:
 "currency.properties supercede..." and "Error while fetching currency
 instance..."
In-Reply-To: <14cfe14a-7ab1-fb52-a821-481fd782d285@oracle.com>
References: <3972607e-6307-673c-41b8-f70cc9ae449b@oracle.com>
	<0f361bd1-d81a-9103-70f6-b02b1c91eb0b@oracle.com>
	<14cfe14a-7ab1-fb52-a821-481fd782d285@oracle.com>
Message-ID: <d3efb2de-f081-23f3-4afc-8dece4789dc0@oracle.com>

+1

Masayoshi


On 5/19/2016 5:40 PM, Yuka Kamiya wrote:
> Hi Nishit,
>
> The fix looks okay to me.
>
> Thanks,
> -- 
> Yuka
>
> On 2016/05/19 16:04, Nishit Jain wrote:
>> Hello All,
>>
>> Please review the updated webrev synced with the latest repository.
>>
>> http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.08/
>>
>> Regards,
>> Nishit Jain
>> On 5/18/2016 3:42 PM, Nishit Jain wrote:
>>> Hello All,
>>>
>>> Please review the fix for JDK-7102969 and JDK-8157138 (Fixing 
>>> multiple bugs in the same changeset)
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-7102969
>>>      https://bugs.openjdk.java.net/browse/JDK-8157138
>>>
>>> Webrev: 
>>> http://cr.openjdk.java.net/~nishjain/7102969_and_8157138/webrev.07
>>>
>>> Fix:
>>>
>>>   For JDK-7102969:
>>>   - Changed the format of currency.data for easier loading into List 
>>> data structure
>>>   - Modified the currency replacement feature to handle some 
>>> specific scenario of special case currencies
>>>
>>>   For JDK-8157138:
>>>   - Modified Currency.getInstance(String currencycode) and 
>>> Currency.getAvailableCurrencies() to return the special case 
>>> currency entries
>>>
>>> Regards,
>>> Nishit Jain
>>
>


From masayoshi.okutsu at oracle.com  Thu May 19 08:40:51 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 19 May 2016 17:40:51 +0900
Subject: <i18n dev> Review Request for JDK-8149452:
 j.t.SimpleDateFormat.getDateFormatSymbols().getZoneStrings() returns
 incorrect result for some time zones
In-Reply-To: <81ed9ce7-ff7e-2929-f182-e34df17bc020@oracle.com>
References: <81ed9ce7-ff7e-2929-f182-e34df17bc020@oracle.com>
Message-ID: <4b8a20f0-0fbe-40de-489f-d4c05457da81@oracle.com>

Looks good to me.

Masayoshi


On 5/18/2016 6:38 PM, Nishit Jain wrote:
> Hello All,
>
> Please review the fix for JDK-8149452
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8149452
> Webrev: http://cr.openjdk.java.net/~nishjain/8149452/webrev.01/
>
> Fix: Made some changes to the CLDRConverter.java to handle the 
> condition of missing timezone name in CLDR
>
> Regards,
> Nishit Jain


From masayoshi.okutsu at oracle.com  Mon May 23 06:11:22 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 23 May 2016 15:11:22 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
Message-ID: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>

Hi,

Please review changes for JDK-8031145 that is to open closed i18n tests. 
There are many old tests which should be cleaned up. I did some, but 
there are still many.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8031145

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.00/

Thanks,
Masayoshi


From Alan.Bateman at oracle.com  Mon May 23 08:10:45 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 May 2016 09:10:45 +0100
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
Message-ID: <5742BB05.8070702@oracle.com>

On 23/05/2016 07:11, Masayoshi Okutsu wrote:
> Hi,
>
> Please review changes for JDK-8031145 that is to open closed i18n 
> tests. There are many old tests which should be cleaned up. I did 
> some, but there are still many.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8031145
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.00/
Liberating these tests is great and this looks like good work.

Is there anything that we can do with the binary files? In the case of 
the .ser file then could it be a byte[] in the test with an execution 
mode that re-generates it?  There is also at least one .data file that 
looks to be the serialized version of a bad ChoiceFormat and maybe that 
could be moved into the source too.

-Alan

From masayoshi.okutsu at oracle.com  Mon May 23 09:12:51 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 23 May 2016 18:12:51 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <5742BB05.8070702@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
Message-ID: <0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>

On 5/23/2016 5:10 PM, Alan Bateman wrote:
> Is there anything that we can do with the binary files? In the case of 
> the .ser file then could it be a byte[] in the test with an execution 
> mode that re-generates it?  There is also at least one .data file that 
> looks to be the serialized version of a bad ChoiceFormat and maybe 
> that could be moved into the source too.

I think it's OK for these tests to use ByteArrayInputStream to test 
serialization compatibility. I will convert the binary files to source 
files.

Masayoshi


From Alan.Bateman at oracle.com  Mon May 23 10:02:28 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 23 May 2016 11:02:28 +0100
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
Message-ID: <5742D534.7000802@oracle.com>



On 23/05/2016 10:12, Masayoshi Okutsu wrote:
> On 5/23/2016 5:10 PM, Alan Bateman wrote:
>> Is there anything that we can do with the binary files? In the case 
>> of the .ser file then could it be a byte[] in the test with an 
>> execution mode that re-generates it? There is also at least one .data 
>> file that looks to be the serialized version of a bad ChoiceFormat 
>> and maybe that could be moved into the source too.
>
> I think it's OK for these tests to use ByteArrayInputStream to test 
> serialization compatibility. I will convert the binary files to source 
> files.
Thanks, that would be great and should avoid needing to checking in any 
binary files.

-Alan

From masayoshi.okutsu at oracle.com  Tue May 24 14:49:45 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 24 May 2016 23:49:45 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <5742D534.7000802@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
Message-ID: <e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>

Changed all binary files (serialized objects) into hex dump text files 
(with ".ser.txt" suffix) and added a utility class to read it as an 
InputStream.

Updated webrev:
http://javasoft.jp.oracle.com/~mokutsu/9/8031145/webrev.01/

Thanks,
Masayoshi

On 5/23/2016 7:02 PM, Alan Bateman wrote:
>
>
> On 23/05/2016 10:12, Masayoshi Okutsu wrote:
>> On 5/23/2016 5:10 PM, Alan Bateman wrote:
>>> Is there anything that we can do with the binary files? In the case 
>>> of the .ser file then could it be a byte[] in the test with an 
>>> execution mode that re-generates it? There is also at least one 
>>> .data file that looks to be the serialized version of a bad 
>>> ChoiceFormat and maybe that could be moved into the source too.
>>
>> I think it's OK for these tests to use ByteArrayInputStream to test 
>> serialization compatibility. I will convert the binary files to 
>> source files.
> Thanks, that would be great and should avoid needing to checking in 
> any binary files.
>
> -Alan


From masayoshi.okutsu at oracle.com  Thu May 26 09:41:56 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 26 May 2016 18:41:56 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
Message-ID: <bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>

Naoto pointed out that test/java/text/Format/common/*Format.props should 
have the copyright header. Unfortunately, 
test/java/text/Format/common/PParser.java, which parses the .props 
files, doesn't support any comment lines. So, PParser has been changed 
to be able to support comment lines. 
test/java/text/Format/common/FormatIteratorTest.java, PParser.java, and 
*Format.props have been changed. No other changes.

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02

Thanks,
Masayoshi

p.s. The URL for webrev.01 was wrong. It should be 
http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.01.

On 5/24/2016 11:49 PM, Masayoshi Okutsu wrote:
> Changed all binary files (serialized objects) into hex dump text files 
> (with ".ser.txt" suffix) and added a utility class to read it as an 
> InputStream.
>
> Updated webrev:
> http://javasoft.jp.oracle.com/~mokutsu/9/8031145/webrev.01/
>
> Thanks,
> Masayoshi
>
> On 5/23/2016 7:02 PM, Alan Bateman wrote:
>>
>>
>> On 23/05/2016 10:12, Masayoshi Okutsu wrote:
>>> On 5/23/2016 5:10 PM, Alan Bateman wrote:
>>>> Is there anything that we can do with the binary files? In the case 
>>>> of the .ser file then could it be a byte[] in the test with an 
>>>> execution mode that re-generates it? There is also at least one 
>>>> .data file that looks to be the serialized version of a bad 
>>>> ChoiceFormat and maybe that could be moved into the source too.
>>>
>>> I think it's OK for these tests to use ByteArrayInputStream to test 
>>> serialization compatibility. I will convert the binary files to 
>>> source files.
>> Thanks, that would be great and should avoid needing to checking in 
>> any binary files.
>>
>> -Alan
>


From Alan.Bateman at oracle.com  Thu May 26 10:07:57 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 May 2016 11:07:57 +0100
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
	<bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
Message-ID: <5746CAFD.7060208@oracle.com>

On 26/05/2016 10:41, Masayoshi Okutsu wrote:
> Naoto pointed out that test/java/text/Format/common/*Format.props 
> should have the copyright header. Unfortunately, 
> test/java/text/Format/common/PParser.java, which parses the .props 
> files, doesn't support any comment lines. So, PParser has been changed 
> to be able to support comment lines. 
> test/java/text/Format/common/FormatIteratorTest.java, PParser.java, 
> and *Format.props have been changed. No other changes.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02
Can the formatting/indentation in PParser be cleaned up before this is 
pushed?

-Alan

From masayoshi.okutsu at oracle.com  Thu May 26 10:12:43 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 26 May 2016 19:12:43 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <5746CAFD.7060208@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
	<bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
	<5746CAFD.7060208@oracle.com>
Message-ID: <39de2bf3-cb95-7cbf-a86c-d0e1476937bf@oracle.com>

On 5/26/2016 7:07 PM, Alan Bateman wrote:
> On 26/05/2016 10:41, Masayoshi Okutsu wrote:
>> Naoto pointed out that test/java/text/Format/common/*Format.props 
>> should have the copyright header. Unfortunately, 
>> test/java/text/Format/common/PParser.java, which parses the .props 
>> files, doesn't support any comment lines. So, PParser has been 
>> changed to be able to support comment lines. 
>> test/java/text/Format/common/FormatIteratorTest.java, PParser.java, 
>> and *Format.props have been changed. No other changes.
>>
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02
> Can the formatting/indentation in PParser be cleaned up before this is 
> pushed?

OK. I will.

Masayoshi


From Alan.Bateman at oracle.com  Thu May 26 10:17:32 2016
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 26 May 2016 11:17:32 +0100
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <39de2bf3-cb95-7cbf-a86c-d0e1476937bf@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
	<bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
	<5746CAFD.7060208@oracle.com>
	<39de2bf3-cb95-7cbf-a86c-d0e1476937bf@oracle.com>
Message-ID: <5746CD3C.8070305@oracle.com>



On 26/05/2016 11:12, Masayoshi Okutsu wrote:
> On 5/26/2016 7:07 PM, Alan Bateman wrote:
>> On 26/05/2016 10:41, Masayoshi Okutsu wrote:
>>> Naoto pointed out that test/java/text/Format/common/*Format.props 
>>> should have the copyright header. Unfortunately, 
>>> test/java/text/Format/common/PParser.java, which parses the .props 
>>> files, doesn't support any comment lines. So, PParser has been 
>>> changed to be able to support comment lines. 
>>> test/java/text/Format/common/FormatIteratorTest.java, PParser.java, 
>>> and *Format.props have been changed. No other changes.
>>>
>>> Webrev:
>>> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02
>> Can the formatting/indentation in PParser be cleaned up before this 
>> is pushed?
>
> OK. I will.
Thanks, otherwise I think this looks good and it's nice to get these 
tests moved to the jdk repo.

-Alan

From yuka.kamiya at oracle.com  Thu May 26 10:27:43 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Thu, 26 May 2016 19:27:43 +0900
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
	<bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
Message-ID: <b34c6332-c099-3ee6-7486-eda96033fd0e@oracle.com>

Hi,

The fix looks okay to me.

Thanks,
--
Yuka

On 2016/05/26 18:41, Masayoshi Okutsu wrote:
> Naoto pointed out that test/java/text/Format/common/*Format.props 
> should have the copyright header. Unfortunately, 
> test/java/text/Format/common/PParser.java, which parses the .props 
> files, doesn't support any comment lines. So, PParser has been changed 
> to be able to support comment lines. 
> test/java/text/Format/common/FormatIteratorTest.java, PParser.java, 
> and *Format.props have been changed. No other changes.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02
>
> Thanks,
> Masayoshi
>
> p.s. The URL for webrev.01 was wrong. It should be 
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.01.
>
> On 5/24/2016 11:49 PM, Masayoshi Okutsu wrote:
>> Changed all binary files (serialized objects) into hex dump text 
>> files (with ".ser.txt" suffix) and added a utility class to read it 
>> as an InputStream.
>>
>> Updated webrev:
>> http://javasoft.jp.oracle.com/~mokutsu/9/8031145/webrev.01/
>>
>> Thanks,
>> Masayoshi
>>
>> On 5/23/2016 7:02 PM, Alan Bateman wrote:
>>>
>>>
>>> On 23/05/2016 10:12, Masayoshi Okutsu wrote:
>>>> On 5/23/2016 5:10 PM, Alan Bateman wrote:
>>>>> Is there anything that we can do with the binary files? In the 
>>>>> case of the .ser file then could it be a byte[] in the test with 
>>>>> an execution mode that re-generates it? There is also at least one 
>>>>> .data file that looks to be the serialized version of a bad 
>>>>> ChoiceFormat and maybe that could be moved into the source too.
>>>>
>>>> I think it's OK for these tests to use ByteArrayInputStream to test 
>>>> serialization compatibility. I will convert the binary files to 
>>>> source files.
>>> Thanks, that would be great and should avoid needing to checking in 
>>> any binary files.
>>>
>>> -Alan
>>
>


From rachna.goel at oracle.com  Thu May 26 11:30:15 2016
From: rachna.goel at oracle.com (Rachna Goel)
Date: Thu, 26 May 2016 17:00:15 +0530
Subject: <i18n dev> Review Request for JDK-8145136:Upgrade CLDR locale data
Message-ID: <d776b567-bac7-2334-9025-596961e6f716@oracle.com>

Hi all,

Please review fix for JDK-8145136.

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

webrev: 
http://cr.openjdk.java.net/~nishjain/rachna/CLDR29/8145136/webrev.00/

Fix: Currently JDK supports CLDR V27 which is upgraded to latest version 29.

For more info:  http://cldr.unicode.org/

-- 
Thanks,
Rachna


From ramanand.patil at oracle.com  Thu May 26 13:22:54 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Thu, 26 May 2016 06:22:54 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
Message-ID: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>

HI all,

Please review the latest TZDATA integration (tzdata2016d) to JDK9.

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

Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/

Patch Contains:

1.       IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated].

2.       "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d.

[This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".]

3.       Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names.

4.       Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch.

 

Regards,

Ramanand.

 

From naoto.sato at oracle.com  Thu May 26 15:07:26 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 26 May 2016 08:07:26 -0700
Subject: <i18n dev> RFR: 8031145: Re-examine closed i18n tests to see it
 they can be moved to the jdk repository.
In-Reply-To: <bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
References: <e31d63cf-9b62-0bda-0734-e8d3c8195e59@oracle.com>
	<5742BB05.8070702@oracle.com>
	<0a05223a-3fa4-3b6e-4e8b-f75a61be894a@oracle.com>
	<5742D534.7000802@oracle.com>
	<e2930f6c-a300-e8a7-e604-1aea82d20710@oracle.com>
	<bbdbe571-2742-5827-8d97-2adc07ab2023@oracle.com>
Message-ID: <288bac39-c615-b5b1-2d69-b60eaa72a44e@oracle.com>

+1

Naoto

On 5/26/16 2:41 AM, Masayoshi Okutsu wrote:
> Naoto pointed out that test/java/text/Format/common/*Format.props should
> have the copyright header. Unfortunately,
> test/java/text/Format/common/PParser.java, which parses the .props
> files, doesn't support any comment lines. So, PParser has been changed
> to be able to support comment lines.
> test/java/text/Format/common/FormatIteratorTest.java, PParser.java, and
> *Format.props have been changed. No other changes.
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.02
>
> Thanks,
> Masayoshi
>
> p.s. The URL for webrev.01 was wrong. It should be
> http://cr.openjdk.java.net/~okutsu/9/8031145/webrev.01.
>
> On 5/24/2016 11:49 PM, Masayoshi Okutsu wrote:
>> Changed all binary files (serialized objects) into hex dump text files
>> (with ".ser.txt" suffix) and added a utility class to read it as an
>> InputStream.
>>
>> Updated webrev:
>> http://javasoft.jp.oracle.com/~mokutsu/9/8031145/webrev.01/
>>
>> Thanks,
>> Masayoshi
>>
>> On 5/23/2016 7:02 PM, Alan Bateman wrote:
>>>
>>>
>>> On 23/05/2016 10:12, Masayoshi Okutsu wrote:
>>>> On 5/23/2016 5:10 PM, Alan Bateman wrote:
>>>>> Is there anything that we can do with the binary files? In the case
>>>>> of the .ser file then could it be a byte[] in the test with an
>>>>> execution mode that re-generates it? There is also at least one
>>>>> .data file that looks to be the serialized version of a bad
>>>>> ChoiceFormat and maybe that could be moved into the source too.
>>>>
>>>> I think it's OK for these tests to use ByteArrayInputStream to test
>>>> serialization compatibility. I will convert the binary files to
>>>> source files.
>>> Thanks, that would be great and should avoid needing to checking in
>>> any binary files.
>>>
>>> -Alan
>>
>

From sean.coffey at oracle.com  Fri May 27 13:19:11 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 27 May 2016 14:19:11 +0100
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
Message-ID: <5748494F.6060404@oracle.com>

Looks fine to me Ramanand. the recent 2016d changes have introduced some 
boundary issues for JDK rule parsing and those issues can be followed up 
in separate issues like you say.

Regards,
Sean.

On 26/05/16 14:22, Ramanand Patil wrote:
> HI all,
>
> Please review the latest TZDATA integration (tzdata2016d) to JDK9.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>
> Patch Contains:
>
> 1.       IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated].
>
> 2.       "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d.
>
> [This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".]
>
> 3.       Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names.
>
> 4.       Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch.
>
>   
>
> Regards,
>
> Ramanand.
>
>   


From masayoshi.okutsu at oracle.com  Fri May 27 14:24:49 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 27 May 2016 23:24:49 +0900
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <5748494F.6060404@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
Message-ID: <12123364-e177-a744-7f24-68e4a8f87532@oracle.com>

This change seems to beyond my proposal that the "GMT?hh:mm" format is 
used for *new* zones with the "?hh" format. But this change removes 
*existing* zones which have changed to use the "?hh" format in tzdata. 
Can this cause any compatibility issues?

And have we agreed to use the "GMT?hh:mm" format?

Thanks,
Masayoshi


On 5/27/2016 10:19 PM, Se?n Coffey wrote:
> Looks fine to me Ramanand. the recent 2016d changes have introduced 
> some boundary issues for JDK rule parsing and those issues can be 
> followed up in separate issues like you say.
>
> Regards,
> Sean.
>
> On 26/05/16 14:22, Ramanand Patil wrote:
>> HI all,
>>
>> Please review the latest TZDATA integration (tzdata2016d) to JDK9.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>
>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>
>> Patch Contains:
>>
>> 1.       IANA tzdata2016d integration into JDK. [It also includes 
>> tzdata2016b and tzdata2016c which was not integrated].
>>
>> 2.       "GMT[+ -]hh:mm" is used for formatting of the modified or 
>> newly added TimeZones in tzdata2016d.
>>
>> [This is done to accommodate the IANA's new system where the zones 
>> use numeric time zone abbreviations like "+04" instead of invented 
>> abbreviations like "ASTT".]
>>
>> 3.       Test case: 
>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
>> updated to include the failures because of GMT[+ -]hh:mm format names.
>>
>> 4.       Few other failing tests: For few other failing tests, new 
>> linked bugs are created and will be addressed in a separate patch.
>>
>>
>> Regards,
>>
>> Ramanand.
>>
>


From sean.coffey at oracle.com  Fri May 27 15:04:48 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Fri, 27 May 2016 16:04:48 +0100
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
Message-ID: <57486210.7090205@oracle.com>

I guess there's a low risk of timezone not being identified if being 
parsed in through a formatter. Isn't such an approach discouraged though 
? short IDs were already subject to change in tzdata releases. Ramanand 
found one issue by removal of these resource strings (so far) and that's 
captured in JDK-8157814

There's a decision to be made about how to use the GMT?hh:mm format for 
new releases given IANA's new short ID identifier mechanism. I think 
that could be discussed as a separate issue. I'd like to see us follow a 
similar approach to IANA and use GMT identifiers on new timezones and 
perhaps even consider using the IANA long name format also for the 
getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of 
"Alma-Ata Time"

Regards,
Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:
> This change seems to beyond my proposal that the "GMT?hh:mm" format is 
> used for *new* zones with the "?hh" format. But this change removes 
> *existing* zones which have changed to use the "?hh" format in tzdata. 
> Can this cause any compatibility issues?
>
> And have we agreed to use the "GMT?hh:mm" format?
>
> Thanks,
> Masayoshi
>
>
> On 5/27/2016 10:19 PM, Se?n Coffey wrote:
>> Looks fine to me Ramanand. the recent 2016d changes have introduced 
>> some boundary issues for JDK rule parsing and those issues can be 
>> followed up in separate issues like you say.
>>
>> Regards,
>> Sean.
>>
>> On 26/05/16 14:22, Ramanand Patil wrote:
>>> HI all,
>>>
>>> Please review the latest TZDATA integration (tzdata2016d) to JDK9.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>>
>>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>>
>>> Patch Contains:
>>>
>>> 1.       IANA tzdata2016d integration into JDK. [It also includes 
>>> tzdata2016b and tzdata2016c which was not integrated].
>>>
>>> 2.       "GMT[+ -]hh:mm" is used for formatting of the modified or 
>>> newly added TimeZones in tzdata2016d.
>>>
>>> [This is done to accommodate the IANA's new system where the zones 
>>> use numeric time zone abbreviations like "+04" instead of invented 
>>> abbreviations like "ASTT".]
>>>
>>> 3.       Test case: 
>>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
>>> updated to include the failures because of GMT[+ -]hh:mm format names.
>>>
>>> 4.       Few other failing tests: For few other failing tests, new 
>>> linked bugs are created and will be addressed in a separate patch.
>>>
>>>
>>> Regards,
>>>
>>> Ramanand.
>>>
>>
>


From naoto.sato at oracle.com  Fri May 27 18:25:11 2016
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 27 May 2016 11:25:11 -0700
Subject: <i18n dev> Review Request for JDK-8145136:Upgrade CLDR locale
 data
In-Reply-To: <d776b567-bac7-2334-9025-596961e6f716@oracle.com>
References: <d776b567-bac7-2334-9025-596961e6f716@oracle.com>
Message-ID: <d4be7d97-7b50-2d80-c8ef-f41ef571fdf6@oracle.com>

Hi Rachna,

Here are my comments to the webrev (I am assuming the tool that extracts 
JavaTime*.java are working correctly, i.e., have not reviewed the data 
itself):

- (All JavaTime*.java files): Unicode copyright notice is outdated. It 
should include the one that has "1991-2016" as the copyright year. So as 
the file "unicode-license.txt"

- JavaTimeSupplementary_iw.java has the copyright year of "2016,". It 
should be "2013, 2016,".

Others look OK.

Naoto

On 5/26/16 4:30 AM, Rachna Goel wrote:
> Hi all,
>
> Please review fix for JDK-8145136.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8145136
>
> webrev:
> http://cr.openjdk.java.net/~nishjain/rachna/CLDR29/8145136/webrev.00/
>
> Fix: Currently JDK supports CLDR V27 which is upgraded to latest version
> 29.
>
> For more info:  http://cldr.unicode.org/
>

From masayoshi.okutsu at oracle.com  Sat May 28 05:27:39 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Sat, 28 May 2016 14:27:39 +0900
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <57486210.7090205@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
Message-ID: <c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>

CLDR locale data defines time zone names, like this (in en.xml):

                        <metazone type="Almaty">
                                 <long>
                                         <generic>Almaty Time</generic>
                                         <standard>Almaty Standard Time</standard>
                                         <daylight>Almaty Summer Time</daylight>
                                 </long>
                         </metazone>

The CLDR converter tool tries to fill in the missing short names from 
the legacy TimeZoneNames data. Removing existing names causes some 
unexpected behavior. I think JDK-8157814 is an example of the unexpected 
behavior. And the suggested fix in JDK-8157814 looks to me like a 
workaround.

I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Se?n Coffey wrote:
> I guess there's a low risk of timezone not being identified if being 
> parsed in through a formatter. Isn't such an approach discouraged 
> though ? short IDs were already subject to change in tzdata releases. 
> Ramanand found one issue by removal of these resource strings (so far) 
> and that's captured in JDK-8157814
>
> There's a decision to be made about how to use the GMT?hh:mm format 
> for new releases given IANA's new short ID identifier mechanism. I 
> think that could be discussed as a separate issue. I'd like to see us 
> follow a similar approach to IANA and use GMT identifiers on new 
> timezones and perhaps even consider using the IANA long name format 
> also for the getDisplayName(..) calls that can be made. e.g. 
> "Asia/Almaty" instead of "Alma-Ata Time"
> Regards,
> Sean.
> On 27/05/16 15:24, Masayoshi Okutsu wrote:
>> This change seems to beyond my proposal that the "GMT?hh:mm" format 
>> is used for *new* zones with the "?hh" format. But this change 
>> removes *existing* zones which have changed to use the "?hh" format 
>> in tzdata. Can this cause any compatibility issues?
>>
>> And have we agreed to use the "GMT?hh:mm" format?
>>
>> Thanks,
>> Masayoshi
>>
>>
>> On 5/27/2016 10:19 PM, Se?n Coffey wrote:
>>> Looks fine to me Ramanand. the recent 2016d changes have introduced 
>>> some boundary issues for JDK rule parsing and those issues can be 
>>> followed up in separate issues like you say.
>>>
>>> Regards,
>>> Sean.
>>>
>>> On 26/05/16 14:22, Ramanand Patil wrote:
>>>> HI all,
>>>>
>>>> Please review the latest TZDATA integration (tzdata2016d) to JDK9.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>>>
>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>>>
>>>> Patch Contains:
>>>>
>>>> 1.       IANA tzdata2016d integration into JDK. [It also includes 
>>>> tzdata2016b and tzdata2016c which was not integrated].
>>>>
>>>> 2.       "GMT[+ -]hh:mm" is used for formatting of the modified or 
>>>> newly added TimeZones in tzdata2016d.
>>>>
>>>> [This is done to accommodate the IANA's new system where the zones 
>>>> use numeric time zone abbreviations like "+04" instead of invented 
>>>> abbreviations like "ASTT".]
>>>>
>>>> 3.       Test case: 
>>>> java/time/test/java/time/format/TestZoneTextPrinterParser.java is 
>>>> updated to include the failures because of GMT[+ -]hh:mm format names.
>>>>
>>>> 4.       Few other failing tests: For few other failing tests, new 
>>>> linked bugs are created and will be addressed in a separate patch.
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Ramanand.
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Sun May 29 23:15:50 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 30 May 2016 08:15:50 +0900
Subject: <i18n dev> Review Request for JDK-8145136:Upgrade CLDR locale
 data
In-Reply-To: <d4be7d97-7b50-2d80-c8ef-f41ef571fdf6@oracle.com>
References: <d776b567-bac7-2334-9025-596961e6f716@oracle.com>
	<d4be7d97-7b50-2d80-c8ef-f41ef571fdf6@oracle.com>
Message-ID: <816aadd1-2442-1dfd-1f93-bc2bf18e4e5c@oracle.com>

Other than the copyright year things, all looks good to me. I don't 
think further review is required for copyright update.

Masayoshi

On 5/28/2016 3:25 AM, Naoto Sato wrote:
> Hi Rachna,
>
> Here are my comments to the webrev (I am assuming the tool that 
> extracts JavaTime*.java are working correctly, i.e., have not reviewed 
> the data itself):
>
> - (All JavaTime*.java files): Unicode copyright notice is outdated. It 
> should include the one that has "1991-2016" as the copyright year. So 
> as the file "unicode-license.txt"
>
> - JavaTimeSupplementary_iw.java has the copyright year of "2016,". It 
> should be "2013, 2016,".
>
> Others look OK.
>
> Naoto
>
> On 5/26/16 4:30 AM, Rachna Goel wrote:
>> Hi all,
>>
>> Please review fix for JDK-8145136.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145136
>>
>> webrev:
>> http://cr.openjdk.java.net/~nishjain/rachna/CLDR29/8145136/webrev.00/
>>
>> Fix: Currently JDK supports CLDR V27 which is upgraded to latest version
>> 29.
>>
>> For more info:  http://cldr.unicode.org/
>>


From masayoshi.okutsu at oracle.com  Mon May 30 05:05:46 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 30 May 2016 14:05:46 +0900
Subject: <i18n dev> RFR: 8039565: Remove test exclusion for
 java/util/ResourceBundle/RestrictedBundleTest.java
Message-ID: <909f81f7-3a25-5174-e50b-7f1e1bb183d4@oracle.com>

Hi,

Please review the fix for JDK-8039565. I don't think it's worth keeping 
this old test and decided to remove it.

Issue:
https://bugs.openjdk.java.net/browse/JDK-8039565

Webrev:
http://cr.openjdk.java.net/~okutsu/9/8039565/webrev.00

Thanks,
Masayoshi


From yuka.kamiya at oracle.com  Mon May 30 05:34:17 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Mon, 30 May 2016 14:34:17 +0900
Subject: <i18n dev> RFR: 8039565: Remove test exclusion for
 java/util/ResourceBundle/RestrictedBundleTest.java
In-Reply-To: <909f81f7-3a25-5174-e50b-7f1e1bb183d4@oracle.com>
References: <909f81f7-3a25-5174-e50b-7f1e1bb183d4@oracle.com>
Message-ID: <128919ca-1655-376a-b6f0-8e5546ee84a6@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka


On 2016/05/30 14:05, Masayoshi Okutsu wrote:
> Hi,
>
> Please review the fix for JDK-8039565. I don't think it's worth 
> keeping this old test and decided to remove it.
>
> Issue:
> https://bugs.openjdk.java.net/browse/JDK-8039565
>
> Webrev:
> http://cr.openjdk.java.net/~okutsu/9/8039565/webrev.00
>
> Thanks,
> Masayoshi
>


From nishit.jain at oracle.com  Mon May 30 06:00:56 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Mon, 30 May 2016 11:30:56 +0530
Subject: <i18n dev> Review Request for JDK-8158025: Typo in java.util.Locale
Message-ID: <e2f0b5c9-00b2-f738-eb2f-5aa9400c2c5c@oracle.com>

Hi,

Please review the fix for JDK-8158025.

Webrev : http://cr.openjdk.java.net/~nishjain/8158025/webrev.00/
Bug: https://bugs.openjdk.java.net/browse/JDK-8158025

Fix: corrected a small typo in Locale.java.


Regards,
Nishit Jain

From masayoshi.okutsu at oracle.com  Mon May 30 06:04:26 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 30 May 2016 15:04:26 +0900
Subject: <i18n dev> Review Request for JDK-8158025: Typo in
 java.util.Locale
In-Reply-To: <e2f0b5c9-00b2-f738-eb2f-5aa9400c2c5c@oracle.com>
References: <e2f0b5c9-00b2-f738-eb2f-5aa9400c2c5c@oracle.com>
Message-ID: <a8f6b673-bf8d-fbb5-1b52-698db5264433@oracle.com>

Looks good to me.

Masayoshi


On 5/30/2016 3:00 PM, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8158025.
>
> Webrev : http://cr.openjdk.java.net/~nishjain/8158025/webrev.00/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8158025
>
> Fix: corrected a small typo in Locale.java.
>
>
> Regards,
> Nishit Jain


From yuka.kamiya at oracle.com  Mon May 30 06:14:49 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Mon, 30 May 2016 15:14:49 +0900
Subject: <i18n dev> Review Request for JDK-8158025: Typo in
 java.util.Locale
In-Reply-To: <a8f6b673-bf8d-fbb5-1b52-698db5264433@oracle.com>
References: <e2f0b5c9-00b2-f738-eb2f-5aa9400c2c5c@oracle.com>
	<a8f6b673-bf8d-fbb5-1b52-698db5264433@oracle.com>
Message-ID: <699683a4-46f9-5a8d-21ba-2856c6d0e6fc@oracle.com>

+1

On 2016/05/30 15:04, Masayoshi Okutsu wrote:
> Looks good to me.
>
> Masayoshi
>
>
> On 5/30/2016 3:00 PM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8158025.
>>
>> Webrev : http://cr.openjdk.java.net/~nishjain/8158025/webrev.00/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8158025
>>
>> Fix: corrected a small typo in Locale.java.
>>
>>
>> Regards,
>> Nishit Jain
>


From yuka.kamiya at oracle.com  Mon May 30 06:40:49 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Mon, 30 May 2016 15:40:49 +0900
Subject: <i18n dev> Review Request for JDK-8145136:Upgrade CLDR locale
 data
In-Reply-To: <816aadd1-2442-1dfd-1f93-bc2bf18e4e5c@oracle.com>
References: <d776b567-bac7-2334-9025-596961e6f716@oracle.com>
	<d4be7d97-7b50-2d80-c8ef-f41ef571fdf6@oracle.com>
	<816aadd1-2442-1dfd-1f93-bc2bf18e4e5c@oracle.com>
Message-ID: <b9e93b16-089e-bb7f-de84-cfadf4fd802c@oracle.com>

+1

On 2016/05/30 8:15, Masayoshi Okutsu wrote:
> Other than the copyright year things, all looks good to me. I don't 
> think further review is required for copyright update.
>
> Masayoshi
>
> On 5/28/2016 3:25 AM, Naoto Sato wrote:
>> Hi Rachna,
>>
>> Here are my comments to the webrev (I am assuming the tool that 
>> extracts JavaTime*.java are working correctly, i.e., have not 
>> reviewed the data itself):
>>
>> - (All JavaTime*.java files): Unicode copyright notice is outdated. 
>> It should include the one that has "1991-2016" as the copyright year. 
>> So as the file "unicode-license.txt"
>>
>> - JavaTimeSupplementary_iw.java has the copyright year of "2016,". It 
>> should be "2013, 2016,".
>>
>> Others look OK.
>>
>> Naoto
>>
>> On 5/26/16 4:30 AM, Rachna Goel wrote:
>>> Hi all,
>>>
>>> Please review fix for JDK-8145136.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8145136
>>>
>>> webrev:
>>> http://cr.openjdk.java.net/~nishjain/rachna/CLDR29/8145136/webrev.00/
>>>
>>> Fix: Currently JDK supports CLDR V27 which is upgraded to latest 
>>> version
>>> 29.
>>>
>>> For more info:  http://cldr.unicode.org/
>>>
>


From ramanand.patil at oracle.com  Mon May 30 18:03:14 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Mon, 30 May 2016 11:03:14 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
Message-ID: <783f0b2f-43fb-40ed-9204-889b9a3c2570@default>

Hi Masayoshi and All,

?

Here is the updated Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/

?

As suggested by Masayoshi, I have kept the existing names unchanged.


Also, this patch contains extra test case fixes for


1.?????? ?java/util/TimeZone/CheckDisplayNames.java 


2.?????? java/util/TimeZone/Bug8149452.java


The exclusion for the newly added TimeZones is added in these test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT?hh:mm format.

?

?

Regards,

Ramanand.

?

From: Masayoshi Okutsu 
Sent: Saturday, May 28, 2016 10:58 AM
To: Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016d

?

CLDR locale data defines time zone names, like this (in en.xml):

?????????????????????? <metazone type="Almaty">
??????????????????????????????? <long>
??????????????????????????????????????? <generic>Almaty Time</generic>
???????????????????????????????? ???????<standard>Almaty Standard Time</standard>
??????????????????????????????????????? <daylight>Almaty Summer Time</daylight>
??????????????????????????????? </long>
??????????????????????? </metazone>
?

The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround.

I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Se?n Coffey wrote:

I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814

There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" 

Regards,
Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:

This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? 

And have we agreed to use the "GMT?hh:mm" format? 

Thanks, 
Masayoshi 


On 5/27/2016 10:19 PM, Se?n Coffey wrote: 



Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. 

Regards, 
Sean. 

On 26/05/16 14:22, Ramanand Patil wrote: 



HI all, 

Please review the latest TZDATA integration (tzdata2016d) to JDK9. 

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ 

Patch Contains: 

1.?????? IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 

2.?????? "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. 

[This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 

3.?????? Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 

4.?????? Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. 


Regards, 

Ramanand. 

?

?

?

?

From nishit.jain at oracle.com  Tue May 31 06:00:26 2016
From: nishit.jain at oracle.com (Nishit Jain)
Date: Tue, 31 May 2016 11:30:26 +0530
Subject: <i18n dev> Review Request for JDK-8072099: Format "ha" is unable to
 parse hours 10-12
Message-ID: <b579d4eb-dd9a-e634-c9ec-f9eba560d0a7@oracle.com>

Hi,

Please review the fix for JDK-8072099.

Webrev: http://cr.openjdk.java.net/~nishjain/8072099/webrev.03/
Bug: https://bugs.openjdk.java.net/browse/JDK-8072099

Fix:  Changes are made to consider the number of pattern letters only 
for the first field of [NumericField][NumericField] pattern.

Regards,
Nishit Jain

From masayoshi.okutsu at oracle.com  Tue May 31 06:06:40 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 31 May 2016 15:06:40 +0900
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
	<783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
Message-ID: <d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>

The CheckDisplayNames.java change is different from what I suggested and 
doesn't make sense. But we no longer need the test. I'd suggest 
CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me.

Masayoshi


On 5/31/2016 3:03 AM, Ramanand Patil wrote:
>
> Hi Masayoshi and All,
>
> Here is the updated Webrev: 
> http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ 
> <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/>
>
> As suggested by Masayoshi, I have kept the existing names unchanged.
>
>
>     Also, this patch contains extra test case fixes for
>
>
>     1./java/util/TimeZone/CheckDisplayNames.java/
>
>
>     2.java/util/TimeZone/Bug8149452.java
>
> The exclusion for the *newly* added TimeZones is added in these test 
> cases where the entries are not present in the resources and the 
> Short/Long display names fallback to the GMT?hh:mm format.
>
> Regards,
>
> Ramanand.
>
> *From:*Masayoshi Okutsu
> *Sent:* Saturday, May 28, 2016 10:58 AM
> *To:* Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; 
> core-libs-dev at openjdk.java.net
> *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d
>
> CLDR locale data defines time zone names, like this (in en.xml):
>
>                         <metazone type="Almaty">
>                                  <long>
>                                          <generic>Almaty Time</generic>
>                                          <standard>Almaty Standard Time</standard>
>                                          <daylight>Almaty Summer Time</daylight>
>                                  </long>
>                          </metazone>
>
> The CLDR converter tool tries to fill in the missing short names from 
> the legacy TimeZoneNames data. Removing existing names causes some 
> unexpected behavior. I think JDK-8157814 is an example of the 
> unexpected behavior. And the suggested fix in JDK-8157814 looks to me 
> like a workaround.
>
> I still think the existing names should be kept unchanged for this fix.
>
> Thanks,
> Masayoshi
>
> On 5/28/2016 12:04 AM, Se?n Coffey wrote:
>
>     I guess there's a low risk of timezone not being identified if
>     being parsed in through a formatter. Isn't such an approach
>     discouraged though ? short IDs were already subject to change in
>     tzdata releases. Ramanand found one issue by removal of these
>     resource strings (so far) and that's captured in JDK-8157814
>
>     There's a decision to be made about how to use the GMT?hh:mm
>     format for new releases given IANA's new short ID identifier
>     mechanism. I think that could be discussed as a separate issue.
>     I'd like to see us follow a similar approach to IANA and use GMT
>     identifiers on new timezones and perhaps even consider using the
>     IANA long name format also for the getDisplayName(..) calls that
>     can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time"
>
>     Regards,
>
>     Sean.
>
>     On 27/05/16 15:24, Masayoshi Okutsu wrote:
>
>         This change seems to beyond my proposal that the "GMT?hh:mm"
>         format is used for *new* zones with the "?hh" format. But this
>         change removes *existing* zones which have changed to use the
>         "?hh" format in tzdata. Can this cause any compatibility issues?
>
>         And have we agreed to use the "GMT?hh:mm" format?
>
>         Thanks,
>         Masayoshi
>
>
>         On 5/27/2016 10:19 PM, Se?n Coffey wrote:
>
>         Looks fine to me Ramanand. the recent 2016d changes have
>         introduced some boundary issues for JDK rule parsing and those
>         issues can be followed up in separate issues like you say.
>
>         Regards,
>         Sean.
>
>         On 26/05/16 14:22, Ramanand Patil wrote:
>
>         HI all,
>
>         Please review the latest TZDATA integration (tzdata2016d) to
>         JDK9.
>
>         Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>
>         Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>         <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/>
>
>         Patch Contains:
>
>         1.       IANA tzdata2016d integration into JDK. [It also
>         includes tzdata2016b and tzdata2016c which was not integrated].
>
>         2.       "GMT[+ -]hh:mm" is used for formatting of the
>         modified or newly added TimeZones in tzdata2016d.
>
>         [This is done to accommodate the IANA's new system where the
>         zones use numeric time zone abbreviations like "+04" instead
>         of invented abbreviations like "ASTT".]
>
>         3.       Test case:
>         java/time/test/java/time/format/TestZoneTextPrinterParser.java
>         is updated to include the failures because of GMT[+ -]hh:mm
>         format names.
>
>         4.       Few other failing tests: For few other failing tests,
>         new linked bugs are created and will be addressed in a
>         separate patch.
>
>
>         Regards,
>
>         Ramanand.
>


From yuka.kamiya at oracle.com  Tue May 31 07:14:55 2016
From: yuka.kamiya at oracle.com (Yuka Kamiya)
Date: Tue, 31 May 2016 16:14:55 +0900
Subject: <i18n dev> Review Request for JDK-8072099: Format "ha" is
 unable to parse hours 10-12
In-Reply-To: <b579d4eb-dd9a-e634-c9ec-f9eba560d0a7@oracle.com>
References: <b579d4eb-dd9a-e634-c9ec-f9eba560d0a7@oracle.com>
Message-ID: <c6f37e62-68b3-e4bc-1463-e27a127171db@oracle.com>

Hi,

The fix looks good to me.

Thanks,
--
Yuka


On 2016/05/31 15:00, Nishit Jain wrote:
> Hi,
>
> Please review the fix for JDK-8072099.
>
> Webrev: http://cr.openjdk.java.net/~nishjain/8072099/webrev.03/
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072099
>
> Fix:  Changes are made to consider the number of pattern letters only 
> for the first field of [NumericField][NumericField] pattern.
>
> Regards,
> Nishit Jain


From masayoshi.okutsu at oracle.com  Tue May 31 07:31:32 2016
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 31 May 2016 16:31:32 +0900
Subject: <i18n dev> Review Request for JDK-8072099: Format "ha" is
 unable to parse hours 10-12
In-Reply-To: <c6f37e62-68b3-e4bc-1463-e27a127171db@oracle.com>
References: <b579d4eb-dd9a-e634-c9ec-f9eba560d0a7@oracle.com>
	<c6f37e62-68b3-e4bc-1463-e27a127171db@oracle.com>
Message-ID: <54ce1af3-bc5a-d078-5537-4852d1a8fce0@oracle.com>

+1


On 5/31/2016 4:14 PM, Yuka Kamiya wrote:
> Hi,
>
> The fix looks good to me.
>
> Thanks,
> -- 
> Yuka
>
>
> On 2016/05/31 15:00, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8072099.
>>
>> Webrev: http://cr.openjdk.java.net/~nishjain/8072099/webrev.03/
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072099
>>
>> Fix:  Changes are made to consider the number of pattern letters only 
>> for the first field of [NumericField][NumericField] pattern.
>>
>> Regards,
>> Nishit Jain
>


From ramanand.patil at oracle.com  Tue May 31 09:29:18 2016
From: ramanand.patil at oracle.com (Ramanand Patil)
Date: Tue, 31 May 2016 02:29:18 -0700 (PDT)
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
	<783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
	<d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
Message-ID: <0c729de0-1b64-4e4f-b655-e477a4c66e81@default>

Hi Masayoshi,

?

Thank you, I will delete this test before pushing the patch.

?

?

Regards,

Ramanand.

?

From: Masayoshi Okutsu 
Sent: Tuesday, May 31, 2016 11:37 AM
To: Ramanand Patil; Se?n Coffey; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016d

?

The CheckDisplayNames.java change is different from what I suggested and doesn't make sense. But we no longer need the test. I'd suggest CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me.

Masayoshi

?

On 5/31/2016 3:03 AM, Ramanand Patil wrote:

Hi Masayoshi and All,

?

Here is the updated Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/

?

As suggested by Masayoshi, I have kept the existing names unchanged.


Also, this patch contains extra test case fixes for


1.?? ?java/util/TimeZone/CheckDisplayNames.java 


2.?? java/util/TimeZone/Bug8149452.java


The exclusion for the newly added TimeZones is added in these test cases where the entries are not present in the resources and the Short/Long display names fallback to the GMT?hh:mm format.

?

?

Regards,

Ramanand.

?

From: Masayoshi Okutsu 
Sent: Saturday, May 28, 2016 10:58 AM
To: Se?n Coffey; Ramanand Patil; HYPERLINK "mailto:i18n-dev at openjdk.java.net"i18n-dev at openjdk.java.net; HYPERLINK "mailto:core-libs-dev at openjdk.java.net"core-libs-dev at openjdk.java.net
Subject: Re: RFR: 8151876: (tz) Support tzdata2016d

?

CLDR locale data defines time zone names, like this (in en.xml):

?????????????????????? <metazone type="Almaty">
??????????????????????????????? <long>
??????????????????????????????????????? <generic>Almaty Time</generic>
???????????????????????????????? ???????<standard>Almaty Standard Time</standard>
??????????????????????????????????????? <daylight>Almaty Summer Time</daylight>
??????????????????????????????? </long>
??????????????????????? </metazone>
?

The CLDR converter tool tries to fill in the missing short names from the legacy TimeZoneNames data. Removing existing names causes some unexpected behavior. I think JDK-8157814 is an example of the unexpected behavior. And the suggested fix in JDK-8157814 looks to me like a workaround.

I still think the existing names should be kept unchanged for this fix.

Thanks,
Masayoshi

On 5/28/2016 12:04 AM, Se?n Coffey wrote:

I guess there's a low risk of timezone not being identified if being parsed in through a formatter. Isn't such an approach discouraged though ? short IDs were already subject to change in tzdata releases. Ramanand found one issue by removal of these resource strings (so far) and that's captured in JDK-8157814

There's a decision to be made about how to use the GMT?hh:mm format for new releases given IANA's new short ID identifier mechanism. I think that could be discussed as a separate issue. I'd like to see us follow a similar approach to IANA and use GMT identifiers on new timezones and perhaps even consider using the IANA long name format also for the getDisplayName(..) calls that can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time" 

Regards,
Sean.

On 27/05/16 15:24, Masayoshi Okutsu wrote:

This change seems to beyond my proposal that the "GMT?hh:mm" format is used for *new* zones with the "?hh" format. But this change removes *existing* zones which have changed to use the "?hh" format in tzdata. Can this cause any compatibility issues? 

And have we agreed to use the "GMT?hh:mm" format? 

Thanks, 
Masayoshi 


On 5/27/2016 10:19 PM, Se?n Coffey wrote: 




Looks fine to me Ramanand. the recent 2016d changes have introduced some boundary issues for JDK rule parsing and those issues can be followed up in separate issues like you say. 

Regards, 
Sean. 

On 26/05/16 14:22, Ramanand Patil wrote: 




HI all, 

Please review the latest TZDATA integration (tzdata2016d) to JDK9. 

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

Webrev: HYPERLINK "http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/"http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/ 

Patch Contains: 

1.?????? IANA tzdata2016d integration into JDK. [It also includes tzdata2016b and tzdata2016c which was not integrated]. 

2.?????? "GMT[+ -]hh:mm" is used for formatting of the modified or newly added TimeZones in tzdata2016d. 

[This is done to accommodate the IANA's new system where the zones use numeric time zone abbreviations like "+04" instead of invented abbreviations like "ASTT".] 

3.?????? Test case: java/time/test/java/time/format/TestZoneTextPrinterParser.java is updated to include the failures because of GMT[+ -]hh:mm format names. 

4.?????? Few other failing tests: For few other failing tests, new linked bugs are created and will be addressed in a separate patch. 


Regards, 

Ramanand. 

?

?

?

?

?

From sean.coffey at oracle.com  Tue May 31 09:34:50 2016
From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=)
Date: Tue, 31 May 2016 10:34:50 +0100
Subject: <i18n dev> RFR: 8151876: (tz) Support tzdata2016d
In-Reply-To: <d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
References: <9b76a353-e477-4f59-b630-5185e9ce6c37@default>
	<5748494F.6060404@oracle.com>
	<12123364-e177-a744-7f24-68e4a8f87532@oracle.com>
	<57486210.7090205@oracle.com>
	<c2c8e2eb-79ad-f4d8-9380-aa9f021c73f6@oracle.com>
	<783f0b2f-43fb-40ed-9204-889b9a3c2570@default>
	<d9b71b38-caac-9fdb-a28d-614e8bb183d1@oracle.com>
Message-ID: <f0ea741f-2873-a2ff-cdce-40785b5c442b@oracle.com>

Masayoshi,

I still think the test adds value. At minimum it identifies timezones 
which don't have a localised string in the JRE provider.

We need to start another discussion about how best to represent timezone 
names for newly added timezones. At the moment, short and long formats 
will be of "GMT?hh:mm" format. I suggest we use the IANA timezone name 
for the long format name in future (e.g. "Asia/Tomsk" instead of 
"GMT+06:00")

For the sake of getting this into the JDK code lines, I suggest we go 
ahead with your suggestion to remove the test for now. I've also 
reviewed this Ramanand. Your edits look fine (including test removal for 
now)

Regards,
Sean.

On 31/05/2016 07:06, Masayoshi Okutsu wrote:
>
> The CheckDisplayNames.java change is different from what I suggested 
> and doesn't make sense. But we no longer need the test. I'd suggest 
> CheckDisplayNames.java be removed. Otherwise, the fix looks OK to me.
>
> Masayoshi
>
>
> On 5/31/2016 3:03 AM, Ramanand Patil wrote:
>>
>> Hi Masayoshi and All,
>>
>> Here is the updated Webrev: 
>> http://cr.openjdk.java.net/~rpatil/8151876/webrev.01/ 
>> <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.01/>
>>
>> As suggested by Masayoshi, I have kept the existing names unchanged.
>>
>>
>>     Also, this patch contains extra test case fixes for
>>
>>
>>     1./java/util/TimeZone/CheckDisplayNames.java/
>>
>>
>>     2.java/util/TimeZone/Bug8149452.java
>>
>> The exclusion for the *newly* added TimeZones is added in these test 
>> cases where the entries are not present in the resources and the 
>> Short/Long display names fallback to the GMT?hh:mm format.
>>
>> Regards,
>>
>> Ramanand.
>>
>> *From:*Masayoshi Okutsu
>> *Sent:* Saturday, May 28, 2016 10:58 AM
>> *To:* Se?n Coffey; Ramanand Patil; i18n-dev at openjdk.java.net; 
>> core-libs-dev at openjdk.java.net
>> *Subject:* Re: RFR: 8151876: (tz) Support tzdata2016d
>>
>> CLDR locale data defines time zone names, like this (in en.xml):
>>
>>                         <metazone type="Almaty">
>>                                  <long>
>>                                          <generic>Almaty Time</generic>
>>                                          <standard>Almaty Standard Time</standard>
>>                                          <daylight>Almaty Summer Time</daylight>
>>                                  </long>
>>                          </metazone>
>>
>> The CLDR converter tool tries to fill in the missing short names from 
>> the legacy TimeZoneNames data. Removing existing names causes some 
>> unexpected behavior. I think JDK-8157814 is an example of the 
>> unexpected behavior. And the suggested fix in JDK-8157814 looks to me 
>> like a workaround.
>>
>> I still think the existing names should be kept unchanged for this fix.
>>
>> Thanks,
>> Masayoshi
>>
>> On 5/28/2016 12:04 AM, Se?n Coffey wrote:
>>
>>     I guess there's a low risk of timezone not being identified if
>>     being parsed in through a formatter. Isn't such an approach
>>     discouraged though ? short IDs were already subject to change in
>>     tzdata releases. Ramanand found one issue by removal of these
>>     resource strings (so far) and that's captured in JDK-8157814
>>
>>     There's a decision to be made about how to use the GMT?hh:mm
>>     format for new releases given IANA's new short ID identifier
>>     mechanism. I think that could be discussed as a separate issue.
>>     I'd like to see us follow a similar approach to IANA and use GMT
>>     identifiers on new timezones and perhaps even consider using the
>>     IANA long name format also for the getDisplayName(..) calls that
>>     can be made. e.g. "Asia/Almaty" instead of "Alma-Ata Time"
>>
>>     Regards,
>>
>>     Sean.
>>
>>     On 27/05/16 15:24, Masayoshi Okutsu wrote:
>>
>>         This change seems to beyond my proposal that the "GMT?hh:mm"
>>         format is used for *new* zones with the "?hh" format. But
>>         this change removes *existing* zones which have changed to
>>         use the "?hh" format in tzdata. Can this cause any
>>         compatibility issues?
>>
>>         And have we agreed to use the "GMT?hh:mm" format?
>>
>>         Thanks,
>>         Masayoshi
>>
>>
>>         On 5/27/2016 10:19 PM, Se?n Coffey wrote:
>>
>>         Looks fine to me Ramanand. the recent 2016d changes have
>>         introduced some boundary issues for JDK rule parsing and
>>         those issues can be followed up in separate issues like you say.
>>
>>         Regards,
>>         Sean.
>>
>>         On 26/05/16 14:22, Ramanand Patil wrote:
>>
>>         HI all,
>>
>>         Please review the latest TZDATA integration (tzdata2016d) to
>>         JDK9.
>>
>>         Bug: https://bugs.openjdk.java.net/browse/JDK-8151876
>>
>>         Webrev: http://cr.openjdk.java.net/~rpatil/8151876/webrev.00/
>>         <http://cr.openjdk.java.net/%7Erpatil/8151876/webrev.00/>
>>
>>         Patch Contains:
>>
>>         1.       IANA tzdata2016d integration into JDK. [It also
>>         includes tzdata2016b and tzdata2016c which was not integrated].
>>
>>         2.       "GMT[+ -]hh:mm" is used for formatting of the
>>         modified or newly added TimeZones in tzdata2016d.
>>
>>         [This is done to accommodate the IANA's new system where the
>>         zones use numeric time zone abbreviations like "+04" instead
>>         of invented abbreviations like "ASTT".]
>>
>>         3.       Test case:
>>         java/time/test/java/time/format/TestZoneTextPrinterParser.java
>>         is updated to include the failures because of GMT[+ -]hh:mm
>>         format names.
>>
>>         4.       Few other failing tests: For few other failing
>>         tests, new linked bugs are created and will be addressed in a
>>         separate patch.
>>
>>
>>         Regards,
>>
>>         Ramanand.
>>
>