From naoto.sato at oracle.com  Fri Feb  1 09:40:10 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 01 Feb 2013 09:40:10 -0800
Subject: <i18n dev> Review Request: 8006748
In-Reply-To: <510B348D.1080306@oracle.com>
References: <510B348D.1080306@oracle.com>
Message-ID: <510BFDFA.5010409@oracle.com>

Looks good.

Naoto

On 1/31/13 7:20 PM, Yong Jeffrey Huang wrote:
> Hello,
>
> This is the review request for
> https://jbs.oracle.com/bugs/browse/JDK-8006748.
>
> http://cr.openjdk.java.net/~yhuang/8006748/webrev.00/
>
> Regression test is in closed repository. I will send it separately.
>
> thanks,
> Yong


From naoto.sato at oracle.com  Mon Feb  4 13:53:47 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 04 Feb 2013 13:53:47 -0800
Subject: <i18n dev> [8]Request for Review: 8007038:
 ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with
 JapaneseChrono
In-Reply-To: <510ABDED.8080603@oracle.com>
References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com>
	<5109DBA1.4000109@oracle.com> <510A1AE4.1020606@oracle.com>
	<510ABDED.8080603@oracle.com>
Message-ID: <51102DEB.8080109@oracle.com>

After all, I decided just to return null on invalid "value"s. Removing 
the Calendar extension in the argument locale object can save duplicated 
caches, but I don't think that's very common, so let them be around.

Revised webrev is located here:

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

Naoto

On 1/31/13 10:54 AM, Naoto Sato wrote:
> OK, I think what the right fix in this case is to remove the
> "-u-ca-japanese" extension in CalendarNameProviderImpl.getDisplayName(),
> as "ja-JP-u-ca-japanese" is still valid as a "display" locale. Will
> modify the fix accordingly.
>
> Naoto
>
> On 1/30/13 11:19 PM, Masayoshi Okutsu wrote:
>> The caller of CalendarNameProvider is responsible for specifying the
>> calendar type to use. The locale gives what language to use for names.
>> Otherwise, a call like provider.getDisplayName("gregory", ERA, 1, SHORT,
>> Locale.forLanguageTag("ja-JP-u-ca-japanese")) works wrong.
>>
>> This may be confusing. So I did put a note to the SPI documentation to
>> avoid this confusion.
>>
>>     |calendarType| - the calendar type. (Any calendar type given by
>>     |locale| is ignored.)
>>
>> The stack trace seems to show the following call (equivalent) was made.
>>
>> provider.getDisplayName("gregory", ERA, 2, SHORT,
>> Locale.forLanguageTag("ja-JP-u-ca-japanese"))
>>
>> Maybe the value parameter should be checked. A question is that it
>> should return null or throw an IllegalArgumentException.
>>
>> Thanks,
>> Masayoshi
>>
>> On 1/31/2013 11:49 AM, Naoto Sato wrote:
>>> I agree that there also is a problem in 310 side, but the bug I am
>>> trying to fix is the one in LocaleResources, which is independent of
>>> how 310 code is calling into this getCalendarNames() method.
>>> LocaleResources.getCalendarNames() should return the calendar names
>>> for the specified calendar.
>>>
>>> Naoto
>>>
>>> On 1/30/13 6:01 PM, Masayoshi Okutsu wrote:
>>>> It's not correct to use locale's calendar for the fix. The calendar
>>>> type
>>>> needs to be from the Chrono(logy) set to the formatter. The 310 code
>>>> needs to be fixed.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 1/31/2013 7:02 AM, Naoto Sato wrote:
>>>>> Hello,
>>>>>
>>>>> Please review the following changes for 8007038:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8007038/webrev.00/
>>>>>
>>>>> The bug description can be found here:
>>>>>
>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007038
>>>>>
>>>>> The cause of the bug was that the calendar name provider
>>>>> implementation did not take the Unicode -u extension into account.
>>>>>
>>>>> Naoto
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Tue Feb  5 17:10:52 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Wed, 06 Feb 2013 10:10:52 +0900
Subject: <i18n dev> [8]Request for Review: 8007038:
 ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with
 JapaneseChrono
In-Reply-To: <51102DEB.8080109@oracle.com>
References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com>
	<5109DBA1.4000109@oracle.com> <510A1AE4.1020606@oracle.com>
	<510ABDED.8080603@oracle.com> <51102DEB.8080109@oracle.com>
Message-ID: <5111AD9C.8040505@oracle.com>

I think the validation is a bit expensive. And I prefer to check the 
value based on resource data rather than API-defined constants, 
especially for Japanese Eras. How about checking the array length 
against the value?

Thanks,
Masayoshi

On 2/5/2013 6:53 AM, Naoto Sato wrote:
> After all, I decided just to return null on invalid "value"s. Removing 
> the Calendar extension in the argument locale object can save 
> duplicated caches, but I don't think that's very common, so let them 
> be around.
>
> Revised webrev is located here:
>
> http://cr.openjdk.java.net/~naoto/8007038/webrev.01/
>
> Naoto
>
> On 1/31/13 10:54 AM, Naoto Sato wrote:
>> OK, I think what the right fix in this case is to remove the
>> "-u-ca-japanese" extension in CalendarNameProviderImpl.getDisplayName(),
>> as "ja-JP-u-ca-japanese" is still valid as a "display" locale. Will
>> modify the fix accordingly.
>>
>> Naoto
>>
>> On 1/30/13 11:19 PM, Masayoshi Okutsu wrote:
>>> The caller of CalendarNameProvider is responsible for specifying the
>>> calendar type to use. The locale gives what language to use for names.
>>> Otherwise, a call like provider.getDisplayName("gregory", ERA, 1, 
>>> SHORT,
>>> Locale.forLanguageTag("ja-JP-u-ca-japanese")) works wrong.
>>>
>>> This may be confusing. So I did put a note to the SPI documentation to
>>> avoid this confusion.
>>>
>>>     |calendarType| - the calendar type. (Any calendar type given by
>>>     |locale| is ignored.)
>>>
>>> The stack trace seems to show the following call (equivalent) was made.
>>>
>>> provider.getDisplayName("gregory", ERA, 2, SHORT,
>>> Locale.forLanguageTag("ja-JP-u-ca-japanese"))
>>>
>>> Maybe the value parameter should be checked. A question is that it
>>> should return null or throw an IllegalArgumentException.
>>>
>>> Thanks,
>>> Masayoshi
>>>
>>> On 1/31/2013 11:49 AM, Naoto Sato wrote:
>>>> I agree that there also is a problem in 310 side, but the bug I am
>>>> trying to fix is the one in LocaleResources, which is independent of
>>>> how 310 code is calling into this getCalendarNames() method.
>>>> LocaleResources.getCalendarNames() should return the calendar names
>>>> for the specified calendar.
>>>>
>>>> Naoto
>>>>
>>>> On 1/30/13 6:01 PM, Masayoshi Okutsu wrote:
>>>>> It's not correct to use locale's calendar for the fix. The calendar
>>>>> type
>>>>> needs to be from the Chrono(logy) set to the formatter. The 310 code
>>>>> needs to be fixed.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 1/31/2013 7:02 AM, Naoto Sato wrote:
>>>>>> Hello,
>>>>>>
>>>>>> Please review the following changes for 8007038:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8007038/webrev.00/
>>>>>>
>>>>>> The bug description can be found here:
>>>>>>
>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007038
>>>>>>
>>>>>> The cause of the bug was that the calendar name provider
>>>>>> implementation did not take the Unicode -u extension into account.
>>>>>>
>>>>>> Naoto
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Wed Feb  6 11:42:43 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Wed, 06 Feb 2013 11:42:43 -0800
Subject: <i18n dev> [8]Request for Review: 8007038:
 ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with
 JapaneseChrono
In-Reply-To: <5111AD9C.8040505@oracle.com>
References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com>
	<5109DBA1.4000109@oracle.com> <510A1AE4.1020606@oracle.com>
	<510ABDED.8080603@oracle.com> <51102DEB.8080109@oracle.com>
	<5111AD9C.8040505@oracle.com>
Message-ID: <5112B233.8030602@oracle.com>

OK, revised the fix. Much simpler now. I kept the regression test the 
same as webrev.01, for the verification purpose.

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

Naoto

On 2/5/13 5:10 PM, Masayoshi Okutsu wrote:
> I think the validation is a bit expensive. And I prefer to check the
> value based on resource data rather than API-defined constants,
> especially for Japanese Eras. How about checking the array length
> against the value?
>
> Thanks,
> Masayoshi
>
> On 2/5/2013 6:53 AM, Naoto Sato wrote:
>> After all, I decided just to return null on invalid "value"s. Removing
>> the Calendar extension in the argument locale object can save
>> duplicated caches, but I don't think that's very common, so let them
>> be around.
>>
>> Revised webrev is located here:
>>
>> http://cr.openjdk.java.net/~naoto/8007038/webrev.01/
>>
>> Naoto
>>
>> On 1/31/13 10:54 AM, Naoto Sato wrote:
>>> OK, I think what the right fix in this case is to remove the
>>> "-u-ca-japanese" extension in CalendarNameProviderImpl.getDisplayName(),
>>> as "ja-JP-u-ca-japanese" is still valid as a "display" locale. Will
>>> modify the fix accordingly.
>>>
>>> Naoto
>>>
>>> On 1/30/13 11:19 PM, Masayoshi Okutsu wrote:
>>>> The caller of CalendarNameProvider is responsible for specifying the
>>>> calendar type to use. The locale gives what language to use for names.
>>>> Otherwise, a call like provider.getDisplayName("gregory", ERA, 1,
>>>> SHORT,
>>>> Locale.forLanguageTag("ja-JP-u-ca-japanese")) works wrong.
>>>>
>>>> This may be confusing. So I did put a note to the SPI documentation to
>>>> avoid this confusion.
>>>>
>>>>     |calendarType| - the calendar type. (Any calendar type given by
>>>>     |locale| is ignored.)
>>>>
>>>> The stack trace seems to show the following call (equivalent) was made.
>>>>
>>>> provider.getDisplayName("gregory", ERA, 2, SHORT,
>>>> Locale.forLanguageTag("ja-JP-u-ca-japanese"))
>>>>
>>>> Maybe the value parameter should be checked. A question is that it
>>>> should return null or throw an IllegalArgumentException.
>>>>
>>>> Thanks,
>>>> Masayoshi
>>>>
>>>> On 1/31/2013 11:49 AM, Naoto Sato wrote:
>>>>> I agree that there also is a problem in 310 side, but the bug I am
>>>>> trying to fix is the one in LocaleResources, which is independent of
>>>>> how 310 code is calling into this getCalendarNames() method.
>>>>> LocaleResources.getCalendarNames() should return the calendar names
>>>>> for the specified calendar.
>>>>>
>>>>> Naoto
>>>>>
>>>>> On 1/30/13 6:01 PM, Masayoshi Okutsu wrote:
>>>>>> It's not correct to use locale's calendar for the fix. The calendar
>>>>>> type
>>>>>> needs to be from the Chrono(logy) set to the formatter. The 310 code
>>>>>> needs to be fixed.
>>>>>>
>>>>>> Thanks,
>>>>>> Masayoshi
>>>>>>
>>>>>> On 1/31/2013 7:02 AM, Naoto Sato wrote:
>>>>>>> Hello,
>>>>>>>
>>>>>>> Please review the following changes for 8007038:
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~naoto/8007038/webrev.00/
>>>>>>>
>>>>>>> The bug description can be found here:
>>>>>>>
>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007038
>>>>>>>
>>>>>>> The cause of the bug was that the calendar name provider
>>>>>>> implementation did not take the Unicode -u extension into account.
>>>>>>>
>>>>>>> Naoto
>>>>>>
>>>>>
>>>>
>>>
>>
>


From masayoshi.okutsu at oracle.com  Thu Feb  7 18:32:03 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Fri, 08 Feb 2013 11:32:03 +0900
Subject: <i18n dev> [8]Request for Review: 8007038:
 ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with
 JapaneseChrono
In-Reply-To: <5112B233.8030602@oracle.com>
References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com>
	<5109DBA1.4000109@oracle.com> <510A1AE4.1020606@oracle.com>
	<510ABDED.8080603@oracle.com> <51102DEB.8080109@oracle.com>
	<5111AD9C.8040505@oracle.com> <5112B233.8030602@oracle.com>
Message-ID: <511463A3.4080104@oracle.com>

Looks good to me.

Masayoshi

On 2/7/2013 4:42 AM, Naoto Sato wrote:
> OK, revised the fix. Much simpler now. I kept the regression test the 
> same as webrev.01, for the verification purpose.
>
> http://cr.openjdk.java.net/~naoto/8007038/webrev.02/
>
> Naoto
>
> On 2/5/13 5:10 PM, Masayoshi Okutsu wrote:
>> I think the validation is a bit expensive. And I prefer to check the
>> value based on resource data rather than API-defined constants,
>> especially for Japanese Eras. How about checking the array length
>> against the value?
>>
>> Thanks,
>> Masayoshi
>>
>> On 2/5/2013 6:53 AM, Naoto Sato wrote:
>>> After all, I decided just to return null on invalid "value"s. Removing
>>> the Calendar extension in the argument locale object can save
>>> duplicated caches, but I don't think that's very common, so let them
>>> be around.
>>>
>>> Revised webrev is located here:
>>>
>>> http://cr.openjdk.java.net/~naoto/8007038/webrev.01/
>>>
>>> Naoto
>>>
>>> On 1/31/13 10:54 AM, Naoto Sato wrote:
>>>> OK, I think what the right fix in this case is to remove the
>>>> "-u-ca-japanese" extension in 
>>>> CalendarNameProviderImpl.getDisplayName(),
>>>> as "ja-JP-u-ca-japanese" is still valid as a "display" locale. Will
>>>> modify the fix accordingly.
>>>>
>>>> Naoto
>>>>
>>>> On 1/30/13 11:19 PM, Masayoshi Okutsu wrote:
>>>>> The caller of CalendarNameProvider is responsible for specifying the
>>>>> calendar type to use. The locale gives what language to use for 
>>>>> names.
>>>>> Otherwise, a call like provider.getDisplayName("gregory", ERA, 1,
>>>>> SHORT,
>>>>> Locale.forLanguageTag("ja-JP-u-ca-japanese")) works wrong.
>>>>>
>>>>> This may be confusing. So I did put a note to the SPI 
>>>>> documentation to
>>>>> avoid this confusion.
>>>>>
>>>>>     |calendarType| - the calendar type. (Any calendar type given by
>>>>>     |locale| is ignored.)
>>>>>
>>>>> The stack trace seems to show the following call (equivalent) was 
>>>>> made.
>>>>>
>>>>> provider.getDisplayName("gregory", ERA, 2, SHORT,
>>>>> Locale.forLanguageTag("ja-JP-u-ca-japanese"))
>>>>>
>>>>> Maybe the value parameter should be checked. A question is that it
>>>>> should return null or throw an IllegalArgumentException.
>>>>>
>>>>> Thanks,
>>>>> Masayoshi
>>>>>
>>>>> On 1/31/2013 11:49 AM, Naoto Sato wrote:
>>>>>> I agree that there also is a problem in 310 side, but the bug I am
>>>>>> trying to fix is the one in LocaleResources, which is independent of
>>>>>> how 310 code is calling into this getCalendarNames() method.
>>>>>> LocaleResources.getCalendarNames() should return the calendar names
>>>>>> for the specified calendar.
>>>>>>
>>>>>> Naoto
>>>>>>
>>>>>> On 1/30/13 6:01 PM, Masayoshi Okutsu wrote:
>>>>>>> It's not correct to use locale's calendar for the fix. The calendar
>>>>>>> type
>>>>>>> needs to be from the Chrono(logy) set to the formatter. The 310 
>>>>>>> code
>>>>>>> needs to be fixed.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Masayoshi
>>>>>>>
>>>>>>> On 1/31/2013 7:02 AM, Naoto Sato wrote:
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> Please review the following changes for 8007038:
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~naoto/8007038/webrev.00/
>>>>>>>>
>>>>>>>> The bug description can be found here:
>>>>>>>>
>>>>>>>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8007038
>>>>>>>>
>>>>>>>> The cause of the bug was that the calendar name provider
>>>>>>>> implementation did not take the Unicode -u extension into account.
>>>>>>>>
>>>>>>>> Naoto
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>


From naoto.sato at oracle.com  Mon Feb 18 10:58:58 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 18 Feb 2013 10:58:58 -0800
Subject: <i18n dev> [8]Review request for 7092447: Clarify the default
 locale used in each locale sensitive operation
Message-ID: <512279F2.6040107@oracle.com>

Hello,

Please review the proposed changes for the subject CR:

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

The changes just clarify the current behavior in each locale sensitive 
service. It involves no actual code changes but just changes to their 
javadocs. Here is the webrev for the proposed changes:

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

Naoto

From masayoshi.okutsu at oracle.com  Mon Feb 18 21:51:56 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Tue, 19 Feb 2013 14:51:56 +0900
Subject: <i18n dev> [8]Review request for 7092447: Clarify the default
 locale used in each locale sensitive operation
In-Reply-To: <512279F2.6040107@oracle.com>
References: <512279F2.6040107@oracle.com>
Message-ID: <512312FC.7010002@oracle.com>

Looks good to me.

Masayoshi

On 2/19/2013 3:58 AM, Naoto Sato wrote:
> Hello,
>
> Please review the proposed changes for the subject CR:
>
> http://bugs.sun.com/view_bug.do?bug_id=7092447
>
> The changes just clarify the current behavior in each locale sensitive 
> service. It involves no actual code changes but just changes to their 
> javadocs. Here is the webrev for the proposed changes:
>
> http://cr.openjdk.java.net/~naoto/7092447/webrev.00/
>
> Naoto


From sean.coffey at oracle.com  Tue Feb 19 05:05:57 2013
From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=)
Date: Tue, 19 Feb 2013 13:05:57 +0000
Subject: <i18n dev> RFR: 7197187 Currency.isPastCutoverDate should be made
	more robust
Message-ID: <512378B5.9020704@oracle.com>

As correctly pointed out by Alan, the 7180362 code fix should be tidied 
up to not handle RuntimeExceptions. The NullPointerExcepiton and 
IndexOutOfBoundsException's should not be handled by the 
Currency.replaceCurrencyData(..)

bug report : http://bugs.sun.com/view_bug.do?bug_id=7197187
webrev : http://cr.openjdk.java.net/~coffeys/webrev.7197187/

regards,
Sean.

From Alan.Bateman at oracle.com  Tue Feb 19 05:10:27 2013
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Feb 2013 13:10:27 +0000
Subject: <i18n dev> RFR: 7197187 Currency.isPastCutoverDate should be
	made more robust
In-Reply-To: <512378B5.9020704@oracle.com>
References: <512378B5.9020704@oracle.com>
Message-ID: <512379C3.5080105@oracle.com>

On 19/02/2013 13:05, Se?n Coffey wrote:
> As correctly pointed out by Alan, the 7180362 code fix should be 
> tidied up to not handle RuntimeExceptions. The NullPointerExcepiton 
> and IndexOutOfBoundsException's should not be handled by the 
> Currency.replaceCurrencyData(..)
>
> bug report : http://bugs.sun.com/view_bug.do?bug_id=7197187
> webrev : http://cr.openjdk.java.net/~coffeys/webrev.7197187/
>
> regards,
> Sean.
Thanks for remembering to come back to that one, the change looks fine 
to me.

-Alan.

From naoto.sato at oracle.com  Fri Feb 22 13:15:07 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 22 Feb 2013 13:15:07 -0800
Subject: <i18n dev> [8]Review request for 8004240 and 8008577
Message-ID: <5127DFDB.1030900@oracle.com>

Hello,

Please review the changes for the following CR:

8004240 : Return value from getAdapterPrefence() can be modified 
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004240)
8008577 : Enable CLDR LocaleProviderAdapter by default 
(http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008577)

The webrev is located at:
http://cr.openjdk.java.net/~naoto/8004240.8008577/webrev.00/

Naoto

From masayoshi.okutsu at oracle.com  Sun Feb 24 18:16:30 2013
From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu)
Date: Mon, 25 Feb 2013 11:16:30 +0900
Subject: <i18n dev> [8]Review request for 8004240 and 8008577
In-Reply-To: <5127DFDB.1030900@oracle.com>
References: <5127DFDB.1030900@oracle.com>
Message-ID: <512AC97E.4020205@oracle.com>

For 8004240, I think adapterPreference should be changed to an 
unmodifiable List because getAdapterPreference() is called often.

For 8008577, I think it's a spec change to 6336885, and that CCC 
approval is required. And should the CLDR adapter be initialized and be 
removed from the list if the initialization failed?

Masayoshi


On 2/23/2013 6:15 AM, Naoto Sato wrote:
> Hello,
>
> Please review the changes for the following CR:
>
> 8004240 : Return value from getAdapterPrefence() can be modified 
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004240)
> 8008577 : Enable CLDR LocaleProviderAdapter by default 
> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008577)
>
> The webrev is located at:
> http://cr.openjdk.java.net/~naoto/8004240.8008577/webrev.00/
>
> Naoto


From naoto.sato at oracle.com  Mon Feb 25 11:13:00 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Feb 2013 11:13:00 -0800
Subject: <i18n dev> [8]Review request for 8004240 and 8008577
In-Reply-To: <512AC97E.4020205@oracle.com>
References: <5127DFDB.1030900@oracle.com> <512AC97E.4020205@oracle.com>
Message-ID: <512BB7BC.60905@oracle.com>

Thank you for the review. Please see my comments embedded below.

On 2/24/13 6:16 PM, Masayoshi Okutsu wrote:
> For 8004240, I think adapterPreference should be changed to an
> unmodifiable List because getAdapterPreference() is called often.

Agree. Will change the impl.

>
> For 8008577, I think it's a spec change to 6336885, and that CCC
> approval is required. And should the CLDR adapter be initialized and be
> removed from the list if the initialization failed?

I think which locale provider adapters are implemented (and enabled) 
depends on each JRE's implementation, not the spec. However, since this 
is going to change Oracle's JRE behavior (even from yet released jdk8 
beta builds), I will file a CCC request for this.

Anyway, I think I'll need to split this review request into two. Will do 
it shortly.

Naoto

>
> Masayoshi
>
>
> On 2/23/2013 6:15 AM, Naoto Sato wrote:
>> Hello,
>>
>> Please review the changes for the following CR:
>>
>> 8004240 : Return value from getAdapterPrefence() can be modified
>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004240)
>> 8008577 : Enable CLDR LocaleProviderAdapter by default
>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008577)
>>
>> The webrev is located at:
>> http://cr.openjdk.java.net/~naoto/8004240.8008577/webrev.00/
>>
>> Naoto
>


From naoto.sato at oracle.com  Mon Feb 25 15:34:23 2013
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 25 Feb 2013 15:34:23 -0800
Subject: <i18n dev> [8]Review request for 8004240
In-Reply-To: <512BB7BC.60905@oracle.com>
References: <5127DFDB.1030900@oracle.com> <512AC97E.4020205@oracle.com>
	<512BB7BC.60905@oracle.com>
Message-ID: <512BF4FF.2070908@oracle.com>

(modified the title)

OK, so this is the review request for 8004240 fix. I changed the type of 
'adapterPreference' from 'Type[]' to 'List<Type>' and initialized it 
with the 'unmodifiableList'.

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

Naoto

On 2/25/13 11:13 AM, Naoto Sato wrote:
> Thank you for the review. Please see my comments embedded below.
>
> On 2/24/13 6:16 PM, Masayoshi Okutsu wrote:
>> For 8004240, I think adapterPreference should be changed to an
>> unmodifiable List because getAdapterPreference() is called often.
>
> Agree. Will change the impl.
>
>>
>> For 8008577, I think it's a spec change to 6336885, and that CCC
>> approval is required. And should the CLDR adapter be initialized and be
>> removed from the list if the initialization failed?
>
> I think which locale provider adapters are implemented (and enabled)
> depends on each JRE's implementation, not the spec. However, since this
> is going to change Oracle's JRE behavior (even from yet released jdk8
> beta builds), I will file a CCC request for this.
>
> Anyway, I think I'll need to split this review request into two. Will do
> it shortly.
>
> Naoto
>
>>
>> Masayoshi
>>
>>
>> On 2/23/2013 6:15 AM, Naoto Sato wrote:
>>> Hello,
>>>
>>> Please review the changes for the following CR:
>>>
>>> 8004240 : Return value from getAdapterPrefence() can be modified
>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004240)
>>> 8008577 : Enable CLDR LocaleProviderAdapter by default
>>> (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8008577)
>>>
>>> The webrev is located at:
>>> http://cr.openjdk.java.net/~naoto/8004240.8008577/webrev.00/
>>>
>>> Naoto
>>
>