From masayoshi.okutsu at oracle.com Wed Aug 6 08:03:23 2014 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 06 Aug 2014 17:03:23 +0900 Subject: [9] RFR: 8048123: Replace calendars.properties with another mechanism to specify a new Japanese calendar era In-Reply-To: <53DA4FC5.4070700@oracle.com> References: <53CE0D8C.7060803@oracle.com> <53CEB102.3000705@oracle.com> <53CEEFD3.8070106@oracle.com> <53CF7668.4070104@oracle.com> <53CFB73F.7080507@oracle.com> <53CFE650.20605@oracle.com> <53D054CF.5010309@oracle.com> <53DA4FC5.4070700@oracle.com> Message-ID: <53E1E14B.10401@oracle.com> I've renamed the test programs and added a test case for java.time. While I was adding the test case, I found JapaneseEra.getDisplayName doesn't work with an additional era (JDK-8054214). I've already fixed it, but the fix will be pushed separately later. No other changes in this webrev. http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.02/ Thanks, Masayoshi On 7/31/2014 11:16 PM, Masayoshi Okutsu wrote: > I've decided to follow the current spec -- ignoring any invalid > property values. This way applications can still run without removing > the property even after installing a fixed update release. > > Thanks, > Masayoshi > > On 7/24/2014 9:35 AM, Masayoshi Okutsu wrote: >> The expected property usage, which hasn't changed from the properties >> file, is that we will provide the correct property value of any new >> era probably with a test program which will verify the given values. >> For JDK 6 to 8, the updated property file will need to be provided by >> us with a test program. I don't expect that users regularly and >> randomly define their own eras. The Japanese government defines eras >> by decrees [1][2]. >> >> I could change the spec, which requires another CCC cycle, and add >> error logging. But I believe that's overkill for the functionality >> and its usage (basically only once every several ten years for the >> limited number of users). In addition, the syntax isn't complicated >> at all. And if any wrong values are given, such as a typo in the >> given name, there will be no way to detect it in the API anyway. >> >> BTW, I tend to avoid use of logging (and some other APIs) in the >> date-time API. It could create inter dependencies leading to an >> infinite loop to use some APIs from the date-time API. IIRC Sherman >> and I have worked on such bug reports. It's far more difficult to >> diagnose inter dependencies than syntax errors of the simple property >> value. >> >> If it's necessary to report any syntax errors, I think throwing an >> exception should be a solution. So, should I start over from the spec? >> >> Thanks, >> Masayoshi >> >> [1] http://law.e-gov.go.jp/htmldata/S64/S64SE001.html >> [2] >> http://www.mext.go.jp/b_menu/hakusho/nc/k19890107001/k19890107001.html >> >> On 7/24/2014 1:44 AM, Naoto Sato wrote: >>> Although I believe the incorrect behavior would be very obvious >>> ("era" specified in the property would simply be not used), I would >>> agree the failed property be better logged. >>> >>> Naoto >>> >>> On 7/23/14, 6:23 AM, Alan Bateman wrote: >>>> On 23/07/2014 09:46, Masayoshi Okutsu wrote: >>>>> Revised the webrev: >>>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01 >>>>> >>>>> The changes from the previous one are: >>>>> - Changed
 (originally 
) to 
{@code
>>>>> - Replaced StringTokenizer with String.split()
>>>>> - Eliminated RuntimeException
>>>> The use of {@code ..} and replacing the usage of StringTokenizer look
>>>> good me.
>>>>
>>>> I'm not so sure about silently ignoring errors in the property value,
>>>> mostly because it would lead to incorrect behavior that is likely 
>>>> to be
>>>> very difficult to track down. If there area used logging then there
>>>> might be some hope of finding it but this isn't the case.
>>>>
>>>> -Alan
>>
>


From aleksej.efimov at oracle.com  Wed Aug  6 13:30:30 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 06 Aug 2014 17:30:30 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014e
In-Reply-To: <53CEB9B3.50307@oracle.com>
References: <53CEB9B3.50307@oracle.com>
Message-ID: <53E22DF6.9080104@oracle.com>

Hello,

Can I ask one more time for a review of this tzdata fix, please?

-Aleksej

On 07/22/2014 11:21 PM, Aleksej Efimov wrote:
> Hi,
>
> Please review the tzdata2014e [1] integration fix to JDK9: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
>
> Two issues with JSR310 implementation were discovered during 
> integration process:
> First issue is related to the internal representation of the '24:00' 
> value. The JSR310 implementation treats this value as a next day 00:00 
> time. The workaround already exists in the code for similar entries 
> and this failure was resolved in similar way [2].
> For the second issue JDK-8051641 [3] was filled and 
> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
> fails with this tzdata.
> Other time zone related test passes without failures.
>
> Thank you,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
> [2] 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/src/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
> [3] https://bugs.openjdk.java.net/browse/JDK-8051641


From naoto.sato at oracle.com  Wed Aug  6 17:14:06 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 06 Aug 2014 10:14:06 -0700
Subject:  [9] RFR: 8048123: Replace calendars.properties with
 another mechanism to specify a new Japanese calendar era
In-Reply-To: <53E1E14B.10401@oracle.com>
References: <53CE0D8C.7060803@oracle.com>	<53CEB102.3000705@oracle.com>	<53CEEFD3.8070106@oracle.com>	<53CF7668.4070104@oracle.com>	<53CFB73F.7080507@oracle.com>	<53CFE650.20605@oracle.com>	<53D054CF.5010309@oracle.com>	<53DA4FC5.4070700@oracle.com>
	<53E1E14B.10401@oracle.com>
Message-ID: <53E2625E.6060000@oracle.com>

Looks good to me.

Naoto

On 8/6/14, 1:03 AM, Masayoshi Okutsu wrote:
> I've renamed the test programs and added a test case for java.time.
> While I was adding the test case, I found JapaneseEra.getDisplayName
> doesn't work with an additional era (JDK-8054214). I've already fixed
> it, but the fix will be pushed separately later.
>
> No other changes in this webrev.
>
> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.02/
>
> Thanks,
> Masayoshi
>
> On 7/31/2014 11:16 PM, Masayoshi Okutsu wrote:
>> I've decided to follow the current spec -- ignoring any invalid
>> property values. This way applications can still run without removing
>> the property even after installing a fixed update release.
>>
>> Thanks,
>> Masayoshi
>>
>> On 7/24/2014 9:35 AM, Masayoshi Okutsu wrote:
>>> The expected property usage, which hasn't changed from the properties
>>> file, is that we will provide the correct property value of any new
>>> era probably with a test program which will verify the given values.
>>> For JDK 6 to 8, the updated property file will need to be provided by
>>> us with a test program. I don't expect that users regularly and
>>> randomly define their own eras. The Japanese government defines eras
>>> by decrees [1][2].
>>>
>>> I could change the spec, which requires another CCC cycle, and add
>>> error logging. But I believe that's overkill for the functionality
>>> and its usage (basically only once every several ten years for the
>>> limited number of users). In addition, the syntax isn't complicated
>>> at all. And if any wrong values are given, such as a typo in the
>>> given name, there will be no way to detect it in the API anyway.
>>>
>>> BTW, I tend to avoid use of logging (and some other APIs) in the
>>> date-time API. It could create inter dependencies leading to an
>>> infinite loop to use some APIs from the date-time API. IIRC Sherman
>>> and I have worked on such bug reports. It's far more difficult to
>>> diagnose inter dependencies than syntax errors of the simple property
>>> value.
>>>
>>> If it's necessary to report any syntax errors, I think throwing an
>>> exception should be a solution. So, should I start over from the spec?
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> [1] http://law.e-gov.go.jp/htmldata/S64/S64SE001.html
>>> [2]
>>> http://www.mext.go.jp/b_menu/hakusho/nc/k19890107001/k19890107001.html
>>>
>>> On 7/24/2014 1:44 AM, Naoto Sato wrote:
>>>> Although I believe the incorrect behavior would be very obvious
>>>> ("era" specified in the property would simply be not used), I would
>>>> agree the failed property be better logged.
>>>>
>>>> Naoto
>>>>
>>>> On 7/23/14, 6:23 AM, Alan Bateman wrote:
>>>>> On 23/07/2014 09:46, Masayoshi Okutsu wrote:
>>>>>> Revised the webrev:
>>>>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>>>>>>
>>>>>> The changes from the previous one are:
>>>>>> - Changed 
 (originally 
) to 
{@code
>>>>>> - Replaced StringTokenizer with String.split()
>>>>>> - Eliminated RuntimeException
>>>>> The use of {@code ..} and replacing the usage of StringTokenizer look
>>>>> good me.
>>>>>
>>>>> I'm not so sure about silently ignoring errors in the property value,
>>>>> mostly because it would lead to incorrect behavior that is likely
>>>>> to be
>>>>> very difficult to track down. If there area used logging then there
>>>>> might be some hope of finding it but this isn't the case.
>>>>>
>>>>> -Alan
>>>
>>
>

From aleksej.efimov at oracle.com  Wed Aug  6 19:13:05 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 06 Aug 2014 23:13:05 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014e
In-Reply-To: <53E22DF6.9080104@oracle.com>
References: <53CEB9B3.50307@oracle.com> <53E22DF6.9080104@oracle.com>
Message-ID: <53E27E41.9060102@oracle.com>

Hello,
I'm withdrawing this review request because the new tzdata2014f release 
is available. I will update the 8049343 bug and will use it for later 
tzdata2014f integration.


Thank you,
Aleksej

On 08/06/2014 05:30 PM, Aleksej Efimov wrote:
> Hello,
>
> Can I ask one more time for a review of this tzdata fix, please?
>
> -Aleksej
>
> On 07/22/2014 11:21 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please review the tzdata2014e [1] integration fix to JDK9: 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/
>>
>> Two issues with JSR310 implementation were discovered during 
>> integration process:
>> First issue is related to the internal representation of the '24:00' 
>> value. The JSR310 implementation treats this value as a next day 
>> 00:00 time. The workaround already exists in the code for similar 
>> entries and this failure was resolved in similar way [2].
>> For the second issue JDK-8051641 [3] was filled and 
>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
>> fails with this tzdata.
>> Other time zone related test passes without failures.
>>
>> Thank you,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>> [2] 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.00/src/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>


From martinrb at google.com  Sun Aug 17 01:11:53 2014
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 16 Aug 2014 18:11:53 -0700
Subject:  RFR: 8055253: test/java/util/Currency/PropertiesTest.sh
 modifies the test JDK
Message-ID: 

Hi Naoto, Alan,

I'd like you to do a code review.

http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-concurrency/
https://bugs.openjdk.java.net/browse/JDK-8055253

This will fix the transient failures in Currency ONCE AND FOR ALL!

From masayoshi.okutsu at oracle.com  Mon Aug 18 09:39:20 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 18 Aug 2014 18:39:20 +0900
Subject:  [9] RFR: 8055088: Optimization for locale resources
 loading isn't working
Message-ID: <53F1C9C8.1000905@oracle.com>

Hello,

Please review the fix for the broken optimization code for resource 
bundle loading.

bug:
https://bugs.openjdk.java.net/browse/JDK-8055088

wevrev:
http://cr.openjdk.java.net/~okutsu/9/8055088/webrev.00/

Note that BreakIteratorInfo and BreakIteratorRules, which are not used 
for any getAvailableLocales, have been added to LocaleDataMetaInfo.

Thanks,
Masayoshi


From naoto.sato at oracle.com  Mon Aug 18 17:43:13 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 18 Aug 2014 10:43:13 -0700
Subject:  RFR: 8055253:
 test/java/util/Currency/PropertiesTest.sh modifies the test JDK
In-Reply-To: 
References: 
Message-ID: <53F23B31.1080903@oracle.com>

Hi Martin,

Initial intention for not copying the JDK was to avoid timeout for some 
cases in slow networked environment. But it still does not avoid all the 
cases. So, yes I am fine with your fix.

Naoto

On 8/16/14, 6:11 PM, Martin Buchholz wrote:
> Hi Naoto, Alan,
>
> I'd like you to do a code review.
>
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-concurrency/
> https://bugs.openjdk.java.net/browse/JDK-8055253
>
> This will fix the transient failures in Currency ONCE AND FOR ALL!

From naoto.sato at oracle.com  Mon Aug 18 18:26:07 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 18 Aug 2014 11:26:07 -0700
Subject:  [9] RFR: 8055088: Optimization for locale resources
 loading isn't working
In-Reply-To: <53F1C9C8.1000905@oracle.com>
References: <53F1C9C8.1000905@oracle.com>
Message-ID: <53F2453F.5000908@oracle.com>

Looks good to me.

Naoto

On 8/18/14, 2:39 AM, Masayoshi Okutsu wrote:
> Hello,
>
> Please review the fix for the broken optimization code for resource
> bundle loading.
>
> bug:
> https://bugs.openjdk.java.net/browse/JDK-8055088
>
> wevrev:
> http://cr.openjdk.java.net/~okutsu/9/8055088/webrev.00/
>
> Note that BreakIteratorInfo and BreakIteratorRules, which are not used
> for any getAvailableLocales, have been added to LocaleDataMetaInfo.
>
> Thanks,
> Masayoshi
>

From martinrb at google.com  Tue Aug 19 04:05:39 2014
From: martinrb at google.com (Martin Buchholz)
Date: Mon, 18 Aug 2014 21:05:39 -0700
Subject:  RFR: 8055253:
 test/java/util/Currency/PropertiesTest.sh modifies the test JDK
In-Reply-To: <53F23B31.1080903@oracle.com>
References: 
	<53F23B31.1080903@oracle.com>
Message-ID: 

I'll commit this.

There are occasionally tests too expensive to run on a regular basis.  For
those, we should use a common mechanism (like test labelling) to ensure
that expensive tests are run less frequently, but not never.


On Mon, Aug 18, 2014 at 10:43 AM, Naoto Sato  wrote:

> Hi Martin,
>
> Initial intention for not copying the JDK was to avoid timeout for some
> cases in slow networked environment. But it still does not avoid all the
> cases. So, yes I am fine with your fix.
>
> Naoto
>
>
> On 8/16/14, 6:11 PM, Martin Buchholz wrote:
>
>> Hi Naoto, Alan,
>>
>> I'd like you to do a code review.
>>
>> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-concurrency/
>> https://bugs.openjdk.java.net/browse/JDK-8055253
>>
>> This will fix the transient failures in Currency ONCE AND FOR ALL!
>>
>

From aleksej.efimov at oracle.com  Wed Aug 20 14:59:09 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 20 Aug 2014 18:59:09 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014f
Message-ID: <53F4B7BD.8020705@oracle.com>

Hi,

Please, review the tzdata2014f integration (with tzdata2014e related 
changes included too) [1] fix to JDK9: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/

The tzdata2014f changes are extensive and relates mostly to timezone 
short names changes + "Asia/Srednekolymsk" time zone were added.
Almost complete list of changes can be found in the JBS bug description 
[1], plus some changes wasn't documented in tzdata release notes - for 
such cases raw tzdata diff was used for the names modifications.

Two issues with JSR310 implementation were discovered during integration 
process:
First issue is related to the internal representation of the '24:00' 
value. The JSR310 implementation treats this value as a next day 00:00 
time. The workaround already exists in JSR310 code for similar entries 
and this failure is resolved in similar way [2] as part of this update.
For the second issue JDK-8051641 [3] was filled and 
'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
fails with this tzdata.
Other time zone related tests [4] passes without failures.

Thank you,
Aleksej

[1] https://bugs.openjdk.java.net/browse/JDK-8049343
[2] 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
[3] https://bugs.openjdk.java.net/browse/JDK-8051641
[4] TZ related test sets: test/sun/util/calendar test/java/util/Calendar 
test/sun/util/resources/TimeZone test/sun/util/calendar 
test/java/util/TimeZone test/java/time\ test/java/util/Formatter 
test/closed/java/util/Calendar test/closed/java/util/TimeZone

From martinrb at google.com  Wed Aug 20 17:39:12 2014
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 20 Aug 2014 10:39:12 -0700
Subject:  RFR: JDK-8055675 java/util/Currency/PropertiesTest.sh
 fails on OS X after JDK-8055253
Message-ID: 

Hi Naoto,

I'd like you to do a code review to fix test breakage on macosx.

https://bugs.openjdk.java.net/browse/JDK-8055675#comment-13541658
http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-PropertiesTest-hygiene/

From naoto.sato at oracle.com  Wed Aug 20 17:52:43 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 20 Aug 2014 10:52:43 -0700
Subject:  RFR: JDK-8055675
 java/util/Currency/PropertiesTest.sh fails on OS X after JDK-8055253
In-Reply-To: 
References: 
Message-ID: <53F4E06B.3090009@oracle.com>

Looks good to me.

Naoto

On 8/20/14, 10:39 AM, Martin Buchholz wrote:
> Hi Naoto,
>
> I'd like you to do a code review to fix test breakage on macosx.
>
> https://bugs.openjdk.java.net/browse/JDK-8055675#comment-13541658
> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/Currency-PropertiesTest-hygiene/

From masayoshi.okutsu at oracle.com  Thu Aug 21 02:32:36 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 21 Aug 2014 11:32:36 +0900
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53F4B7BD.8020705@oracle.com>
References: <53F4B7BD.8020705@oracle.com>
Message-ID: <53F55A44.6010501@oracle.com>

I think the long names of the Australia time zones should be revisited 
to be consistent with the abbreviation changes. The new abbreviations 
follow the S[tandard] and D[aylight saving] convention rather than the 
S[tandard] and S[ummer time] one. The long names, such as "Eastern 
Summer Time (Queensland)", no longer make sense.

On the other hand, you will need to access impact of the name changes, 
including abbreviations. Also, if you change the long names, their 
translations will need to be changed as well.

Thanks,
Masayoshi

On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
> Hi,
>
> Please, review the tzdata2014f integration (with tzdata2014e related 
> changes included too) [1] fix to JDK9: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>
> The tzdata2014f changes are extensive and relates mostly to timezone 
> short names changes + "Asia/Srednekolymsk" time zone were added.
> Almost complete list of changes can be found in the JBS bug 
> description [1], plus some changes wasn't documented in tzdata release 
> notes - for such cases raw tzdata diff was used for the names 
> modifications.
>
> Two issues with JSR310 implementation were discovered during 
> integration process:
> First issue is related to the internal representation of the '24:00' 
> value. The JSR310 implementation treats this value as a next day 00:00 
> time. The workaround already exists in JSR310 code for similar entries 
> and this failure is resolved in similar way [2] as part of this update.
> For the second issue JDK-8051641 [3] was filled and 
> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
> fails with this tzdata.
> Other time zone related tests [4] passes without failures.
>
> Thank you,
> Aleksej
>
> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
> [2] 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
> [4] TZ related test sets: test/sun/util/calendar 
> test/java/util/Calendar test/sun/util/resources/TimeZone 
> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
> test/java/util/Formatter test/closed/java/util/Calendar 
> test/closed/java/util/TimeZone


From aleksej.efimov at oracle.com  Thu Aug 21 08:05:23 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Thu, 21 Aug 2014 12:05:23 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53F55A44.6010501@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
Message-ID: <53F5A843.3000302@oracle.com>

Masayoshi,
I agree that we should change the long names to match the new short 
names introduced by tzdata.
But I suggest to log a different CR for such activity to handle long 
name changes and their translations (this activity is slightly out of 
tzdata update scope). Does it make sense?

-Aleksej

On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
> I think the long names of the Australia time zones should be revisited 
> to be consistent with the abbreviation changes. The new abbreviations 
> follow the S[tandard] and D[aylight saving] convention rather than the 
> S[tandard] and S[ummer time] one. The long names, such as "Eastern 
> Summer Time (Queensland)", no longer make sense.
>
> On the other hand, you will need to access impact of the name changes, 
> including abbreviations. Also, if you change the long names, their 
> translations will need to be changed as well.
>
> Thanks,
> Masayoshi
>
> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>> Hi,
>>
>> Please, review the tzdata2014f integration (with tzdata2014e related 
>> changes included too) [1] fix to JDK9: 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>
>> The tzdata2014f changes are extensive and relates mostly to timezone 
>> short names changes + "Asia/Srednekolymsk" time zone were added.
>> Almost complete list of changes can be found in the JBS bug 
>> description [1], plus some changes wasn't documented in tzdata 
>> release notes - for such cases raw tzdata diff was used for the names 
>> modifications.
>>
>> Two issues with JSR310 implementation were discovered during 
>> integration process:
>> First issue is related to the internal representation of the '24:00' 
>> value. The JSR310 implementation treats this value as a next day 
>> 00:00 time. The workaround already exists in JSR310 code for similar 
>> entries and this failure is resolved in similar way [2] as part of 
>> this update.
>> For the second issue JDK-8051641 [3] was filled and 
>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one that 
>> fails with this tzdata.
>> Other time zone related tests [4] passes without failures.
>>
>> Thank you,
>> Aleksej
>>
>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>> [2] 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>> [4] TZ related test sets: test/sun/util/calendar 
>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>> test/java/util/Formatter test/closed/java/util/Calendar 
>> test/closed/java/util/TimeZone
>


From masayoshi.okutsu at oracle.com  Thu Aug 21 11:51:08 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 21 Aug 2014 20:51:08 +0900
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53F5A843.3000302@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com>
Message-ID: <53F5DD2C.1010706@oracle.com>

We used to make name changes in the root (base) bundle as part of time 
zone data maintenance and deter only translations. But if you want to 
handle name changes later, that would be fine. It's your call.

Thanks,
Masayoshi

On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
> Masayoshi,
> I agree that we should change the long names to match the new short 
> names introduced by tzdata.
> But I suggest to log a different CR for such activity to handle long 
> name changes and their translations (this activity is slightly out of 
> tzdata update scope). Does it make sense?
>
> -Aleksej
>
> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>> I think the long names of the Australia time zones should be 
>> revisited to be consistent with the abbreviation changes. The new 
>> abbreviations follow the S[tandard] and D[aylight saving] convention 
>> rather than the S[tandard] and S[ummer time] one. The long names, 
>> such as "Eastern Summer Time (Queensland)", no longer make sense.
>>
>> On the other hand, you will need to access impact of the name 
>> changes, including abbreviations. Also, if you change the long names, 
>> their translations will need to be changed as well.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>> Hi,
>>>
>>> Please, review the tzdata2014f integration (with tzdata2014e related 
>>> changes included too) [1] fix to JDK9: 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>
>>> The tzdata2014f changes are extensive and relates mostly to timezone 
>>> short names changes + "Asia/Srednekolymsk" time zone were added.
>>> Almost complete list of changes can be found in the JBS bug 
>>> description [1], plus some changes wasn't documented in tzdata 
>>> release notes - for such cases raw tzdata diff was used for the 
>>> names modifications.
>>>
>>> Two issues with JSR310 implementation were discovered during 
>>> integration process:
>>> First issue is related to the internal representation of the '24:00' 
>>> value. The JSR310 implementation treats this value as a next day 
>>> 00:00 time. The workaround already exists in JSR310 code for similar 
>>> entries and this failure is resolved in similar way [2] as part of 
>>> this update.
>>> For the second issue JDK-8051641 [3] was filled and 
>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
>>> that fails with this tzdata.
>>> Other time zone related tests [4] passes without failures.
>>>
>>> Thank you,
>>> Aleksej
>>>
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>> [2] 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>> [4] TZ related test sets: test/sun/util/calendar 
>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>> test/closed/java/util/TimeZone
>>
>


From aleksej.efimov at oracle.com  Fri Aug 22 12:17:28 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Fri, 22 Aug 2014 16:17:28 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53F5DD2C.1010706@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
Message-ID: <53F734D8.1000801@oracle.com>

Masayoshi,
You're right that the "root names" should be changed as part of this 
update. The names were changed according to Australian official document 
here: http://australia.gov.au/about-australia/our-country/time
The fixed version of the webrev can be found here: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02

Thanks,
Aleksej


On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
> We used to make name changes in the root (base) bundle as part of time 
> zone data maintenance and deter only translations. But if you want to 
> handle name changes later, that would be fine. It's your call.
>
> Thanks,
> Masayoshi
>
> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> I agree that we should change the long names to match the new short 
>> names introduced by tzdata.
>> But I suggest to log a different CR for such activity to handle long 
>> name changes and their translations (this activity is slightly out of 
>> tzdata update scope). Does it make sense?
>>
>> -Aleksej
>>
>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>> I think the long names of the Australia time zones should be 
>>> revisited to be consistent with the abbreviation changes. The new 
>>> abbreviations follow the S[tandard] and D[aylight saving] convention 
>>> rather than the S[tandard] and S[ummer time] one. The long names, 
>>> such as "Eastern Summer Time (Queensland)", no longer make sense.
>>>
>>> On the other hand, you will need to access impact of the name 
>>> changes, including abbreviations. Also, if you change the long 
>>> names, their translations will need to be changed as well.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>> Hi,
>>>>
>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>> related changes included too) [1] fix to JDK9: 
>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>
>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>> timezone short names changes + "Asia/Srednekolymsk" time zone were 
>>>> added.
>>>> Almost complete list of changes can be found in the JBS bug 
>>>> description [1], plus some changes wasn't documented in tzdata 
>>>> release notes - for such cases raw tzdata diff was used for the 
>>>> names modifications.
>>>>
>>>> Two issues with JSR310 implementation were discovered during 
>>>> integration process:
>>>> First issue is related to the internal representation of the 
>>>> '24:00' value. The JSR310 implementation treats this value as a 
>>>> next day 00:00 time. The workaround already exists in JSR310 code 
>>>> for similar entries and this failure is resolved in similar way [2] 
>>>> as part of this update.
>>>> For the second issue JDK-8051641 [3] was filled and 
>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
>>>> that fails with this tzdata.
>>>> Other time zone related tests [4] passes without failures.
>>>>
>>>> Thank you,
>>>> Aleksej
>>>>
>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>> [2] 
>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>> test/closed/java/util/TimeZone
>>>
>>
>


From naoto.sato at oracle.com  Fri Aug 22 18:46:43 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Aug 2014 11:46:43 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to determine
 available localedata and cldrdata
Message-ID: <53F79013.9030607@oracle.com>

Hello,

Please review the changes for the following issue:

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

The proposed changes are located at:

http://cr.openjdk.java.net/~naoto/8038436/webrev.3/

The idea is to introduce an SPI so that supported locales are 
dynamically searched at runtime, not depending on the existence of 
physical jar files.

I'd appreciate it if build folks could review the makefile related 
changes, i18n forks to review locale framework files, and Mandy from 
modularization point of view.

Naoto

From mandy.chung at oracle.com  Fri Aug 22 21:26:58 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 22 Aug 2014 14:26:58 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F79013.9030607@oracle.com>
References: <53F79013.9030607@oracle.com>
Message-ID: <53F7B5A2.50606@oracle.com>

On 8/22/14 11:46 AM, Naoto Sato wrote:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>
I skimmed on the patch and have a few initial comment/questions.

JREENLocaleDataMetaInfo
JRENonENLocaleDataMetaInfo
    - are the lists of locale names generated previously?
    The long lines need to be broken up.  Perhaps defining them
    as string constants and grouped them per language (or some
    fashion) would make it easier to read and maintain.

    It would be good to define string constants for the en-* locale
    names that are shared by FormatData, CurrencyNames, AvailbleLocales.

    The @since 1.6 is not updated and not needed.

    I wonder ifavailableLanguageTags andgetSupportedLocaleString
    should return a list or an array of String (see comment below).


There are two provider implementations for
sun.util.locale.provider.LocaleDataMetaInfo and two service config
files as you want to put them in cldrdata.jar and localedata.jar.
I wonder if you want to merge them into a single service config
for now until you decide to separate them into separate modules
in the future.

You could simply put it under
src/jdk.localedata/share/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo

sun/util/cldr/CLDRLocaleProviderAdapter.java
    line 67: why do you silently ignore any exception? In that
    case, it will throw UOE in line 71.  Is UOE caught somewhere?
    Assume there is a good reason to ignore the exception,
    can you add comment to explain it?

sun/util/locale/provider/JRELocaleProviderAdapter.java
    line 391: what exceptions do you expect to be caught here?
    Do you have a test case for this to demonstrate why you
    have to ignore the exception?

    LocaleDataMetaInfo.availableLanguageTags returns a string
    of space-separated names.  Would it be better to return
    a List or String[]
    
When you have an image build, it'd be useful to test without
cldrdata.jar and localedata.jar from the extension directory
and run the tests to use the default EN locale.

thanks
Mandy


From naoto.sato at oracle.com  Fri Aug 22 22:37:49 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Aug 2014 15:37:49 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F7B5A2.50606@oracle.com>
References: <53F79013.9030607@oracle.com> <53F7B5A2.50606@oracle.com>
Message-ID: <53F7C63D.5080900@oracle.com>

Thank you Mandy for a quick review. Please see my comments below.

On 8/22/14, 2:26 PM, Mandy Chung wrote:
> On 8/22/14 11:46 AM, Naoto Sato wrote:
>>
>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>>
> I skimmed on the patch and have a few initial comment/questions.
>
> JREENLocaleDataMetaInfo
> JRENonENLocaleDataMetaInfo
>     - are the lists of locale names generated previously?

Yes.

>     The long lines need to be broken up.  Perhaps defining them
>     as string constants and grouped them per language (or some
>     fashion) would make it easier to read and maintain.
>
>     It would be good to define string constants for the en-* locale
>     names that are shared by FormatData, CurrencyNames, AvailbleLocales.
>
>     The @since 1.6 is not updated and not needed.

Will modify the string constants.

>
>     I wonder ifavailableLanguageTags andgetSupportedLocaleString
>     should return a list or an array of String (see comment below).
>
>
> There are two provider implementations for
> sun.util.locale.provider.LocaleDataMetaInfo and two service config
> files as you want to put them in cldrdata.jar and localedata.jar.
> I wonder if you want to merge them into a single service config
> for now until you decide to separate them into separate modules
> in the future.
>
> You could simply put it under
> src/jdk.localedata/share/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo

I tried to merge the config file, but it seems not possible to me to 
have two implementation definitions in a single file, e.g., if the 
config file has two entries

sun.util.locale.provider.JRENonENLocaleDataMetaInfo
sun.util.cldr.CLDRLocaleDataMetaInfo

and localedata.jar/cldrdata.jar have one on those each, ServiceLoader 
lookup failed with the exception (sorry forgot the actual name) saying, 
e.g., CLDRLocaleDataMetaInfo cannot be instantiated from localedata.jar. 
Thus I had to have two service config files.

>
> sun/util/cldr/CLDRLocaleProviderAdapter.java
>     line 67: why do you silently ignore any exception? In that
>     case, it will throw UOE in line 71.  Is UOE caught somewhere?
>     Assume there is a good reason to ignore the exception,
>     can you add comment to explain it?

UOE is caught in JRELocaleProviderAdapter. Will add some more comments 
there.

>
> sun/util/locale/provider/JRELocaleProviderAdapter.java
>     line 391: what exceptions do you expect to be caught here?
>     Do you have a test case for this to demonstrate why you
>     have to ignore the exception?

The one we have been discussing: AccessClassInPackage security exception 
for sun.util.locale.provider classes from localedata.jar/cldrdata.jar. 
Anyway, I followed the ResourceBundle.loadBundle()'s behavior here, 
where it ignores any Exception instances.

>
>     LocaleDataMetaInfo.availableLanguageTags returns a string
>     of space-separated names.  Would it be better to return
>     a List or String[]

I think having a single string is preferred as to the performance, 
especially in CLDR's case there are hundreds of locales involved.

>
> When you have an image build, it'd be useful to test without
> cldrdata.jar and localedata.jar from the extension directory
> and run the tests to use the default EN locale.

Although I don't have any regression tests, I manually tested such 
situations and confirmed it worked correctly.

Naoto

From mandy.chung at oracle.com  Fri Aug 22 22:56:36 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 22 Aug 2014 15:56:36 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F7C63D.5080900@oracle.com>
References: <53F79013.9030607@oracle.com> <53F7B5A2.50606@oracle.com>
	<53F7C63D.5080900@oracle.com>
Message-ID: <53F7CAA4.4000800@oracle.com>

On 8/22/14 3:37 PM, Naoto Sato wrote:
>
>>
>>     I wonder ifavailableLanguageTags andgetSupportedLocaleString
>>     should return a list or an array of String (see comment below).
>>
>>
>> There are two provider implementations for
>> sun.util.locale.provider.LocaleDataMetaInfo and two service config
>> files as you want to put them in cldrdata.jar and localedata.jar.
>> I wonder if you want to merge them into a single service config
>> for now until you decide to separate them into separate modules
>> in the future.
>>
>> You could simply put it under
>> src/jdk.localedata/share/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo 
>>
>
> I tried to merge the config file, but it seems not possible to me to 
> have two implementation definitions in a single file, e.g., if the 
> config file has two entries
>
> sun.util.locale.provider.JRENonENLocaleDataMetaInfo
> sun.util.cldr.CLDRLocaleDataMetaInfo
>
> and localedata.jar/cldrdata.jar have one on those each, ServiceLoader 
> lookup failed with the exception (sorry forgot the actual name) 
> saying, e.g., CLDRLocaleDataMetaInfo cannot be instantiated from 
> localedata.jar. Thus I had to have two service config files.

A service config file can contain multiple provider implementation 
classes.  JDI connector is one example:
http://hg.openjdk.java.net/jdk9/dev/jdk/file/74078474d9bd/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector

There may be some bug somewhere.
>
>>
>> sun/util/cldr/CLDRLocaleProviderAdapter.java
>>     line 67: why do you silently ignore any exception? In that
>>     case, it will throw UOE in line 71.  Is UOE caught somewhere?
>>     Assume there is a good reason to ignore the exception,
>>     can you add comment to explain it?
>
> UOE is caught in JRELocaleProviderAdapter. Will add some more comments 
> there.

Is it the SecurityException you try to catch?  perhaps you should throw 
UOE directly at line 68 with the exception as the cause for better 
diagnosability.
>
>>
>> sun/util/locale/provider/JRELocaleProviderAdapter.java
>>     line 391: what exceptions do you expect to be caught here?
>>     Do you have a test case for this to demonstrate why you
>>     have to ignore the exception?
>
> The one we have been discussing: AccessClassInPackage security 
> exception for sun.util.locale.provider classes from 
> localedata.jar/cldrdata.jar. Anyway, I followed the 
> ResourceBundle.loadBundle()'s behavior here, where it ignores any 
> Exception instances.
>

Can you add that test case?
>
>>
>> When you have an image build, it'd be useful to test without
>> cldrdata.jar and localedata.jar from the extension directory
>> and run the tests to use the default EN locale.
>
> Although I don't have any regression tests, I manually tested such 
> situations and confirmed it worked correctly.

Do you mean that the existing regression tests never load cldrdata.jar 
and localedata.jar?  If so, that matches my suggestion to run them on a 
JDK image without cldrdata.jar and localedata.jar and they should pass?

Mandy

From naoto.sato at oracle.com  Fri Aug 22 23:23:47 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Aug 2014 16:23:47 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F7CAA4.4000800@oracle.com>
References: <53F79013.9030607@oracle.com> <53F7B5A2.50606@oracle.com>
	<53F7C63D.5080900@oracle.com> <53F7CAA4.4000800@oracle.com>
Message-ID: <53F7D103.2050908@oracle.com>

On 8/22/14, 3:56 PM, Mandy Chung wrote:
> A service config file can contain multiple provider implementation
> classes.  JDI connector is one example:
> http://hg.openjdk.java.net/jdk9/dev/jdk/file/74078474d9bd/src/jdk.jdi/share/classes/META-INF/services/com.sun.jdi.connect.Connector
>
>
> There may be some bug somewhere.

I know a single service config file can contain multiple implementation 
classes. However in this case, each jar file contains only either of 
those two provider types. For example, localedata.jar only contains 
JRENonENLocaleDataMetaInfo. So if the service config file contained 
CLDRLocaleDataMetaInfo entry, that would fail on loading.

>> UOE is caught in JRELocaleProviderAdapter. Will add some more comments
>> there.
>
> Is it the SecurityException you try to catch?  perhaps you should throw
> UOE directly at line 68 with the exception as the cause for better
> diagnosability.

Will do.

>> The one we have been discussing: AccessClassInPackage security
>> exception for sun.util.locale.provider classes from
>> localedata.jar/cldrdata.jar. Anyway, I followed the
>> ResourceBundle.loadBundle()'s behavior here, where it ignores any
>> Exception instances.
>>
>
> Can you add that test case?

If the code weren't catching the exception, several existing regression 
tests would fail, such as, 
test/java/util/concurrent/atomic/AtomicUpdaters.java which installs a 
Policy that allows no permissions. Do you still need extra test case for 
it which would do the same testing?

>>> When you have an image build, it'd be useful to test without
>>> cldrdata.jar and localedata.jar from the extension directory
>>> and run the tests to use the default EN locale.
>>
>> Although I don't have any regression tests, I manually tested such
>> situations and confirmed it worked correctly.
>
> Do you mean that the existing regression tests never load cldrdata.jar
> and localedata.jar?  If so, that matches my suggestion to run them on a
> JDK image without cldrdata.jar and localedata.jar and they should pass?

There already are test cases that examine localedata/cldrdata locale 
data. Maybe what could be done is to create a test to obtain available 
locales without localedata.jar/cldrdata.jar, and confirm it only 
contains en* locales. Are there any way to run regression tests that can 
run *without* installed JDK extensions?

Naoto

From masayoshi.okutsu at oracle.com  Mon Aug 25 08:41:54 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 25 Aug 2014 17:41:54 +0900
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F79013.9030607@oracle.com>
References: <53F79013.9030607@oracle.com>
Message-ID: <53FAF6D2.7010408@oracle.com>

Here are my comments.

- Looks like this change removed the 8055088 fix for BreakIteratorInfo 
optimization.

- The langtags field in each *Impl class should be volatile.

- DateFormatProviderImpl has static langtags to be shared by some other 
*Impl. But JRE and CLDR have different sets of language tags.

- Now language tags are hard coded, but that will be error prone when 
adding or changing locale data. There should be a test case for checking 
consistency between existing resource bundles and the hard-coded tags 
(to detect any missing locales in the hard-coded lists).

- JREENLocaleDataMetaInfo: the first upper case part looks like one word 
JREEN. JreEnLocaleDataMetaInfo may be better. It's not consistent with 
others, though.

Masayoshi


On 8/23/2014 3:46 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8038436
>
> The proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>
> The idea is to introduce an SPI so that supported locales are 
> dynamically searched at runtime, not depending on the existence of 
> physical jar files.
>
> I'd appreciate it if build folks could review the makefile related 
> changes, i18n forks to review locale framework files, and Mandy from 
> modularization point of view.
>
> Naoto


From Alan.Bateman at oracle.com  Mon Aug 25 16:28:31 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 25 Aug 2014 17:28:31 +0100
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F79013.9030607@oracle.com>
References: <53F79013.9030607@oracle.com>
Message-ID: <53FB642F.3090902@oracle.com>

On 22/08/2014 19:46, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8038436
>
> The proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>
> The idea is to introduce an SPI so that supported locales are 
> dynamically searched at runtime, not depending on the existence of 
> physical jar files.
>
> I'd appreciate it if build folks could review the makefile related 
> changes, i18n forks to review locale framework files, and Mandy from 
> modularization point of view.
I've skimmed over the changes (not a detailed review, I see Mandy and 
Masayoshi are doing that). It is good to see this code changed to use 
ServiceLoader and dropping the direct access to localeddata.jar and 
cldrdata.jar. It would be useful to see if you can run a few startup 
performance tests to see that the changes have any impact.

On JREENLocaleDataMetaInfo then I wonder if you've considering using 
camel case instead. Maybe "JRE" could be dropped (I realize the type is 
"JRE") and it can be renamed to EnLocaleDataMetaInfo to avoid all caps 
"JREEN".

A minor comment on JREENLocaleDataMetaInfo.getSupportedLocaleString is 
that it could be changed to return 
resourceNameToLocales.getOrDefault(resourceName, "");

For the initialization then this might be help with some of the long 
lines and might make the publication a bit clearer too:

private static final Map resourceNameToLocales ;

static {
     Map map = new HashMap<>();
     map.put(...);
     resourceNameToLocales = map;
}

On the long lines then JRENonENLocaleDataMetaInfo will need attention as 
the 872 character line will make future side-by-side reviews fun :-)

In CLDRLocaleProviderAdapter's constructor then it is catches/ignores 
exceptions, the subsequent UOE does not help diagnose any issues. 
Hopefully this can be re-examined before these changes are pushed as any 
issue here would be difficult to diagnose.

One thing that isn't clear to me is the getLangTags implementations in 
several classes where it has to cast to JRELocaleProviderAdapter. It's 
not clear to the reader why this is necessary and how it would behave 
with CLDRLocaleProviderAdapter.

-Alan.



From masayoshi.okutsu at oracle.com  Wed Aug 27 08:34:33 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 27 Aug 2014 17:34:33 +0900
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53F734D8.1000801@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com>
Message-ID: <53FD9819.7080000@oracle.com>

Here are additional comments.

src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:

I'm concerned about the workarounds. It's not new in this update, but 
this problem would make tzupdater data void until the workaround is 
added to the next update release. Could you please work with Sherman to 
eliminate the workaround (outside of this 2014f update)?

src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

          String LORD_HOWE[] = new String[] {"Lord Howe Standard Time", "LHST",
-                                           "Lord Howe Summer Time", "LHST",
+                                           "Lord Howe Summer Time", "LHDT",

The S-D convention is applied to Lord Howe as well.

  567             {"Antarctica/Macquarie", new String[] {"Macquarie Island Time", "MIST",
  568                                                    "Macquarie Island Summer Time", "MIST",
  569                                                    "Macquarie Island Time", "MIST"}},

This one should also follow the S-D convention, although this time zone 
doesn't observe daylight saving time.


+        String XJT[] = new String[] {"China Standard Time", "XJT",
+                                     "China Daylight Time", "XJDT",
+                                     "China Time", "XJT"};

Should the long names be based on Xinjiang?

Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
same time zone.

-            {"America/Metlakatla", new String[] {"Metlakatla Standard Time", "MeST",
-                                                 "Metlakatla Daylight Time", "MeDT",
-                                                 "Metlakatla Time", "MeT"}},
+            {"America/Metlakatla", new String[] {"Metlakatla Standard Time", "PST",
+                                                 "Metlakatla Daylight Time", "PDT",
+                                                 "Metlakatla Time", "PT"}},

-            {"Europe/Volgograd", new String[] {"Volgograd Time", "VOLT",
-                                               "Volgograd Summer Time", "VOLST",
-                                               "Volgograd Time", "VOLT"}},
+            {"Europe/Volgograd", new String[] {"Volgograd Time", "MSK",
+                                               "Volgograd Summer Time", "MSK",
+                                               "Volgograd Time", "MSK"}},
  

The long names should be changed accordingly.

Thanks,
Masayoshi

On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
> Masayoshi,
> You're right that the "root names" should be changed as part of this 
> update. The names were changed according to Australian official 
> document here: http://australia.gov.au/about-australia/our-country/time
> The fixed version of the webrev can be found here: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>
> Thanks,
> Aleksej
>
>
> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>> We used to make name changes in the root (base) bundle as part of 
>> time zone data maintenance and deter only translations. But if you 
>> want to handle name changes later, that would be fine. It's your call.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> I agree that we should change the long names to match the new short 
>>> names introduced by tzdata.
>>> But I suggest to log a different CR for such activity to handle long 
>>> name changes and their translations (this activity is slightly out 
>>> of tzdata update scope). Does it make sense?
>>>
>>> -Aleksej
>>>
>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>> I think the long names of the Australia time zones should be 
>>>> revisited to be consistent with the abbreviation changes. The new 
>>>> abbreviations follow the S[tandard] and D[aylight saving] 
>>>> convention rather than the S[tandard] and S[ummer time] one. The 
>>>> long names, such as "Eastern Summer Time (Queensland)", no longer 
>>>> make sense.
>>>>
>>>> On the other hand, you will need to access impact of the name 
>>>> changes, including abbreviations. Also, if you change the long 
>>>> names, their translations will need to be changed as well.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>> Hi,
>>>>>
>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>> related changes included too) [1] fix to JDK9: 
>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>
>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone were 
>>>>> added.
>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>> release notes - for such cases raw tzdata diff was used for the 
>>>>> names modifications.
>>>>>
>>>>> Two issues with JSR310 implementation were discovered during 
>>>>> integration process:
>>>>> First issue is related to the internal representation of the 
>>>>> '24:00' value. The JSR310 implementation treats this value as a 
>>>>> next day 00:00 time. The workaround already exists in JSR310 code 
>>>>> for similar entries and this failure is resolved in similar way 
>>>>> [2] as part of this update.
>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
>>>>> that fails with this tzdata.
>>>>> Other time zone related tests [4] passes without failures.
>>>>>
>>>>> Thank you,
>>>>> Aleksej
>>>>>
>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>> [2] 
>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>> test/closed/java/util/TimeZone
>>>>
>>>
>>
>


From aleksej.efimov at oracle.com  Wed Aug 27 13:53:17 2014
From: aleksej.efimov at oracle.com (Aleksej Efimov)
Date: Wed, 27 Aug 2014 17:53:17 +0400
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53FD9819.7080000@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
Message-ID: <53FDE2CD.8040709@oracle.com>

Masayoshi,
Thank you for a detailed review - I tried to address all your comments. 
Please, see the updated review: 
http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
About the workarounds - I will start discussion with Sherman when the 
tzdata2014f (and I suppose the 2014g - it will be available soon 
according to tzdata mail-list [1]) integration will be complete.

-Aleksej

[1] tzdata2014g is coming: 
http://mm.icann.org/pipermail/tz/2014-August/021528.html

On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
> Here are additional comments.
>
> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>
> I'm concerned about the workarounds. It's not new in this update, but 
> this problem would make tzupdater data void until the workaround is 
> added to the next update release. Could you please work with Sherman 
> to eliminate the workaround (outside of this 2014f update)?
>
> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>
>          String LORD_HOWE[] = new String[] {"Lord Howe Standard Time", 
> "LHST",
> -                                           "Lord Howe Summer Time", 
> "LHST",
> +                                           "Lord Howe Summer Time", 
> "LHDT",
>
> The S-D convention is applied to Lord Howe as well.
>
>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
> Island Time", "MIST",
>  568                                                    "Macquarie 
> Island Summer Time", "MIST",
>  569                                                    "Macquarie 
> Island Time", "MIST"}},
>
> This one should also follow the S-D convention, although this time 
> zone doesn't observe daylight saving time.
>
>
> +        String XJT[] = new String[] {"China Standard Time", "XJT",
> +                                     "China Daylight Time", "XJDT",
> +                                     "China Time", "XJT"};
>
> Should the long names be based on Xinjiang?
>
> Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
> same time zone.
>
> -            {"America/Metlakatla", new String[] {"Metlakatla Standard 
> Time", "MeST",
> -                                                 "Metlakatla Daylight 
> Time", "MeDT",
> -                                                 "Metlakatla Time", 
> "MeT"}},
> +            {"America/Metlakatla", new String[] {"Metlakatla Standard 
> Time", "PST",
> +                                                 "Metlakatla Daylight 
> Time", "PDT",
> +                                                 "Metlakatla Time", 
> "PT"}},
>
> -            {"Europe/Volgograd", new String[] {"Volgograd Time", "VOLT",
> -                                               "Volgograd Summer 
> Time", "VOLST",
> -                                               "Volgograd Time", 
> "VOLT"}},
> +            {"Europe/Volgograd", new String[] {"Volgograd Time", "MSK",
> +                                               "Volgograd Summer 
> Time", "MSK",
> +                                               "Volgograd Time", 
> "MSK"}},
>
>
> The long names should be changed accordingly.
>
> Thanks,
> Masayoshi
>
> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>> Masayoshi,
>> You're right that the "root names" should be changed as part of this 
>> update. The names were changed according to Australian official 
>> document here: http://australia.gov.au/about-australia/our-country/time
>> The fixed version of the webrev can be found here: 
>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>
>> Thanks,
>> Aleksej
>>
>>
>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>> We used to make name changes in the root (base) bundle as part of 
>>> time zone data maintenance and deter only translations. But if you 
>>> want to handle name changes later, that would be fine. It's your call.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>> Masayoshi,
>>>> I agree that we should change the long names to match the new short 
>>>> names introduced by tzdata.
>>>> But I suggest to log a different CR for such activity to handle 
>>>> long name changes and their translations (this activity is slightly 
>>>> out of tzdata update scope). Does it make sense?
>>>>
>>>> -Aleksej
>>>>
>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>> I think the long names of the Australia time zones should be 
>>>>> revisited to be consistent with the abbreviation changes. The new 
>>>>> abbreviations follow the S[tandard] and D[aylight saving] 
>>>>> convention rather than the S[tandard] and S[ummer time] one. The 
>>>>> long names, such as "Eastern Summer Time (Queensland)", no longer 
>>>>> make sense.
>>>>>
>>>>> On the other hand, you will need to access impact of the name 
>>>>> changes, including abbreviations. Also, if you change the long 
>>>>> names, their translations will need to be changed as well.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>> Hi,
>>>>>>
>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>
>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>> were added.
>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>>> release notes - for such cases raw tzdata diff was used for the 
>>>>>> names modifications.
>>>>>>
>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>> integration process:
>>>>>> First issue is related to the internal representation of the 
>>>>>> '24:00' value. The JSR310 implementation treats this value as a 
>>>>>> next day 00:00 time. The workaround already exists in JSR310 code 
>>>>>> for similar entries and this failure is resolved in similar way 
>>>>>> [2] as part of this update.
>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
>>>>>> that fails with this tzdata.
>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>
>>>>>> Thank you,
>>>>>> Aleksej
>>>>>>
>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>> [2] 
>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>>> test/closed/java/util/TimeZone
>>>>>
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Thu Aug 28 03:43:35 2014
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 28 Aug 2014 12:43:35 +0900
Subject:  RFR: 8049343: (tz) Support tzdata2014f
In-Reply-To: <53FDE2CD.8040709@oracle.com>
References: <53F4B7BD.8020705@oracle.com> <53F55A44.6010501@oracle.com>
	<53F5A843.3000302@oracle.com> <53F5DD2C.1010706@oracle.com>
	<53F734D8.1000801@oracle.com> <53FD9819.7080000@oracle.com>
	<53FDE2CD.8040709@oracle.com>
Message-ID: <53FEA567.9020601@oracle.com>

  src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:

  239         String SLST[] = new String[] {"Greenwich Mean Time", "GMT",
  240                                       "Sierra Leone Summer Time", "SLST",
  241                                       "Sierra Leone Time", "SLT"};

  251         String WART[] = new String[] {"Western Argentine Time", "WART",
  252                                       "Western Argentine Summer Time", "WARST",
  253                                       "Western Argentine Time", "WART"};

It seems these are no longer used.

-            {"Antarctica/Macquarie", new String[] {"Macquarie Island Time", "MIST",
-                                                   "Macquarie Island Summer Time", "MIST",
+            {"Antarctica/Macquarie", new String[] {"Macquarie Island Standard Time", "MIST",
+                                                   "Macquarie Island Daylight Time", "MIST",

The daylight saving time abbreviation should be MIDT.

Thanks,
Masayoshi

On 8/27/2014 10:53 PM, Aleksej Efimov wrote:
> Masayoshi,
> Thank you for a detailed review - I tried to address all your 
> comments. Please, see the updated review: 
> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.03
> About the workarounds - I will start discussion with Sherman when the 
> tzdata2014f (and I suppose the 2014g - it will be available soon 
> according to tzdata mail-list [1]) integration will be complete.
>
> -Aleksej
>
> [1] tzdata2014g is coming: 
> http://mm.icann.org/pipermail/tz/2014-August/021528.html
>
> On 08/27/2014 12:34 PM, Masayoshi Okutsu wrote:
>> Here are additional comments.
>>
>> src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java:
>>
>> I'm concerned about the workarounds. It's not new in this update, but 
>> this problem would make tzupdater data void until the workaround is 
>> added to the next update release. Could you please work with Sherman 
>> to eliminate the workaround (outside of this 2014f update)?
>>
>> src/java.base/share/classes/sun/util/resources/TimeZoneNames.java:
>>
>>          String LORD_HOWE[] = new String[] {"Lord Howe Standard 
>> Time", "LHST",
>> -                                           "Lord Howe Summer Time", 
>> "LHST",
>> +                                           "Lord Howe Summer Time", 
>> "LHDT",
>>
>> The S-D convention is applied to Lord Howe as well.
>>
>>  567             {"Antarctica/Macquarie", new String[] {"Macquarie 
>> Island Time", "MIST",
>>  568 "Macquarie Island Summer Time", "MIST",
>>  569 "Macquarie Island Time", "MIST"}},
>>
>> This one should also follow the S-D convention, although this time 
>> zone doesn't observe daylight saving time.
>>
>>
>> +        String XJT[] = new String[] {"China Standard Time", "XJT",
>> +                                     "China Daylight Time", "XJDT",
>> +                                     "China Time", "XJT"};
>>
>> Should the long names be based on Xinjiang?
>>
>> Africa/Freetown is now a link to Africa/Abidjan. Those should be the 
>> same time zone.
>>
>> -            {"America/Metlakatla", new String[] {"Metlakatla 
>> Standard Time", "MeST",
>> -                                                 "Metlakatla 
>> Daylight Time", "MeDT",
>> -                                                 "Metlakatla Time", 
>> "MeT"}},
>> +            {"America/Metlakatla", new String[] {"Metlakatla 
>> Standard Time", "PST",
>> +                                                 "Metlakatla 
>> Daylight Time", "PDT",
>> +                                                 "Metlakatla Time", 
>> "PT"}},
>>
>> -            {"Europe/Volgograd", new String[] {"Volgograd Time", 
>> "VOLT",
>> -                                               "Volgograd Summer 
>> Time", "VOLST",
>> -                                               "Volgograd Time", 
>> "VOLT"}},
>> +            {"Europe/Volgograd", new String[] {"Volgograd Time", "MSK",
>> +                                               "Volgograd Summer 
>> Time", "MSK",
>> +                                               "Volgograd Time", 
>> "MSK"}},
>>
>>
>> The long names should be changed accordingly.
>>
>> Thanks,
>> Masayoshi
>>
>> On 8/22/2014 9:17 PM, Aleksej Efimov wrote:
>>> Masayoshi,
>>> You're right that the "root names" should be changed as part of this 
>>> update. The names were changed according to Australian official 
>>> document here: http://australia.gov.au/about-australia/our-country/time
>>> The fixed version of the webrev can be found here: 
>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.02
>>>
>>> Thanks,
>>> Aleksej
>>>
>>>
>>> On 08/21/2014 03:51 PM, Masayoshi Okutsu wrote:
>>>> We used to make name changes in the root (base) bundle as part of 
>>>> time zone data maintenance and deter only translations. But if you 
>>>> want to handle name changes later, that would be fine. It's your call.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 8/21/2014 5:05 PM, Aleksej Efimov wrote:
>>>>> Masayoshi,
>>>>> I agree that we should change the long names to match the new 
>>>>> short names introduced by tzdata.
>>>>> But I suggest to log a different CR for such activity to handle 
>>>>> long name changes and their translations (this activity is 
>>>>> slightly out of tzdata update scope). Does it make sense?
>>>>>
>>>>> -Aleksej
>>>>>
>>>>> On 08/21/2014 06:32 AM, Masayoshi Okutsu wrote:
>>>>>> I think the long names of the Australia time zones should be 
>>>>>> revisited to be consistent with the abbreviation changes. The new 
>>>>>> abbreviations follow the S[tandard] and D[aylight saving] 
>>>>>> convention rather than the S[tandard] and S[ummer time] one. The 
>>>>>> long names, such as "Eastern Summer Time (Queensland)", no longer 
>>>>>> make sense.
>>>>>>
>>>>>> On the other hand, you will need to access impact of the name 
>>>>>> changes, including abbreviations. Also, if you change the long 
>>>>>> names, their translations will need to be changed as well.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 8/20/2014 11:59 PM, Aleksej Efimov wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> Please, review the tzdata2014f integration (with tzdata2014e 
>>>>>>> related changes included too) [1] fix to JDK9: 
>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/
>>>>>>>
>>>>>>> The tzdata2014f changes are extensive and relates mostly to 
>>>>>>> timezone short names changes + "Asia/Srednekolymsk" time zone 
>>>>>>> were added.
>>>>>>> Almost complete list of changes can be found in the JBS bug 
>>>>>>> description [1], plus some changes wasn't documented in tzdata 
>>>>>>> release notes - for such cases raw tzdata diff was used for the 
>>>>>>> names modifications.
>>>>>>>
>>>>>>> Two issues with JSR310 implementation were discovered during 
>>>>>>> integration process:
>>>>>>> First issue is related to the internal representation of the 
>>>>>>> '24:00' value. The JSR310 implementation treats this value as a 
>>>>>>> next day 00:00 time. The workaround already exists in JSR310 
>>>>>>> code for similar entries and this failure is resolved in similar 
>>>>>>> way [2] as part of this update.
>>>>>>> For the second issue JDK-8051641 [3] was filled and 
>>>>>>> 'sun/util/calendar/zi/TestZoneInfo310.java' test is the only one 
>>>>>>> that fails with this tzdata.
>>>>>>> Other time zone related tests [4] passes without failures.
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Aleksej
>>>>>>>
>>>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8049343
>>>>>>> [2] 
>>>>>>> http://cr.openjdk.java.net/~aefimov/8049343/9/webrev.01/src/java.base/share/classes/sun/util/calendar/ZoneInfoFile.java.patch
>>>>>>> [3] https://bugs.openjdk.java.net/browse/JDK-8051641
>>>>>>> [4] TZ related test sets: test/sun/util/calendar 
>>>>>>> test/java/util/Calendar test/sun/util/resources/TimeZone 
>>>>>>> test/sun/util/calendar test/java/util/TimeZone test/java/time\ 
>>>>>>> test/java/util/Formatter test/closed/java/util/Calendar 
>>>>>>> test/closed/java/util/TimeZone
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Thu Aug 28 18:34:12 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 28 Aug 2014 11:34:12 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53F79013.9030607@oracle.com>
References: <53F79013.9030607@oracle.com>
Message-ID: <53FF7624.2020508@oracle.com>

Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the 
changes based on your suggestions as follows:

http://cr.openjdk.java.net/~naoto/8038436/webrev.4/

Here are the changes since webrev.3

- CLDRLocaleProviderAdapter.java: modified to throw 
UnsupportedOperationException with the actual exception set to its 
"cause." More descriptive comment on it.

- *ProviderImpl.java: Removed changes to them. Initial thought was to 
make them performant by changing the langtags to static, but it turned 
out that wasn't necessary.

- JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed 
to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for 
readability. String constants are wrapped for readability as well. Used 
getOrDefault() for getSupportedLocaleString().

- Added test cases for SecurityException and JRE's supported locales for 
each service.

I'd appreciate it if someone in the build-dev could review the makefile 
changes.

Naoto

On 8/22/14, 11:46 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8038436
>
> The proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>
> The idea is to introduce an SPI so that supported locales are
> dynamically searched at runtime, not depending on the existence of
> physical jar files.
>
> I'd appreciate it if build folks could review the makefile related
> changes, i18n forks to review locale framework files, and Mandy from
> modularization point of view.
>
> Naoto

From mandy.chung at oracle.com  Fri Aug 29 00:11:05 2014
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 28 Aug 2014 17:11:05 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53FF7624.2020508@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
Message-ID: <53FFC519.6070100@oracle.com>

Naoto,

This looks better.  Thanks for the update.

The getSupportedLocaleString method in both EnLocaleDataMetaInfo and 
NonEnLocaleDataMetaInfo has the javadoc that missing the description.

sun.util.locale.provider is a package in java.base and 
NonEnLocaleDataMetaInfo has to be in a different package as it's in the 
jdk.localedata

Previously the list of locales was generated at build time. 
NonEnLocaleDataMetaInfo now hardcodes the list in the source.  How often 
do we need to update this list?  Just wonder whether there is a better 
way to maintain this list and catch regression.  You have a new test  
Bug8038436.java to compare the golden list which is good.  However, the 
golden list is hardcoded too that seems to be error-prone.  Does 
Bug8038436.java pass with jdk9?

The current source layout implies the jdk.localedata module contains 
both cldr and localedata while they are generated as two separate JAR 
files in the jdk image.  Would you propose to split CLDR out as 
jdk.cldrdata?  Currently you have two service config files providing the 
same service type and leads to the awkward location.

If they should be kept under jdk.localedata, we could live with the two 
service config files until the modular image is in place.

I would suggest renaming
src/jdk.localedata/share/classes/sun/util/cldr/sun.util.locale.provider.LocaleDataMetaInfo
   -> 
src/jdk.localedata/META-INF/cldrdata-services/sun.util.locale.provider.LocaleDataMetaInfo

src/jdk.localedata/share/classes/sun/util/locale/provider/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo
   -> 
src/jdk.localedata/META-INF/localedata-services/sun.util.locale.provider.LocaleDataMetaInfo

Mandy

On 8/28/14 11:34 AM, Naoto Sato wrote:
> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the 
> changes based on your suggestions as follows:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
>
> Here are the changes since webrev.3
>
> - CLDRLocaleProviderAdapter.java: modified to throw 
> UnsupportedOperationException with the actual exception set to its 
> "cause." More descriptive comment on it.
>
> - *ProviderImpl.java: Removed changes to them. Initial thought was to 
> make them performant by changing the langtags to static, but it turned 
> out that wasn't necessary.
>
> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: 
> Renamed to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo 
> respectively for readability. String constants are wrapped for 
> readability as well. Used getOrDefault() for getSupportedLocaleString().
>
> - Added test cases for SecurityException and JRE's supported locales 
> for each service.
>
> I'd appreciate it if someone in the build-dev could review the 
> makefile changes.
>
> Naoto
>
> On 8/22/14, 11:46 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038436
>>
>> The proposed changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>>
>> The idea is to introduce an SPI so that supported locales are
>> dynamically searched at runtime, not depending on the existence of
>> physical jar files.
>>
>> I'd appreciate it if build folks could review the makefile related
>> changes, i18n forks to review locale framework files, and Mandy from
>> modularization point of view.
>>
>> Naoto


From yong.huang at oracle.com  Fri Aug 29 07:47:51 2014
From: yong.huang at oracle.com (Yong Huang)
Date: Fri, 29 Aug 2014 15:47:51 +0800
Subject:  [9] Review Request - JDK-8055222: ISO 4217 Amendment #159
Message-ID: <54003027.1080405@oracle.com>

Hello,

Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8055222

Webrev: http://cr.openjdk.java.net/~yhuang/8055222/webrev.00/

thanks,
Yong

From Alan.Bateman at oracle.com  Fri Aug 29 13:29:00 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 29 Aug 2014 14:29:00 +0100
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53FF7624.2020508@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
Message-ID: <5400801C.1030406@oracle.com>

On 28/08/2014 19:34, Naoto Sato wrote:
> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the 
> changes based on your suggestions as follows:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
>
> Here are the changes since webrev.3
>
> - CLDRLocaleProviderAdapter.java: modified to throw 
> UnsupportedOperationException with the actual exception set to its 
> "cause." More descriptive comment on it.
>
> - *ProviderImpl.java: Removed changes to them. Initial thought was to 
> make them performant by changing the langtags to static, but it turned 
> out that wasn't necessary.
>
> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: 
> Renamed to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo 
> respectively for readability. String constants are wrapped for 
> readability as well. Used getOrDefault() for getSupportedLocaleString().
>
> - Added test cases for SecurityException and JRE's supported locales 
> for each service.
>
> I'd appreciate it if someone in the build-dev could review the 
> makefile changes.
I looked through the updated webrev and it looks much better (and much 
easier to review too).

I assume CLDRLocaleProviderAdapter.metaInfo should be final.

I'm still not sure about CLDRLocaleProviderAdapter throwing UOE when 
iterating over the installed LocaleDataMetaInfo implementations fail. It 
almost feels like it should be an InternalError as it could only mean 
something wrong with the JDK code or something broken in the JDK 
installation. I have the same concern in 
JRELocaleProviderAdapter.createSupportedLocaleString where it would be 
even more difficult to diagnose why non-English locales appear to be 
missing.

Typo in JRELocaleProviderAdapter, installede -> installed.

I see Mandy has pointed out the location of the services configuration 
files, it would be good to check into that.

Otherwise I think this looks reasonable, you've addressed the comments I 
had in the original webrev.

-Alan.



From naoto.sato at oracle.com  Fri Aug 29 20:08:54 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 29 Aug 2014 13:08:54 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53FFC519.6070100@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
	<53FFC519.6070100@oracle.com>
Message-ID: <5400DDD6.9060402@oracle.com>

On 8/28/14, 5:11 PM, Mandy Chung wrote:
> Naoto,
>
> This looks better.  Thanks for the update.
>
> The getSupportedLocaleString method in both EnLocaleDataMetaInfo and
> NonEnLocaleDataMetaInfo has the javadoc that missing the description.
>
> sun.util.locale.provider is a package in java.base and
> NonEnLocaleDataMetaInfo has to be in a different package as it's in the
> jdk.localedata
>
> Previously the list of locales was generated at build time.
> NonEnLocaleDataMetaInfo now hardcodes the list in the source.  How often
> do we need to update this list?  Just wonder whether there is a better
> way to maintain this list and catch regression.  You have a new test
> Bug8038436.java to compare the golden list which is good.  However, the
> golden list is hardcoded too that seems to be error-prone.  Does
> Bug8038436.java pass with jdk9?

JRE's locale data will be just in maintenance mode as CLDR will become 
the defualt, so it won't change much, and the test case does pass with jdk9.

Having said that, I just reverted to the dynamic list generation at the 
build time. Just leave the test case though.

I will address your other suggestions in the next revision.

Naoto

>
> The current source layout implies the jdk.localedata module contains
> both cldr and localedata while they are generated as two separate JAR
> files in the jdk image.  Would you propose to split CLDR out as
> jdk.cldrdata?  Currently you have two service config files providing the
> same service type and leads to the awkward location.
>
> If they should be kept under jdk.localedata, we could live with the two
> service config files until the modular image is in place.
>
> I would suggest renaming
> src/jdk.localedata/share/classes/sun/util/cldr/sun.util.locale.provider.LocaleDataMetaInfo
>    ->
> src/jdk.localedata/META-INF/cldrdata-services/sun.util.locale.provider.LocaleDataMetaInfo
>
> src/jdk.localedata/share/classes/sun/util/locale/provider/META-INF/services/sun.util.locale.provider.LocaleDataMetaInfo
>    ->
> src/jdk.localedata/META-INF/localedata-services/sun.util.locale.provider.LocaleDataMetaInfo
>
> Mandy
>
> On 8/28/14 11:34 AM, Naoto Sato wrote:
>> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
>> changes based on your suggestions as follows:
>>
>> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
>>
>> Here are the changes since webrev.3
>>
>> - CLDRLocaleProviderAdapter.java: modified to throw
>> UnsupportedOperationException with the actual exception set to its
>> "cause." More descriptive comment on it.
>>
>> - *ProviderImpl.java: Removed changes to them. Initial thought was to
>> make them performant by changing the langtags to static, but it turned
>> out that wasn't necessary.
>>
>> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java:
>> Renamed to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo
>> respectively for readability. String constants are wrapped for
>> readability as well. Used getOrDefault() for getSupportedLocaleString().
>>
>> - Added test cases for SecurityException and JRE's supported locales
>> for each service.
>>
>> I'd appreciate it if someone in the build-dev could review the
>> makefile changes.
>>
>> Naoto
>>
>> On 8/22/14, 11:46 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the following issue:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8038436
>>>
>>> The proposed changes are located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>>>
>>> The idea is to introduce an SPI so that supported locales are
>>> dynamically searched at runtime, not depending on the existence of
>>> physical jar files.
>>>
>>> I'd appreciate it if build folks could review the makefile related
>>> changes, i18n forks to review locale framework files, and Mandy from
>>> modularization point of view.
>>>
>>> Naoto
>

From naoto.sato at oracle.com  Fri Aug 29 20:15:17 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 29 Aug 2014 13:15:17 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <5400801C.1030406@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
	<5400801C.1030406@oracle.com>
Message-ID: <5400DF55.409@oracle.com>

On 8/29/14, 6:29 AM, Alan Bateman wrote:
>
> I'm still not sure about CLDRLocaleProviderAdapter throwing UOE when
> iterating over the installed LocaleDataMetaInfo implementations fail. It
> almost feels like it should be an InternalError as it could only mean
> something wrong with the JDK code or something broken in the JDK
> installation.

This can happen when the user mistakenly specify java.locale.providers 
with CLDR on a profile without CLDR's locale data installed, such as 
compact ones in JDK8.

> I have the same concern in
> JRELocaleProviderAdapter.createSupportedLocaleString where it would be
> even more difficult to diagnose why non-English locales appear to be
> missing.

It would be desirable to have some kind of better diagnose mechanism, 
but I think that would be an enhancement and out of the scope for this CR.

Will address other suggestions in the next webrev.

Naoto

From naoto.sato at oracle.com  Fri Aug 29 21:07:07 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 29 Aug 2014 14:07:07 -0700
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <53FF7624.2020508@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
Message-ID: <5400EB7B.1050303@oracle.com>

I incorporated the suggestions from Mandy and Alan. Also one change 
since the last webrev was to revert the hard-coding of the supported 
locales list back to the one which dynamically generates the lists at 
the build time. I initially thought static listing of locales would be 
less complex as to the build script/makefile, but on second thought it's 
less evil than possible future regressions.

Please review:
http://cr.openjdk.java.net/~naoto/8038436/webrev.5/

Naoto

On 8/28/14, 11:34 AM, Naoto Sato wrote:
> Thank you, Mandy, Masayoshi, and Alan for your comments. I revised the
> changes based on your suggestions as follows:
>
> http://cr.openjdk.java.net/~naoto/8038436/webrev.4/
>
> Here are the changes since webrev.3
>
> - CLDRLocaleProviderAdapter.java: modified to throw
> UnsupportedOperationException with the actual exception set to its
> "cause." More descriptive comment on it.
>
> - *ProviderImpl.java: Removed changes to them. Initial thought was to
> make them performant by changing the langtags to static, but it turned
> out that wasn't necessary.
>
> - JREENLocaleDataMetaInfo.java/JRENonENLocaleDataMetaInfo.java: Renamed
> to EnLocaleDataMetaInfo and NonEnLocaleDataMetaInfo respectively for
> readability. String constants are wrapped for readability as well. Used
> getOrDefault() for getSupportedLocaleString().
>
> - Added test cases for SecurityException and JRE's supported locales for
> each service.
>
> I'd appreciate it if someone in the build-dev could review the makefile
> changes.
>
> Naoto
>
> On 8/22/14, 11:46 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8038436
>>
>> The proposed changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8038436/webrev.3/
>>
>> The idea is to introduce an SPI so that supported locales are
>> dynamically searched at runtime, not depending on the existence of
>> physical jar files.
>>
>> I'd appreciate it if build folks could review the makefile related
>> changes, i18n forks to review locale framework files, and Mandy from
>> modularization point of view.
>>
>> Naoto

From naoto.sato at oracle.com  Fri Aug 29 21:48:10 2014
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 29 Aug 2014 14:48:10 -0700
Subject:  [9] Review Request - JDK-8055222: ISO 4217 Amendment
 #159
In-Reply-To: <54003027.1080405@oracle.com>
References: <54003027.1080405@oracle.com>
Message-ID: <5400F51A.7000907@oracle.com>

Hi Yong,

The amendment also mentions to the name change "Cape Verde" -> "Cabo 
Verde." Should the change also include it?

Naoto

On 8/29/14, 12:47 AM, Yong Huang wrote:
> Hello,
>
> Please review the fix for https://bugs.openjdk.java.net/browse/JDK-8055222
>
> Webrev: http://cr.openjdk.java.net/~yhuang/8055222/webrev.00/
>
> thanks,
> Yong

From Alan.Bateman at oracle.com  Sat Aug 30 12:47:50 2014
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 30 Aug 2014 13:47:50 +0100
Subject:  [9] RFR 8038436: Re-examine the mechanism to
 determine available localedata and cldrdata
In-Reply-To: <5400EB7B.1050303@oracle.com>
References: <53F79013.9030607@oracle.com> <53FF7624.2020508@oracle.com>
	<5400EB7B.1050303@oracle.com>
Message-ID: <5401C7F6.9010804@oracle.com>

On 29/08/2014 22:07, Naoto Sato wrote:
> I incorporated the suggestions from Mandy and Alan. Also one change 
> since the last webrev was to revert the hard-coding of the supported 
> locales list back to the one which dynamically generates the lists at 
> the build time. I initially thought static listing of locales would be 
> less complex as to the build script/makefile, but on second thought 
> it's less evil than possible future regressions.
>
> Please review:
> http://cr.openjdk.java.net/~naoto/8038436/webrev.5/
>
I think this looks okay and I assume you'll create another issue to 
re-examine the error handling as I do think that does need to be looked 
at again (my main concern is that it will silently failover and that 
could be very hard to diagnose).

One comment on the test Bug8038436 is that it sets java.ext.dirs on the 
assumption that the locale and cldr data wouldn't be found. I suspect 
this will need to be re-worked once we get to the point of linking 
modules into the image. It may be that the ext directory is empty by 
default (localdata.jar and cldrdata.jar will not exist).

-Alan.