<i18n dev> [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono

[Masayoshi Okutsu]

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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>