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
