From masayoshi.okutsu at oracle.com  Tue Oct  2 22:02:12 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 03 Oct 2012 14:02:12 +0900
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can
 not be invoked when region code is specified in Locale
In-Reply-To: <505B97E4.7000805@oracle.com>
References: <504E7CAD.2010800@oracle.com> <505104BF.5090501@oracle.com>
	<505B97E4.7000805@oracle.com>
Message-ID: <506BC6D4.4000000@oracle.com>

Hi Naoto,

Here are my comments.

LocaleProviderAdapter.java:

- After parsing the java.locale.providers value, if typeList is empty, 
the default list (JRE,SPI) should be used.

- I don't think the following lines are necessary in getAdapter().

Otherwise, the fix looks good to me.

Thanks,
Masayoshi

On 9/21/2012 7:25 AM, Naoto Sato wrote:
> I revised the fix again to catch up with the internal comments, i.e., 
> correcting the behavior when a bogus adapter is specified, it won't 
> fall back to JRE locale data. The revised webrev is located here:
>
> http://cr.openjdk.java.net/~naoto/7196799/webrev.02/
>
> Naoto
>
> On 9/12/12 2:55 PM, Naoto Sato wrote:
>> I updated the webrev to include another fix to a test bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197573
>>
>> Since the fix is to correct some wrong assumption on the platform
>> default locale in the same test case with 7196799, I just combined two
>> fixes in one changeset. The code changes for 7197573 remain intact.
>>
>> The combined new webrev is located at:
>>
>> http://cr.openjdk.java.net/~naoto/7196799/webrev.01/
>>
>> Naoto
>>
>> On 9/10/12 4:50 PM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the proposed fix for the subject bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799
>>>
>>> The webrev for the fix is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.00/
>>>
>>> The fix is basically limit the implicit fallback to JRE's locale data
>>> only for the root locale, in order to honor the CLDR's fallback.
>>>
>>> Naoto
>>
>


From naoto.sato at oracle.com  Wed Oct  3 11:08:19 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 03 Oct 2012 11:08:19 -0700
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can
 not be invoked when region code is specified in Locale
In-Reply-To: <506BC6D4.4000000@oracle.com>
References: <504E7CAD.2010800@oracle.com> <505104BF.5090501@oracle.com>
	<505B97E4.7000805@oracle.com> <506BC6D4.4000000@oracle.com>
Message-ID: <506C7F13.9090709@oracle.com>

Hi Masayoshi,

Thank you for the review. I updated LocaleProviderAdapter.java according 
to your comments. Also I fixed two instances of "if (locale == 
Locale.ROOT)" statements in LocaleProviderAdapter.java and 
CalendarDataProviderImpl.java (this is irrelevant to the bug, but fixed 
it anyway for precaution).

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

Naoto

On 10/2/12 10:02 PM, Masayoshi Okutsu wrote:
> Hi Naoto,
>
> Here are my comments.
>
> LocaleProviderAdapter.java:
>
> - After parsing the java.locale.providers value, if typeList is empty,
> the default list (JRE,SPI) should be used.
>
> - I don't think the following lines are necessary in getAdapter().
>
> Otherwise, the fix looks good to me.
>
> Thanks,
> Masayoshi
>
> On 9/21/2012 7:25 AM, Naoto Sato wrote:
>> I revised the fix again to catch up with the internal comments, i.e.,
>> correcting the behavior when a bogus adapter is specified, it won't
>> fall back to JRE locale data. The revised webrev is located here:
>>
>> http://cr.openjdk.java.net/~naoto/7196799/webrev.02/
>>
>> Naoto
>>
>> On 9/12/12 2:55 PM, Naoto Sato wrote:
>>> I updated the webrev to include another fix to a test bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197573
>>>
>>> Since the fix is to correct some wrong assumption on the platform
>>> default locale in the same test case with 7196799, I just combined two
>>> fixes in one changeset. The code changes for 7197573 remain intact.
>>>
>>> The combined new webrev is located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.01/
>>>
>>> Naoto
>>>
>>> On 9/10/12 4:50 PM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the proposed fix for the subject bug:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799
>>>>
>>>> The webrev for the fix is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.00/
>>>>
>>>> The fix is basically limit the implicit fallback to JRE's locale data
>>>> only for the root locale, in order to honor the CLDR's fallback.
>>>>
>>>> Naoto
>>>
>>
>


From masayoshi.okutsu at oracle.com  Thu Oct  4 01:36:53 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 04 Oct 2012 17:36:53 +0900
Subject: <i18n dev> [8] Review request for CR 7196799: CLDR adapter can
 not be invoked when region code is specified in Locale
In-Reply-To: <506C7F13.9090709@oracle.com>
References: <504E7CAD.2010800@oracle.com> <505104BF.5090501@oracle.com>
	<505B97E4.7000805@oracle.com> <506BC6D4.4000000@oracle.com>
	<506C7F13.9090709@oracle.com>
Message-ID: <506D4AA5.8080604@oracle.com>

Looks good to me.

Masayoshi

On 10/4/2012 3:08 AM, Naoto Sato wrote:
> Hi Masayoshi,
>
> Thank you for the review. I updated LocaleProviderAdapter.java 
> according to your comments. Also I fixed two instances of "if (locale 
> == Locale.ROOT)" statements in LocaleProviderAdapter.java and 
> CalendarDataProviderImpl.java (this is irrelevant to the bug, but 
> fixed it anyway for precaution).
>
> http://cr.openjdk.java.net/~naoto/7196799/webrev.03/
>
> Naoto
>
> On 10/2/12 10:02 PM, Masayoshi Okutsu wrote:
>> Hi Naoto,
>>
>> Here are my comments.
>>
>> LocaleProviderAdapter.java:
>>
>> - After parsing the java.locale.providers value, if typeList is empty,
>> the default list (JRE,SPI) should be used.
>>
>> - I don't think the following lines are necessary in getAdapter().
>>
>> Otherwise, the fix looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 9/21/2012 7:25 AM, Naoto Sato wrote:
>>> I revised the fix again to catch up with the internal comments, i.e.,
>>> correcting the behavior when a bogus adapter is specified, it won't
>>> fall back to JRE locale data. The revised webrev is located here:
>>>
>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.02/
>>>
>>> Naoto
>>>
>>> On 9/12/12 2:55 PM, Naoto Sato wrote:
>>>> I updated the webrev to include another fix to a test bug:
>>>>
>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7197573
>>>>
>>>> Since the fix is to correct some wrong assumption on the platform
>>>> default locale in the same test case with 7196799, I just combined two
>>>> fixes in one changeset. The code changes for 7197573 remain intact.
>>>>
>>>> The combined new webrev is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.01/
>>>>
>>>> Naoto
>>>>
>>>> On 9/10/12 4:50 PM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the proposed fix for the subject bug:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196799
>>>>>
>>>>> The webrev for the fix is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/7196799/webrev.00/
>>>>>
>>>>> The fix is basically limit the implicit fallback to JRE's locale data
>>>>> only for the root locale, in order to honor the CLDR's fallback.
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Thu Oct  4 14:40:11 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 04 Oct 2012 14:40:11 -0700
Subject: <i18n dev> [8]Review request for 7200119:
 Collator.getAvailableLocales() doesn't return Locale.US
Message-ID: <506E023B.2010101@oracle.com>

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200119

Proposed changes are located at:

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

This is just to add "en-US" to all the locale sensitive services, as it 
is defined in the spec.

Naoto

From naoto.sato at oracle.com  Thu Oct  4 14:44:36 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 04 Oct 2012 14:44:36 -0700
Subject: <i18n dev> [8]Review request for 7200341:
 DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some
 circumstances
Message-ID: <506E0344.20800@oracle.com>

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200341

Proposed changes are located at:

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

The fix is to re-implement hashCode() correctly. It now also takes all 
the fields into consideration for hash code calculation.

Naoto

From naoto.sato at oracle.com  Thu Oct  4 14:51:11 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 04 Oct 2012 14:51:11 -0700
Subject: <i18n dev> [8]Review request for 7198834: HOST Adapter: one extra
 empty space in the end of the pattern string
Message-ID: <506E04CF.1050302@oracle.com>

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198834

Proposed changes are located at:

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

The fix is just to not leave one space at the end of format string. Also 
corrected a typo in JRELocaleProviderAdapter.java

Naoto

From masayoshi.okutsu at oracle.com  Thu Oct  4 19:27:23 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 05 Oct 2012 11:27:23 +0900
Subject: <i18n dev> [8]Review request for 7200119:
 Collator.getAvailableLocales() doesn't return Locale.US
In-Reply-To: <506E023B.2010101@oracle.com>
References: <506E023B.2010101@oracle.com>
Message-ID: <506E458B.8070708@oracle.com>

Looks good.

Masayoshi

On 10/5/2012 6:40 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200119
>
> Proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/7200119/webrev.00/
>
> This is just to add "en-US" to all the locale sensitive services, as 
> it is defined in the spec.
>
> Naoto


From masayoshi.okutsu at oracle.com  Thu Oct  4 22:36:27 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 05 Oct 2012 14:36:27 +0900
Subject: <i18n dev> [8]Review request for 7200341:
 DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some
 circumstances
In-Reply-To: <506E0344.20800@oracle.com>
References: <506E0344.20800@oracle.com>
Message-ID: <506E71DB.5090803@oracle.com>

The fix will have a problem when called by multiple threads. Strictly 
speaking, DateFormatSymbols isn't thread-safe, but the usage of 
cachedHashCode will have a problem even with no set* calls.

I'd suggest the following.

    int hashCode =cachedHashCode;
    if (hashCode == 0) {
        ...
        cachedHashCode = hashCode;
    }
    return hashCode;

And cachedHashCode needs to be volatile. And when a DateFormatSymbols is 
mutated, the cachedHashCode value needs to be reset.

Masayoshi

On 10/5/2012 6:44 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200341
>
> Proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/7200341/webrev.00/
>
> The fix is to re-implement hashCode() correctly. It now also takes all 
> the fields into consideration for hash code calculation.
>
> Naoto


From masayoshi.okutsu at oracle.com  Fri Oct  5 01:16:37 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 05 Oct 2012 17:16:37 +0900
Subject: <i18n dev> [8]Review request for 7198834: HOST Adapter: one
 extra empty space in the end of the pattern string
In-Reply-To: <506E04CF.1050302@oracle.com>
References: <506E04CF.1050302@oracle.com>
Message-ID: <506E9765.6040607@oracle.com>

Looks good.

Masayoshi

On 10/5/2012 6:51 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7198834
>
> Proposed changes are located at:
>
> http://cr.openjdk.java.net/~naoto/7198834/webrev.00/
>
> The fix is just to not leave one space at the end of format string. 
> Also corrected a typo in JRELocaleProviderAdapter.java
>
> Naoto


From sean.coffey at oracle.com  Fri Oct  5 09:31:37 2012
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Fri, 05 Oct 2012 17:31:37 +0100
Subject: <i18n dev> RFF : 7196533 : TimeZone.getDefault() slow due to
 synchronization bottleneck
Message-ID: <506F0B69.1050409@oracle.com>

Recent changes in java.util.TimeZone created new setter and getter 
methods for setting and obtaining the defaultTimeZone for VM.

Synchronization on these methods has caused some performance issues for 
VMs making heavy usage of TimeZone.getDefault()

Fix is to remove synchronization and make the mainAppContextDefault 
variable volatile.

webrev : http://cr.openjdk.java.net/~coffeys/webrev.7196533.jdk8/ 
<http://cr.openjdk.java.net/%7Ecoffeys/webrev.7196533.jdk8/>
bug report : http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7196533

regards,
Sean.

From naoto.sato at oracle.com  Fri Oct  5 11:13:46 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 05 Oct 2012 11:13:46 -0700
Subject: <i18n dev> [8]Review request for 7200341:
 DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some
 circumstances
In-Reply-To: <506E71DB.5090803@oracle.com>
References: <506E0344.20800@oracle.com> <506E71DB.5090803@oracle.com>
Message-ID: <506F235A.1070901@oracle.com>

Thanks. I modified the fix according to your comments. The new webrev is 
located at:

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

Please review.

Naoto

On 10/4/12 10:36 PM, Masayoshi Okutsu wrote:
> The fix will have a problem when called by multiple threads. Strictly
> speaking, DateFormatSymbols isn't thread-safe, but the usage of
> cachedHashCode will have a problem even with no set* calls.
>
> I'd suggest the following.
>
>     int hashCode =cachedHashCode;
>     if (hashCode == 0) {
>         ...
>         cachedHashCode = hashCode;
>     }
>     return hashCode;
>
> And cachedHashCode needs to be volatile. And when a DateFormatSymbols is
> mutated, the cachedHashCode value needs to be reset.
>
> Masayoshi
>
> On 10/5/2012 6:44 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200341
>>
>> Proposed changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/7200341/webrev.00/
>>
>> The fix is to re-implement hashCode() correctly. It now also takes all
>> the fields into consideration for hash code calculation.
>>
>> Naoto
>


From masayoshi.okutsu at oracle.com  Mon Oct  8 23:06:01 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 09 Oct 2012 15:06:01 +0900
Subject: <i18n dev> [8]Review request for 7200341:
 DateFormatSymbols.hashCode() throws ArrayIndexOutOfBoundsException in some
 circumstances
In-Reply-To: <506F235A.1070901@oracle.com>
References: <506E0344.20800@oracle.com> <506E71DB.5090803@oracle.com>
	<506F235A.1070901@oracle.com>
Message-ID: <5073BEC9.9020805@oracle.com>

Looks good.

Masayoshi

On 10/6/2012 3:13 AM, Naoto Sato wrote:
> Thanks. I modified the fix according to your comments. The new webrev 
> is located at:
>
> http://cr.openjdk.java.net/~naoto/7200341/webrev.01/
>
> Please review.
>
> Naoto
>
> On 10/4/12 10:36 PM, Masayoshi Okutsu wrote:
>> The fix will have a problem when called by multiple threads. Strictly
>> speaking, DateFormatSymbols isn't thread-safe, but the usage of
>> cachedHashCode will have a problem even with no set* calls.
>>
>> I'd suggest the following.
>>
>>     int hashCode =cachedHashCode;
>>     if (hashCode == 0) {
>>         ...
>>         cachedHashCode = hashCode;
>>     }
>>     return hashCode;
>>
>> And cachedHashCode needs to be volatile. And when a DateFormatSymbols is
>> mutated, the cachedHashCode value needs to be reset.
>>
>> Masayoshi
>>
>> On 10/5/2012 6:44 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the fix for the following bug:
>>>
>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7200341
>>>
>>> Proposed changes are located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/7200341/webrev.00/
>>>
>>> The fix is to re-implement hashCode() correctly. It now also takes all
>>> the fields into consideration for hash code calculation.
>>>
>>> Naoto
>>
>


From naoto.sato at oracle.com  Thu Oct 11 14:45:13 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 11 Oct 2012 14:45:13 -0700
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
Message-ID: <50773DE9.5000505@oracle.com>

Hello,

Please review the changes for the subject bugs:

8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) 
doesn't work as expected with custom extensions
8000273: java.util.Locale.getDisplayVariant(Locale l) isn't transferred 
to the custom service provider
8000615: JRE adapter: timezone name of en_US is changed when extension 
directory is added

All of these bugs are regressions caused by the JEP 127 change, where 
locale providers are invoked not with the originally requested locale. 
Now it is invoked with the original locale as in 
LocaleServiceProviderPool.java. With this change, resource bundle locale 
check in JRE's 
LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider 
implementations are no longer needed.

The webrev for these changes are located at:

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

Naoto

From masayoshi.okutsu at oracle.com  Sun Oct 14 12:14:33 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 15 Oct 2012 04:14:33 +0900
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
In-Reply-To: <50773DE9.5000505@oracle.com>
References: <50773DE9.5000505@oracle.com>
Message-ID: <507B0F19.6080505@oracle.com>

Here are my comments.

LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:

- pool is no longer used and should be removed.

- Should contains(key) be retained? It should be faster than try-catch.

Otherwise, the fix looks good to me.

Thanks,
Masayoshi

On 10/12/2012 6:45 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the subject bugs:
>
> 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition) 
> doesn't work as expected with custom extensions
> 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't 
> transferred to the custom service provider
> 8000615: JRE adapter: timezone name of en_US is changed when extension 
> directory is added
>
> All of these bugs are regressions caused by the JEP 127 change, where 
> locale providers are invoked not with the originally requested locale. 
> Now it is invoked with the original locale as in 
> LocaleServiceProviderPool.java. With this change, resource bundle 
> locale check in JRE's 
> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider 
> implementations are no longer needed.
>
> The webrev for these changes are located at:
>
> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.00/
>
> Naoto


From Alan.Bateman at oracle.com  Mon Oct 15 09:05:25 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 15 Oct 2012 17:05:25 +0100
Subject: <i18n dev> Do developers or end-users create currency.properties?
Message-ID: <507C3445.2060208@oracle.com>


As part of preparing for modules in the future [1], we need to look at 
configuration (and other) files in the JDK and see whether such files 
could eventually move to module-private locations.

The Currency classes allows people to override the currency data that 
comes with the JDK by creating the 
file${java.home}/lib/currency.properties. I'm interested to know if this 
is actually used, and if so, is it commonly used. In general then 
creating or configuring files that are located in the JDK images is 
problematic as such changes are lost when switching JDK images. I've 
come across cases where folks have put in sym links into the JDK image 
for time zone data, I'm curious if anyone has come across this for 
currency data too.

Thanks,

-Alan

[1] http://openjdk.java.net/jeps/162




From naoto.sato at oracle.com  Mon Oct 15 12:03:58 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 15 Oct 2012 12:03:58 -0700
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
In-Reply-To: <507B0F19.6080505@oracle.com>
References: <50773DE9.5000505@oracle.com> <507B0F19.6080505@oracle.com>
Message-ID: <507C5E1E.6070506@oracle.com>

Thanks, Masayoshi, for the review. I removed that 'pool'. As to 
"contains(key)", it has to be removed so that ResourceBundle's fallback 
should occur with the requested locale. In fact, those try-catch would 
never be used for normal keys because JRE/CLDR root bundles contain all 
the defaults.

Here is the updated webrev:

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

Naoto
On 10/14/12 12:14 PM, Masayoshi Okutsu wrote:
> Here are my comments.
>
> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:
>
> - pool is no longer used and should be removed.
>
> - Should contains(key) be retained? It should be faster than try-catch.
>
> Otherwise, the fix looks good to me.
>
> Thanks,
> Masayoshi
>
> On 10/12/2012 6:45 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the subject bugs:
>>
>> 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition)
>> doesn't work as expected with custom extensions
>> 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't
>> transferred to the custom service provider
>> 8000615: JRE adapter: timezone name of en_US is changed when extension
>> directory is added
>>
>> All of these bugs are regressions caused by the JEP 127 change, where
>> locale providers are invoked not with the originally requested locale.
>> Now it is invoked with the original locale as in
>> LocaleServiceProviderPool.java. With this change, resource bundle
>> locale check in JRE's
>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider
>> implementations are no longer needed.
>>
>> The webrev for these changes are located at:
>>
>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.00/
>>
>> Naoto
>


From naoto.sato at oracle.com  Mon Oct 15 23:49:13 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 15 Oct 2012 23:49:13 -0700
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
In-Reply-To: <507C5E1E.6070506@oracle.com>
References: <50773DE9.5000505@oracle.com> <507B0F19.6080505@oracle.com>
	<507C5E1E.6070506@oracle.com>
Message-ID: <507D0369.3010101@oracle.com>

Since CLDR may not have all the defaults on the root bundle, I changed 
the fix to use ResourceBundle.containsKey() method which guarantees to 
look for the key including its parent bundles. Also changed 
OpenListResourceBundle to ResourceBundle, since it is no longer needed. 
Here is the latest webrev:

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

Naoto

On 10/15/12 12:03 PM, Naoto Sato wrote:
> Thanks, Masayoshi, for the review. I removed that 'pool'. As to
> "contains(key)", it has to be removed so that ResourceBundle's fallback
> should occur with the requested locale. In fact, those try-catch would
> never be used for normal keys because JRE/CLDR root bundles contain all
> the defaults.
>
> Here is the updated webrev:
>
> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.01/
>
> Naoto
> On 10/14/12 12:14 PM, Masayoshi Okutsu wrote:
>> Here are my comments.
>>
>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:
>>
>> - pool is no longer used and should be removed.
>>
>> - Should contains(key) be retained? It should be faster than try-catch.
>>
>> Otherwise, the fix looks good to me.
>>
>> Thanks,
>> Masayoshi
>>
>> On 10/12/2012 6:45 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the subject bugs:
>>>
>>> 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition)
>>> doesn't work as expected with custom extensions
>>> 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't
>>> transferred to the custom service provider
>>> 8000615: JRE adapter: timezone name of en_US is changed when extension
>>> directory is added
>>>
>>> All of these bugs are regressions caused by the JEP 127 change, where
>>> locale providers are invoked not with the originally requested locale.
>>> Now it is invoked with the original locale as in
>>> LocaleServiceProviderPool.java. With this change, resource bundle
>>> locale check in JRE's
>>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider
>>> implementations are no longer needed.
>>>
>>> The webrev for these changes are located at:
>>>
>>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.00/
>>>
>>> Naoto
>>
>


From Alan.Bateman at oracle.com  Tue Oct 16 06:05:06 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 16 Oct 2012 14:05:06 +0100
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <507C3445.2060208@oracle.com>
References: <507C3445.2060208@oracle.com>
Message-ID: <507D5B82.7060902@oracle.com>

On 15/10/2012 17:05, Alan Bateman wrote:
>
> As part of preparing for modules in the future [1], we need to look at 
> configuration (and other) files in the JDK and see whether such files 
> could eventually move to module-private locations.
>
> The Currency classes allows people to override the currency data that 
> comes with the JDK by creating the file 
> ${java.home}/lib/currency.properties. I'm interested to know if this 
> is actually used, and if so, is it commonly used. In general then 
> creating or configuring files that are located in the JDK images is 
> problematic as such changes are lost when switching JDK images. I've 
> come across cases where folks have put in sym links into the JDK image 
> for time zone data, I'm curious if anyone has come across this for 
> currency data too.
>
One other question on this topic is whether a system property or some 
other means to specify the location of a currency properties file to 
override the currency data was considered during 6332666. Although 
system properties aren't always the best solution it would at least 
allow someone to maintain their own currency file in a location that is 
immune from JDK updates.

-Alan

From masayoshi.okutsu at oracle.com  Tue Oct 16 08:12:32 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 16 Oct 2012 08:12:32 -0700
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
In-Reply-To: <507D0369.3010101@oracle.com>
References: <50773DE9.5000505@oracle.com> <507B0F19.6080505@oracle.com>
	<507C5E1E.6070506@oracle.com> <507D0369.3010101@oracle.com>
Message-ID: <507D7960.6020806@oracle.com>

The try-catch is no longer needed. Otherwise, the fix looks good to me.

Masayoshi

On 2012/10/15 23:49, Naoto Sato wrote:
> Since CLDR may not have all the defaults on the root bundle, I changed 
> the fix to use ResourceBundle.containsKey() method which guarantees to 
> look for the key including its parent bundles. Also changed 
> OpenListResourceBundle to ResourceBundle, since it is no longer 
> needed. Here is the latest webrev:
>
> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.02/
>
> Naoto
>
> On 10/15/12 12:03 PM, Naoto Sato wrote:
>> Thanks, Masayoshi, for the review. I removed that 'pool'. As to
>> "contains(key)", it has to be removed so that ResourceBundle's fallback
>> should occur with the requested locale. In fact, those try-catch would
>> never be used for normal keys because JRE/CLDR root bundles contain all
>> the defaults.
>>
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.01/
>>
>> Naoto
>> On 10/14/12 12:14 PM, Masayoshi Okutsu wrote:
>>> Here are my comments.
>>>
>>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:
>>>
>>> - pool is no longer used and should be removed.
>>>
>>> - Should contains(key) be retained? It should be faster than try-catch.
>>>
>>> Otherwise, the fix looks good to me.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 10/12/2012 6:45 AM, Naoto Sato wrote:
>>>> Hello,
>>>>
>>>> Please review the changes for the subject bugs:
>>>>
>>>> 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition)
>>>> doesn't work as expected with custom extensions
>>>> 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't
>>>> transferred to the custom service provider
>>>> 8000615: JRE adapter: timezone name of en_US is changed when extension
>>>> directory is added
>>>>
>>>> All of these bugs are regressions caused by the JEP 127 change, where
>>>> locale providers are invoked not with the originally requested locale.
>>>> Now it is invoked with the original locale as in
>>>> LocaleServiceProviderPool.java. With this change, resource bundle
>>>> locale check in JRE's
>>>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider
>>>> implementations are no longer needed.
>>>>
>>>> The webrev for these changes are located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.00/
>>>>
>>>> Naoto
>>>
>>
>


From naoto.sato at oracle.com  Tue Oct 16 09:31:13 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 16 Oct 2012 09:31:13 -0700
Subject: <i18n dev> [8] Request for review: 8000245/8000273/8000615
In-Reply-To: <507D7960.6020806@oracle.com>
References: <50773DE9.5000505@oracle.com> <507B0F19.6080505@oracle.com>
	<507C5E1E.6070506@oracle.com> <507D0369.3010101@oracle.com>
	<507D7960.6020806@oracle.com>
Message-ID: <507D8BD1.7080803@oracle.com>

OK, I will remove those try-catch and push the changeset.

Naoto

On 10/16/12 8:12 AM, Masayoshi Okutsu wrote:
> The try-catch is no longer needed. Otherwise, the fix looks good to me.
>
> Masayoshi
>
> On 2012/10/15 23:49, Naoto Sato wrote:
>> Since CLDR may not have all the defaults on the root bundle, I changed
>> the fix to use ResourceBundle.containsKey() method which guarantees to
>> look for the key including its parent bundles. Also changed
>> OpenListResourceBundle to ResourceBundle, since it is no longer
>> needed. Here is the latest webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.02/
>>
>> Naoto
>>
>> On 10/15/12 12:03 PM, Naoto Sato wrote:
>>> Thanks, Masayoshi, for the review. I removed that 'pool'. As to
>>> "contains(key)", it has to be removed so that ResourceBundle's fallback
>>> should occur with the requested locale. In fact, those try-catch would
>>> never be used for normal keys because JRE/CLDR root bundles contain all
>>> the defaults.
>>>
>>> Here is the updated webrev:
>>>
>>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.01/
>>>
>>> Naoto
>>> On 10/14/12 12:14 PM, Masayoshi Okutsu wrote:
>>>> Here are my comments.
>>>>
>>>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider:
>>>>
>>>> - pool is no longer used and should be removed.
>>>>
>>>> - Should contains(key) be retained? It should be faster than try-catch.
>>>>
>>>> Otherwise, the fix looks good to me.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 10/12/2012 6:45 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the changes for the subject bugs:
>>>>>
>>>>> 8000245: SimpleDateFormat.format(date, StringBuffer, FieldPosition)
>>>>> doesn't work as expected with custom extensions
>>>>> 8000273: java.util.Locale.getDisplayVariant(Locale l) isn't
>>>>> transferred to the custom service provider
>>>>> 8000615: JRE adapter: timezone name of en_US is changed when extension
>>>>> directory is added
>>>>>
>>>>> All of these bugs are regressions caused by the JEP 127 change, where
>>>>> locale providers are invoked not with the originally requested locale.
>>>>> Now it is invoked with the original locale as in
>>>>> LocaleServiceProviderPool.java. With this change, resource bundle
>>>>> locale check in JRE's
>>>>> LocaleNameProvider/CurrencyNameProvider/TimeZoneNameProvider
>>>>> implementations are no longer needed.
>>>>>
>>>>> The webrev for these changes are located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8000245.8000273.8000615/webrev.00/
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Tue Oct 16 09:50:19 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 16 Oct 2012 09:50:19 -0700
Subject: <i18n dev> Do developers or end-users create
	currency.properties?
In-Reply-To: <507D5B82.7060902@oracle.com>
References: <507C3445.2060208@oracle.com> <507D5B82.7060902@oracle.com>
Message-ID: <507D904B.4020103@oracle.com>

The idea was that "currency.properties" was intended for the "emergency" 
situation, where JRE's update could not keep up with customers' needs. 
The assumption was JRE's lib/currency.data should contain the latest 
currency data with the JRE updates.

Naoto

On 10/16/12 6:05 AM, Alan Bateman wrote:
> One other question on this topic is whether a system property or some
> other means to specify the location of a currency properties file to
> override the currency data was considered during 6332666. Although
> system properties aren't always the best solution it would at least
> allow someone to maintain their own currency file in a location that is
> immune from JDK updates.
>
> -Alan


From naoto.sato at oracle.com  Mon Oct 22 15:26:36 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 22 Oct 2012 15:26:36 -0700
Subject: <i18n dev> Request for review: 8000997: Multiple locale sensitive
 services cannot be loaded
Message-ID: <5085C81C.4090505@oracle.com>

Hello,

I need a reviewer for the changes for 8000997, where the symptom is:

"With the locale data deployment feature, locale sensitive services SPI 
implementations cannot be loaded more than one implementation. This is 
due to the fact that SPILocaleProviderAdapter only uses one instance of 
SPI implementations. It should load all the available installed 
providers as in JDK7, and correctly selects the instance depending on 
the requester's locale."

The gist of the fix is to prepare LocaleServiceProvider delegates for 
each services in SPILocaleProviderAdapter, and they work with the real 
SPI implementations. The proposed change is located here:

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

Naoto

From masayoshi.okutsu at oracle.com  Tue Oct 23 14:53:08 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 23 Oct 2012 14:53:08 -0700
Subject: <i18n dev> Request for review: 8000997: Multiple locale
 sensitive services cannot be loaded
In-Reply-To: <5085C81C.4090505@oracle.com>
References: <5085C81C.4090505@oracle.com>
Message-ID: <508711C4.5020209@oracle.com>

Here are my comments.

SPILocaleProviderAdapter.java:

- Should "." be used for composing a class name of a Delegate instead of 
"$"?

- Is it necessary to iterate locale candidate in getImpl? (Iteration is 
performed outside of adapters when getting an adapter or a provider of 
pools.)

- addImpl() overrides any previous impl if there are multiple 
implementations for the same Locale. Should the first one preserved?

- map.keySet().contains(key) should be map.containsKey(key).

- When a factory of a provider returns null where null is not allowed, 
should the provider be removed from the map?

Thanks,
Masayoshi

On 2012/10/22 15:26, Naoto Sato wrote:
> Hello,
>
> I need a reviewer for the changes for 8000997, where the symptom is:
>
> "With the locale data deployment feature, locale sensitive services 
> SPI implementations cannot be loaded more than one implementation. 
> This is due to the fact that SPILocaleProviderAdapter only uses one 
> instance of SPI implementations. It should load all the available 
> installed providers as in JDK7, and correctly selects the instance 
> depending on the requester's locale."
>
> The gist of the fix is to prepare LocaleServiceProvider delegates for 
> each services in SPILocaleProviderAdapter, and they work with the real 
> SPI implementations. The proposed change is located here:
>
> http://cr.openjdk.java.net/~naoto/8000997/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Tue Oct 23 17:20:27 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 23 Oct 2012 17:20:27 -0700
Subject: <i18n dev> Request for review: 8000997: Multiple locale
 sensitive services cannot be loaded
In-Reply-To: <508711C4.5020209@oracle.com>
References: <5085C81C.4090505@oracle.com> <508711C4.5020209@oracle.com>
Message-ID: <5087344B.7090506@oracle.com>

Thank you for your review. My comments are embedded below:

On 10/23/12 2:53 PM, Masayoshi Okutsu wrote:
> Here are my comments.
>
> SPILocaleProviderAdapter.java:
>
> - Should "." be used for composing a class name of a Delegate instead of
> "$"?

Since those delegates are inner classes within SPILocaleProviderAdapter, 
it has to be "$", otherwise the class cannot be found with 
Class.forName() method.

> - Is it necessary to iterate locale candidate in getImpl? (Iteration is
> performed outside of adapters when getting an adapter or a provider of
> pools.)

Yes. Delegates have to check lookup locales within themselves in order 
to decide which implementation should be returned.

> - addImpl() overrides any previous impl if there are multiple
> implementations for the same Locale. Should the first one preserved?

There is no rule which implementation is used when there are multiple 
implementations for a particular locale, so I think overriding is OK. 
Since in JDK7, the logic used to use Set interface, there is no way to 
keep compatibility.

> - map.keySet().contains(key) should be map.containsKey(key).

Fixed.

> - When a factory of a provider returns null where null is not allowed,
> should the provider be removed from the map?

I think this should be fine, since they are just the "delegates." 
Instead I added assertion to each getImpl() return value, which should 
always be non null.

The modified webrev is located here. Only SPILocaleProviderAdapter.java 
is modified this time.

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

Naoto

>
> Thanks,
> Masayoshi
>
> On 2012/10/22 15:26, Naoto Sato wrote:
>> Hello,
>>
>> I need a reviewer for the changes for 8000997, where the symptom is:
>>
>> "With the locale data deployment feature, locale sensitive services
>> SPI implementations cannot be loaded more than one implementation.
>> This is due to the fact that SPILocaleProviderAdapter only uses one
>> instance of SPI implementations. It should load all the available
>> installed providers as in JDK7, and correctly selects the instance
>> depending on the requester's locale."
>>
>> The gist of the fix is to prepare LocaleServiceProvider delegates for
>> each services in SPILocaleProviderAdapter, and they work with the real
>> SPI implementations. The proposed change is located here:
>>
>> http://cr.openjdk.java.net/~naoto/8000997/webrev.00/
>>
>> Naoto
>


From masayoshi.okutsu at oracle.com  Mon Oct 29 01:30:31 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 29 Oct 2012 17:30:31 +0900
Subject: <i18n dev> Request for review: 8000997: Multiple locale
 sensitive services cannot be loaded
In-Reply-To: <5087344B.7090506@oracle.com>
References: <5085C81C.4090505@oracle.com> <508711C4.5020209@oracle.com>
	<5087344B.7090506@oracle.com>
Message-ID: <508E3EA7.2090500@oracle.com>

Looks good.

Masayoshi

On 10/24/2012 9:20 AM, Naoto Sato wrote:
> Thank you for your review. My comments are embedded below:
>
> On 10/23/12 2:53 PM, Masayoshi Okutsu wrote:
>> Here are my comments.
>>
>> SPILocaleProviderAdapter.java:
>>
>> - Should "." be used for composing a class name of a Delegate instead of
>> "$"?
>
> Since those delegates are inner classes within 
> SPILocaleProviderAdapter, it has to be "$", otherwise the class cannot 
> be found with Class.forName() method.
>
>> - Is it necessary to iterate locale candidate in getImpl? (Iteration is
>> performed outside of adapters when getting an adapter or a provider of
>> pools.)
>
> Yes. Delegates have to check lookup locales within themselves in order 
> to decide which implementation should be returned.
>
>> - addImpl() overrides any previous impl if there are multiple
>> implementations for the same Locale. Should the first one preserved?
>
> There is no rule which implementation is used when there are multiple 
> implementations for a particular locale, so I think overriding is OK. 
> Since in JDK7, the logic used to use Set interface, there is no way to 
> keep compatibility.
>
>> - map.keySet().contains(key) should be map.containsKey(key).
>
> Fixed.
>
>> - When a factory of a provider returns null where null is not allowed,
>> should the provider be removed from the map?
>
> I think this should be fine, since they are just the "delegates." 
> Instead I added assertion to each getImpl() return value, which should 
> always be non null.
>
> The modified webrev is located here. Only 
> SPILocaleProviderAdapter.java is modified this time.
>
> http://cr.openjdk.java.net/~naoto/8000997/webrev.01/
>
> Naoto
>
>>
>> Thanks,
>> Masayoshi
>>
>> On 2012/10/22 15:26, Naoto Sato wrote:
>>> Hello,
>>>
>>> I need a reviewer for the changes for 8000997, where the symptom is:
>>>
>>> "With the locale data deployment feature, locale sensitive services
>>> SPI implementations cannot be loaded more than one implementation.
>>> This is due to the fact that SPILocaleProviderAdapter only uses one
>>> instance of SPI implementations. It should load all the available
>>> installed providers as in JDK7, and correctly selects the instance
>>> depending on the requester's locale."
>>>
>>> The gist of the fix is to prepare LocaleServiceProvider delegates for
>>> each services in SPILocaleProviderAdapter, and they work with the real
>>> SPI implementations. The proposed change is located here:
>>>
>>> http://cr.openjdk.java.net/~naoto/8000997/webrev.00/
>>>
>>> Naoto
>>
>


From naoto.sato at oracle.com  Tue Oct 30 09:33:43 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Oct 2012 09:33:43 -0700
Subject: <i18n dev> [8]Review request: 8001231 : Move locale data out of
 rt.jar (except the US locale)
Message-ID: <50900167.80805@oracle.com>

Hello,

I need someone to review my changes to the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231

The fix is to move locale data out of rt.jar into localedata.jar which 
will be optional in the compact profile 
(http://openjdk.java.net/jeps/161) The gist of the changes are in 
FILES_* files, but I also modified the makefiles for the new build-infra 
build. So I would appreciate your review in this area as well.

The proposed fix is located at:

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

Naoto

From naoto.sato at oracle.com  Tue Oct 30 14:44:24 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Oct 2012 14:44:24 -0700
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
Message-ID: <50904A38.5060505@oracle.com>

Hello,

Please review the fix for the following bug:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205

The fix is simply to supply the fallback locale provider adapter for the 
root locale, when there is no explicit "JRE" adapter is specified in the 
locale provider preference list.

The proposed fix is located at:

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

Naoto

From naoto.sato at oracle.com  Tue Oct 30 14:55:23 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Oct 2012 14:55:23 -0700
Subject: <i18n dev> [8]Review request for 8001440:,
 CLDR adapter: Invalid number extension in language tag causes
 exception in NumberFormat.format()
Message-ID: <50904CCB.4030402@oracle.com>

Here is another simple fix review request. The bug description can be 
found at:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001440

The reason of the issue was that the "DefaultNumberingSystem" value was 
not retrieved correctly when the Unicode extension key was a bogus 
value. The proposed fix is located at:

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

Naoto

From masayoshi.okutsu at oracle.com  Tue Oct 30 19:43:25 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 31 Oct 2012 11:43:25 +0900
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <50904A38.5060505@oracle.com>
References: <50904A38.5060505@oracle.com>
Message-ID: <5090904D.9080801@oracle.com>

Question. Does the full set of available locales of JRE still become 
available with this fix? For example, when java.locale.providers=SPI, 
all JRE locales are included in the getAvailableLocales (API)? The 
fallback adapter is an interesting idea, but it's a bit confusing...

Thanks,
Masayoshi

On 10/31/2012 6:44 AM, Naoto Sato wrote:
> Hello,
>
> Please review the fix for the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>
> The fix is simply to supply the fallback locale provider adapter for 
> the root locale, when there is no explicit "JRE" adapter is specified 
> in the locale provider preference list.
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Tue Oct 30 19:55:32 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 30 Oct 2012 19:55:32 -0700
Subject: <i18n dev> [8]Request for review: 8001205)
 Calendar.getDisplayName(...): Returns null when provider is SPI but there
 is no SPI implementation
In-Reply-To: <5090904D.9080801@oracle.com>
References: <50904A38.5060505@oracle.com> <5090904D.9080801@oracle.com>
Message-ID: <50909324.1090803@oracle.com>

With this fix, no. But another bug was filed regarding the locale 
sensitive service APIs' (e.g., Collator) getAvailableLocales() return 
value (8001562). I will fix it to keep the returned locale array 
compatible with JDK7.

Naoto

On 10/30/12 7:43 PM, Masayoshi Okutsu wrote:
> Question. Does the full set of available locales of JRE still become
> available with this fix? For example, when java.locale.providers=SPI,
> all JRE locales are included in the getAvailableLocales (API)? The
> fallback adapter is an interesting idea, but it's a bit confusing...
>
> Thanks,
> Masayoshi
>
> On 10/31/2012 6:44 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the fix for the following bug:
>>
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001205
>>
>> The fix is simply to supply the fallback locale provider adapter for
>> the root locale, when there is no explicit "JRE" adapter is specified
>> in the locale provider preference list.
>>
>> The proposed fix is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8001205/webrev.00/
>>
>> Naoto
>


From Alan.Bateman at oracle.com  Wed Oct 31 03:06:46 2012
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Wed, 31 Oct 2012 10:06:46 +0000
Subject: <i18n dev> [8]Review request: 8001231 : Move locale data out of
 rt.jar (except the US locale)
In-Reply-To: <50900167.80805@oracle.com>
References: <50900167.80805@oracle.com>
Message-ID: <5090F836.7040801@oracle.com>

On 30/10/2012 16:33, Naoto Sato wrote:
> Hello,
>
> I need someone to review my changes to the following bug:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001231
>
> The fix is to move locale data out of rt.jar into localedata.jar which 
> will be optional in the compact profile 
> (http://openjdk.java.net/jeps/161) The gist of the changes are in 
> FILES_* files, but I also modified the makefiles for the new 
> build-infra build. So I would appreciate your review in this area as 
> well.
>
> The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8001231/webrev.00/
>
> Naoto
I looked through the changes and they look fine to me, it's good to have 
this separation. Also good to see that you've also updated the makefiles 
for the new build system. If we were continuing with the old build 
system then I would suggested using AUTO_FILES_JAVA_DIRS as there 
shouldn't be a need to list every source file for every locale in the 
make files.

The only question I have is whether there is any performance 
implications for the western Europe locales. I don't know if we've got 
any tests that would tell us whether this is significant or not.

-Alan



From naoto.sato at oracle.com  Wed Oct 31 11:12:17 2012
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 31 Oct 2012 11:12:17 -0700
Subject: <i18n dev> [8]Review request: 8001231 : Move locale data out of
 rt.jar (except the US locale)
In-Reply-To: <5090F836.7040801@oracle.com>
References: <50900167.80805@oracle.com> <5090F836.7040801@oracle.com>
Message-ID: <50916A01.5000201@oracle.com>

Thank you for the review, Alan.

On 10/31/12 3:06 AM, Alan Bateman wrote:
> I looked through the changes and they look fine to me, it's good to have
> this separation. Also good to see that you've also updated the makefiles
> for the new build system. If we were continuing with the old build
> system then I would suggested using AUTO_FILES_JAVA_DIRS as there
> shouldn't be a need to list every source file for every locale in the
> make files.

Only tricky part is that for the US locale, it's not automatic. US and 
non-US locale data co-exist in sun/text/resources/en and 
sun/util/resources/en. Considering the traditional build is going away, 
I just modified the existing file lists to work with the desired 
US/non-US separation.

> The only question I have is whether there is any performance
> implications for the western Europe locales. I don't know if we've got
> any tests that would tell us whether this is significant or not.

Will look into this and come up with some data.

Naoto

From masayoshi.okutsu at oracle.com  Wed Oct 31 18:38:55 2012
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Thu, 01 Nov 2012 10:38:55 +0900
Subject: <i18n dev> [8]Review request for 8001440:,
 CLDR adapter: Invalid number extension in language tag causes
 exception in NumberFormat.format()
In-Reply-To: <50904CCB.4030402@oracle.com>
References: <50904CCB.4030402@oracle.com>
Message-ID: <5091D2AF.3070709@oracle.com>

Looks good to me.

Masayoshi

On 10/31/2012 6:55 AM, Naoto Sato wrote:
> Here is another simple fix review request. The bug description can be 
> found at:
>
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8001440
>
> The reason of the issue was that the "DefaultNumberingSystem" value 
> was not retrieved correctly when the Unicode extension key was a bogus 
> value. The proposed fix is located at:
>
> http://cr.openjdk.java.net/~naoto/8001440/webrev.00/
>
> Naoto