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
