Hi Naoto and Sean
I think we can verify it in Japanese environment.
The reason for backporting is that it's quite safe to do and also
would be better if the defect is fixed in JDK 7 also. Please let me
know if there is any idea. Thank you.
Best regards,
Frank
While I think fix looks goo
OK, I am fine with backporting the fix. Please go ahead.
Naoto
On 1/29/13 9:34 PM, Frank Ding wrote:
Hi Naoto and Sean
I think we can verify it in Japanese environment.
The reason for backporting is that it's quite safe to do and also
would be better if the defect is fixed in JDK 7 also.
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
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.openjd
Hi Naoto,
Thank you.
To Sean,
Could you please shed your light or anything I can do?
Best regards,
Frank
On 1/31/2013 3:15 AM, Naoto Sato wrote:
OK, I am fine with backporting the fix. Please go ahead.
Naoto
On 1/29/13 9:34 PM, Frank Ding wrote:
Hi Naoto and Sean
I think we can verif
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.
Please also provide a regression test along with the fix. Thanks.
Naoto
On 1/30/13 6:08 PM, Frank Ding wrote:
Hi Naoto,
Thank you.
To Sean,
Could you please shed your light or anything I can do?
Best regards,
Frank
On 1/31/2013 3:15 AM, Naoto Sato wrote:
OK, I am fine with backporting
Colleagues,
I'm someway out of sync here but how about the first line in
XKeysym.java?
1 // This is a generated file: do not edit! Edit keysym2ucs.h if necessary.
Either this rather unusual approach should be changed or
keysym2ucs.h prototype changed first.
Thanks,
-yan
On 01/31/2013 06:08 AM,
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.
