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

[Naoto Sato]

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