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

[Masayoshi Okutsu]

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