From sean.coffey at oracle.com Thu Jan 3 11:59:02 2013 From: sean.coffey at oracle.com (=?ISO-8859-1?Q?Se=E1n_Coffey?=) Date: Thu, 03 Jan 2013 19:59:02 +0000 Subject: RFR: CR 7196533 : TimeZone.getDefault() slow due to synchronization bottleneck Message-ID: <50E5E306.4020505@oracle.com> Masayoshi, I'm looking to backport this fix which was been soaking in jdk8 for a few months now. Fix is identical with the exception of some comment re-ordering and redeclaring of the javaAWTAccess variable to keep code consistent with jdk8. jdk8 review thread : http://mail.openjdk.java.net/pipermail/i18n-dev/2012-October/000799.html bug report : http://bugs.sun.com/view_bug.do?bug_id=7196533 webrev : http://cr.openjdk.java.net/~coffeys/webrev.7196533.7u/ Regards, Sean. From masayoshi.okutsu at oracle.com Thu Jan 3 16:00:29 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 04 Jan 2013 09:00:29 +0900 Subject: RFR: CR 7196533 : TimeZone.getDefault() slow due to synchronization bottleneck In-Reply-To: <50E5E306.4020505@oracle.com> References: <50E5E306.4020505@oracle.com> Message-ID: <50E61B9D.20101@oracle.com> Looks good to me. Thanks, Masayoshi On 1/4/2013 4:59 AM, Se?n Coffey wrote: > Masayoshi, > > I'm looking to backport this fix which was been soaking in jdk8 for a > few months now. > > Fix is identical with the exception of some comment re-ordering and > redeclaring of the javaAWTAccess variable to keep code consistent > with jdk8. > > jdk8 review thread : > http://mail.openjdk.java.net/pipermail/i18n-dev/2012-October/000799.html > bug report : http://bugs.sun.com/view_bug.do?bug_id=7196533 > > webrev : http://cr.openjdk.java.net/~coffeys/webrev.7196533.7u/ > > Regards, > Sean. > > From naoto.sato at oracle.com Fri Jan 11 13:18:22 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 11 Jan 2013 13:18:22 -0800 Subject: [8]Review Request: 7162007: Clean up i18n related caches Message-ID: <50F0819E.1080306@oracle.com> Hello, (To build-dev folks, I am sending this to you as the change includes one modification in make directory. It is just simply adding a new Java file, so I think it won't affect the new build-infra structure) Please review the changes for this issue: http://bugs.sun.com/view_bug.do?bug_id=7162007 Currently locale sensitive services cache their data in a very ad-hoc manner, scattered everywhere. This issue intends to consolidate them into a centralized location in sun.util.locale.provider package. The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/7162007/webrev.00/ Naoto From kelly.ohair at oracle.com Fri Jan 11 17:40:32 2013 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 11 Jan 2013 17:40:32 -0800 Subject: [8]Review Request: 7162007: Clean up i18n related caches In-Reply-To: <50F0819E.1080306@oracle.com> References: <50F0819E.1080306@oracle.com> Message-ID: makefile change is fine, no need to change the new build makefiles at all. -kto On Jan 11, 2013, at 1:18 PM, Naoto Sato wrote: > Hello, > > (To build-dev folks, I am sending this to you as the change includes one modification in make directory. It is just simply adding a new Java file, so I think it won't affect the new build-infra structure) > > Please review the changes for this issue: > > http://bugs.sun.com/view_bug.do?bug_id=7162007 > > Currently locale sensitive services cache their data in a very ad-hoc manner, scattered everywhere. This issue intends to consolidate them into a centralized location in sun.util.locale.provider package. > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/7162007/webrev.00/ > > Naoto From masayoshi.okutsu at oracle.com Fri Jan 11 23:58:27 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sat, 12 Jan 2013 16:58:27 +0900 Subject: [8]Review Request: 7162007: Clean up i18n related caches In-Reply-To: <50F0819E.1080306@oracle.com> References: <50F0819E.1080306@oracle.com> Message-ID: <50F117A3.9040309@oracle.com> Looks good to me. Masayoshi On 1/12/2013 6:18 AM, Naoto Sato wrote: > Hello, > > (To build-dev folks, I am sending this to you as the change includes > one modification in make directory. It is just simply adding a new > Java file, so I think it won't affect the new build-infra structure) > > Please review the changes for this issue: > > http://bugs.sun.com/view_bug.do?bug_id=7162007 > > Currently locale sensitive services cache their data in a very ad-hoc > manner, scattered everywhere. This issue intends to consolidate them > into a centralized location in sun.util.locale.provider package. > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/7162007/webrev.00/ > > Naoto From masayoshi.okutsu at oracle.com Tue Jan 15 23:21:41 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 16 Jan 2013 16:21:41 +0900 Subject: [8] Code review request: 4745761: (cal) RFE: Support builder for constructing Calendar Message-ID: <50F65505.6000205@oracle.com> Hello. This is a review request for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745761 Webrev: http://cr.openjdk.java.net/~okutsu/8/4745761/webrev.00/ Thanks, Masayoshi From yuka.kamiya at oracle.com Thu Jan 17 02:55:07 2013 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Thu, 17 Jan 2013 19:55:07 +0900 Subject: [8] Code review request: 4745761: (cal) RFE: Support builder for constructing Calendar In-Reply-To: <50F65505.6000205@oracle.com> References: <50F65505.6000205@oracle.com> Message-ID: <50F7D88B.4080003@oracle.com> HI, The fix looks ok to me. Thanks, -- Yuka (13/01/16 16:21), Masayoshi Okutsu wrote: > Hello. > > This is a review request for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4745761 > > Webrev: > http://cr.openjdk.java.net/~okutsu/8/4745761/webrev.00/ > > Thanks, > Masayoshi > From masayoshi.okutsu at oracle.com Sun Jan 20 08:28:29 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 21 Jan 2013 01:28:29 +0900 Subject: [8] Code review request: 8004489 and 8006509 Message-ID: <50FC1B2D.4020300@oracle.com> Hi, This is a code review request for two RFEs. http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004489 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006509 Webrev: http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.00/ I didn't add the resources starting with "cldr." to LocaleData this time. Those should be added when JSR 310 resources requirements get clearer. Thanks, Masayoshi From masayoshi.okutsu at oracle.com Sun Jan 20 21:34:23 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Mon, 21 Jan 2013 14:34:23 +0900 Subject: [8] Code review request: 8004489 and 8006509 In-Reply-To: <50FC1B2D.4020300@oracle.com> References: <50FC1B2D.4020300@oracle.com> Message-ID: <50FCD35F.508@oracle.com> I've updated the webrev to address some feedback. - Added @compile -XDignore.symbol.file to CldrFormatNamesTest.java - Added the Unicode copyright to FormatData_be.java, FormatData_is.java, and FormatData_zh_TW.java. - Removed a System.out.println for debugging from CLDR Converter tool. - Removed redundant variable initialization in CalendarDataUtility.normalizeCalendarType(String). Revised webrev: http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.01/ Thanks, Masayoshi On 1/21/2013 1:28 AM, Masayoshi Okutsu wrote: > Hi, > > This is a code review request for two RFEs. > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004489 > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006509 > > Webrev: > http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.00/ > > I didn't add the resources starting with "cldr." to LocaleData this > time. Those should be added when JSR 310 resources requirements get > clearer. > > Thanks, > Masayoshi > From yuka.kamiya at oracle.com Sun Jan 20 22:14:46 2013 From: yuka.kamiya at oracle.com (Yuka Kamiya) Date: Mon, 21 Jan 2013 15:14:46 +0900 Subject: [8] Code review request: 8004489 and 8006509 In-Reply-To: <50FCD35F.508@oracle.com> References: <50FC1B2D.4020300@oracle.com> <50FCD35F.508@oracle.com> Message-ID: <50FCDCD6.7050001@oracle.com> Hi, The fix looks ok to me. Thanks, -- Yuka (13/01/21 14:34), Masayoshi Okutsu wrote: > I've updated the webrev to address some feedback. > > - Added @compile -XDignore.symbol.file to CldrFormatNamesTest.java > > - Added the Unicode copyright to FormatData_be.java, FormatData_is.java, and FormatData_zh_TW.java. > > - Removed a System.out.println for debugging from CLDR Converter tool. > > - Removed redundant variable initialization in CalendarDataUtility.normalizeCalendarType(String). > > Revised webrev: > http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.01/ > > Thanks, > Masayoshi > > On 1/21/2013 1:28 AM, Masayoshi Okutsu wrote: >> Hi, >> >> This is a code review request for two RFEs. >> >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8004489 >> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=8006509 >> >> Webrev: >> http://cr.openjdk.java.net/~okutsu/8/8004489.8006509/webrev.00/ >> >> I didn't add the resources starting with "cldr." to LocaleData this time. Those should be added when JSR 310 resources requirements get clearer. >> >> Thanks, >> Masayoshi >> > From gitne at excite.co.jp Sun Jan 27 03:18:04 2013 From: gitne at excite.co.jp (=?ISO-2022-JP?B?SmFrb2IgV2lzb3I=?=) Date: Sun, 27 Jan 2013 20:18:04 +0900 Subject: =?iso-2022-jp?b?TmV3YmllIHF1ZXN0aW9ucw==?= Message-ID: <201301271118.r0RBI4oq029437@mail-web03.excite.co.jp> Hi there! I have been working with the javaws deployment tool recently and have noticed that it lacks a localization for Polish. So, I looked for the localized resource files and thought I could provide that. I was quickly able to localize javaws' syntax description in jre/lib/deploy/messages.properties. But I was a little bit stuck with the rest. After building a Polish ListResourceBundle based on deploy.jar/com/sun/deploy/resources/Deployment.class and successfully testing it, I was wondering whether the source code for the deployment tool is included in OpenJDK. Greping OpenJDK's source code brought no enlightenment. Is the deployment tool indeed not part of OpenJDK? If not, where should I send my patch for review to? Are there any plans or any intention to localize OpenJDK to other languages than the existing en, ja, and zh? Would localizations to de and pl be welcomed? If so, where should I send patches for review to (yes, I have read the contributors and faq sections, but I am still confused)? Is there any document governing policy on localizations? Regards Jacob From omajid at redhat.com Mon Jan 28 10:47:24 2013 From: omajid at redhat.com (Omair Majid) Date: Mon, 28 Jan 2013 13:47:24 -0500 Subject: Newbie questions In-Reply-To: <201301271118.r0RBI4oq029437@mail-web03.excite.co.jp> References: <201301271118.r0RBI4oq029437@mail-web03.excite.co.jp> Message-ID: <5106C7BC.1040205@redhat.com> Hi, On 01/27/2013 06:18 AM, Jakob Wisor wrote: > I have been working with the javaws deployment tool recently and have > noticed that it lacks a localization for Polish. So, I looked for the > localized resource files and thought I could provide that. I was > quickly able to localize javaws' syntax description in > jre/lib/deploy/messages.properties. But I was a little bit stuck with > the rest. After building a Polish ListResourceBundle based on > deploy.jar/com/sun/deploy/resources/Deployment.class and successfully > testing it, I was wondering whether the source code for the > deployment tool is included in OpenJDK. Greping OpenJDK's source code > brought no enlightenment. Is the deployment tool indeed not part of > OpenJDK? If not, where should I send my patch for review to? You are correct: OpenJDK does not include the source for javaws. The javaws implementation that is shipped with Oracle's JDK/JRE is proprietary. I don't know where you would send patches for that. Some of us are working on an open source implementation of javaws, called IcedTea-Web [1], that does include include the source and accepts localization patches for any language. It is not included in OpenJDK, though most Linux distributions do ship it along with OpenJDK as the plugin and javaws implementation. We normally hang out on distro-pkg-dev at openjdk.java.net (cc'ed). > Are there any plans or any intention to localize OpenJDK to other > languages than the existing en, ja, and zh? Would localizations to de > and pl be welcomed? If so, where should I send patches for review to > (yes, I have read the contributors and faq sections, but I am still > confused)? I can't speak for OpenJDK, but for IcedTea-Web, we are willing to localize to any language that you can provide translations for. distro-pkg-dev at openjdk.java.net is the right place for any patches for IcedTea-Web. Thanks, Omair [1] http://icedtea.classpath.org/wiki/IcedTea-Web -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From dingxmin at linux.vnet.ibm.com Tue Jan 29 21:34:10 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Wed, 30 Jan 2013 13:34:10 +0800 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <5107689A.8030604@linux.vnet.ibm.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> Message-ID: <5108B0D2.9070106@linux.vnet.ibm.com> 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 good (that's why I approved the change in jdk8), > I don't find any reason for backporting this change into 7u line. Is > there any strong reason for backport? > > Naoto > > On 9/18/12 10:37 AM, Se?n Coffey wrote: > > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. > > Was it possible to verify this fix on jdk7u Shi Jun ? > > > > Any thoughts from i18n reviewers on this one being backported to 7u ? > > > > regards, > > Sean. > > > > On 17/09/2012 08:07, Shi Jun Zhang wrote: > >> Hi all, > >> > >> I'd like to request for approval to push the following change into 7u10. > >> > >> Changeset in jdk8 > >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 > >> > >> Webrev > >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ > >> > >> Reviewed by anthony, naoto > >> > >> Review thread > >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html > >> > > > > > From naoto.sato at oracle.com Wed Jan 30 11:15:48 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 30 Jan 2013 11:15:48 -0800 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <5108B0D2.9070106@linux.vnet.ibm.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> <5108B0D2.9070106@linux.vnet.ibm.com> Message-ID: <51097164.9080105@oracle.com> 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. Please let me > know if there is any idea. Thank you. > > Best regards, > Frank >> While I think fix looks good (that's why I approved the change in jdk8), >> I don't find any reason for backporting this change into 7u line. Is >> there any strong reason for backport? >> >> Naoto >> >> On 9/18/12 10:37 AM, Se?n Coffey wrote: >> > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. >> > Was it possible to verify this fix on jdk7u Shi Jun ? >> > >> > Any thoughts from i18n reviewers on this one being backported to 7u ? >> > >> > regards, >> > Sean. >> > >> > On 17/09/2012 08:07, Shi Jun Zhang wrote: >> >> Hi all, >> >> >> >> I'd like to request for approval to push the following change into >> 7u10. >> >> >> >> Changeset in jdk8 >> >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 >> >> >> >> Webrev >> >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ >> >> >> >> Reviewed by anthony, naoto >> >> >> >> Review thread >> >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html >> >> >> > >> >> >> > From naoto.sato at oracle.com Wed Jan 30 14:02:04 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 30 Jan 2013 14:02:04 -0800 Subject: [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono Message-ID: <5109985C.50805@oracle.com> 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 From masayoshi.okutsu at oracle.com Wed Jan 30 18:01:16 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 31 Jan 2013 11:01:16 +0900 Subject: [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono In-Reply-To: <5109985C.50805@oracle.com> References: <5109985C.50805@oracle.com> Message-ID: <5109D06C.30200@oracle.com> 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 From dingxmin at linux.vnet.ibm.com Wed Jan 30 18:08:27 2013 From: dingxmin at linux.vnet.ibm.com (Frank Ding) Date: Thu, 31 Jan 2013 10:08:27 +0800 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <51097164.9080105@oracle.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> <5108B0D2.9070106@linux.vnet.ibm.com> <51097164.9080105@oracle.com> Message-ID: <5109D21B.6080406@linux.vnet.ibm.com> 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 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 good (that's why I approved the change in >>> jdk8), >>> I don't find any reason for backporting this change into 7u line. Is >>> there any strong reason for backport? >>> >>> Naoto >>> >>> On 9/18/12 10:37 AM, Se?n Coffey wrote: >>> > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. >>> > Was it possible to verify this fix on jdk7u Shi Jun ? >>> > >>> > Any thoughts from i18n reviewers on this one being backported to 7u ? >>> > >>> > regards, >>> > Sean. >>> > >>> > On 17/09/2012 08:07, Shi Jun Zhang wrote: >>> >> Hi all, >>> >> >>> >> I'd like to request for approval to push the following change into >>> 7u10. >>> >> >>> >> Changeset in jdk8 >>> >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 >>> >> >>> >> Webrev >>> >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ >>> >> >>> >> Reviewed by anthony, naoto >>> >> >>> >> Review thread >>> >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html >>> >> >>> > >>> >>> >>> >> > From naoto.sato at oracle.com Wed Jan 30 18:49:05 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 30 Jan 2013 18:49:05 -0800 Subject: [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono In-Reply-To: <5109D06C.30200@oracle.com> References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com> Message-ID: <5109DBA1.4000109@oracle.com> 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 > From naoto.sato at oracle.com Wed Jan 30 22:31:09 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 30 Jan 2013 22:31:09 -0800 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <5109D21B.6080406@linux.vnet.ibm.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> <5108B0D2.9070106@linux.vnet.ibm.com> <51097164.9080105@oracle.com> <5109D21B.6080406@linux.vnet.ibm.com> Message-ID: <510A0FAD.1020501@oracle.com> 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 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. Please let me >>> know if there is any idea. Thank you. >>> >>> Best regards, >>> Frank >>>> While I think fix looks good (that's why I approved the change in >>>> jdk8), >>>> I don't find any reason for backporting this change into 7u line. Is >>>> there any strong reason for backport? >>>> >>>> Naoto >>>> >>>> On 9/18/12 10:37 AM, Se?n Coffey wrote: >>>> > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. >>>> > Was it possible to verify this fix on jdk7u Shi Jun ? >>>> > >>>> > Any thoughts from i18n reviewers on this one being backported to 7u ? >>>> > >>>> > regards, >>>> > Sean. >>>> > >>>> > On 17/09/2012 08:07, Shi Jun Zhang wrote: >>>> >> Hi all, >>>> >> >>>> >> I'd like to request for approval to push the following change into >>>> 7u10. >>>> >> >>>> >> Changeset in jdk8 >>>> >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 >>>> >> >>>> >> Webrev >>>> >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ >>>> >> >>>> >> Reviewed by anthony, naoto >>>> >> >>>> >> Review thread >>>> >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html >>>> >> >>>> > >>>> >>>> >>>> >>> >> > From yuri.nesterenko at oracle.com Wed Jan 30 23:02:46 2013 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Thu, 31 Jan 2013 11:02:46 +0400 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <5109D21B.6080406@linux.vnet.ibm.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> <5108B0D2.9070106@linux.vnet.ibm.com> <51097164.9080105@oracle.com> <5109D21B.6080406@linux.vnet.ibm.com> Message-ID: <510A1716.9070308@oracle.com> 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, 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 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. Please let me >>> know if there is any idea. Thank you. >>> >>> Best regards, >>> Frank >>>> While I think fix looks good (that's why I approved the change in >>>> jdk8), >>>> I don't find any reason for backporting this change into 7u line. Is >>>> there any strong reason for backport? >>>> >>>> Naoto >>>> >>>> On 9/18/12 10:37 AM, Se?n Coffey wrote: >>>> > cc'ing i18n-dev alias here also. i18n fixes can be difficult to test. >>>> > Was it possible to verify this fix on jdk7u Shi Jun ? >>>> > >>>> > Any thoughts from i18n reviewers on this one being backported to 7u ? >>>> > >>>> > regards, >>>> > Sean. >>>> > >>>> > On 17/09/2012 08:07, Shi Jun Zhang wrote: >>>> >> Hi all, >>>> >> >>>> >> I'd like to request for approval to push the following change into >>>> 7u10. >>>> >> >>>> >> Changeset in jdk8 >>>> >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 >>>> >> >>>> >> Webrev >>>> >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ >>>> >> >>>> >> Reviewed by anthony, naoto >>>> >> >>>> >> Review thread >>>> >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html >>>> >> >>>> > >>>> >>>> >>>> >>> >> > From masayoshi.okutsu at oracle.com Wed Jan 30 23:19:00 2013 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 31 Jan 2013 16:19:00 +0900 Subject: [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono In-Reply-To: <5109DBA1.4000109@oracle.com> References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com> <5109DBA1.4000109@oracle.com> Message-ID: <510A1AE4.1020606@oracle.com> 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 >> > From sean.coffey at oracle.com Thu Jan 31 01:43:05 2013 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Thu, 31 Jan 2013 09:43:05 +0000 Subject: Fwd: Re: [7u10] Request for approval: 7174233: Openjdk is missing some key maps on the Japanese keyboards In-Reply-To: <510A1716.9070308@oracle.com> References: <5058C769.2050005@oracle.com> <5107689A.8030604@linux.vnet.ibm.com> <5108B0D2.9070106@linux.vnet.ibm.com> <51097164.9080105@oracle.com> <5109D21B.6080406@linux.vnet.ibm.com> <510A1716.9070308@oracle.com> Message-ID: <510A3CA9.3070608@oracle.com> Yuri, that java code is normally auto generated with the src/solaris/classes/sun/awt/X11/genhash.awk file : # With this script one can generate a new version XKeysym.java file out # of keysym2ucs.h prototype and UnicodeData.txt database. # Latter file should be fetched from a unicode.org site, most # probably http://www.unicode.org/Public/UNIDATA/UnicodeData.txt Since the same approach (manual update) was taken for jdk8 fix, I suspect it should work for 7u also. Frank - can you address Yuri's question? Let's wait for confirmation from Yuri also on whether he's ok with this port and if there are no objections, Iet's consider this approved for jdk7u-dev. Please provide a testcase if possible. I'm also assuming that you'll verify the fix in a Japanese locale before pushing. regards, Sean. On 31/01/2013 07:02, Yuri Nesterenko wrote: > 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, 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 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. Please let me >>>> know if there is any idea. Thank you. >>>> >>>> Best regards, >>>> Frank >>>>> While I think fix looks good (that's why I approved the change in >>>>> jdk8), >>>>> I don't find any reason for backporting this change into 7u line. Is >>>>> there any strong reason for backport? >>>>> >>>>> Naoto >>>>> >>>>> On 9/18/12 10:37 AM, Se?n Coffey wrote: >>>>> > cc'ing i18n-dev alias here also. i18n fixes can be difficult to >>>>> test. >>>>> > Was it possible to verify this fix on jdk7u Shi Jun ? >>>>> > >>>>> > Any thoughts from i18n reviewers on this one being backported to >>>>> 7u ? >>>>> > >>>>> > regards, >>>>> > Sean. >>>>> > >>>>> > On 17/09/2012 08:07, Shi Jun Zhang wrote: >>>>> >> Hi all, >>>>> >> >>>>> >> I'd like to request for approval to push the following change into >>>>> 7u10. >>>>> >> >>>>> >> Changeset in jdk8 >>>>> >>http://hg.openjdk.java.net/jdk8/awt/jdk/rev/6694d9e99716 >>>>> >> >>>>> >> Webrev >>>>> >>http://cr.openjdk.java.net/~zhangshj/jdk7u/7174233/webrev.00/ >>>>> >> >>>>> >> Reviewed by anthony, naoto >>>>> >> >>>>> >> Review thread >>>>> >>http://mail.openjdk.java.net/pipermail/awt-dev/2012-June/002919.html >>>>> >>>>> >> >>>>> > >>>>> >>>>> >>>>> >>>> >>> >> > From naoto.sato at oracle.com Thu Jan 31 10:54:37 2013 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 31 Jan 2013 10:54:37 -0800 Subject: [8]Request for Review: 8007038: ArrayIndexOutOfBoundsException on calling localizedDateTime().print() with JapaneseChrono In-Reply-To: <510A1AE4.1020606@oracle.com> References: <5109985C.50805@oracle.com> <5109D06C.30200@oracle.com> <5109DBA1.4000109@oracle.com> <510A1AE4.1020606@oracle.com> Message-ID: <510ABDED.8080603@oracle.com> 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 >>> >> > From yong.huang at oracle.com Thu Jan 31 19:20:45 2013 From: yong.huang at oracle.com (Yong Jeffrey Huang) Date: Fri, 01 Feb 2013 11:20:45 +0800 Subject: Review Request: 8006748 Message-ID: <510B348D.1080306@oracle.com> Hello, This is the review request for https://jbs.oracle.com/bugs/browse/JDK-8006748. http://cr.openjdk.java.net/~yhuang/8006748/webrev.00/ Regression test is in closed repository. I will send it separately. thanks, Yong