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

[Masayoshi Okutsu]

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