From naoto.sato at oracle.com Thu Nov 1 18:11:50 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 11:11:50 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character Message-ID: <384430af-6edd-e499-e004-622db81a7011@oracle.com> Hello, Please review a javadoc fix to this issue: https://bugs.openjdk.java.net/browse/JDK-8213046 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ This is to clarify the previously pushed change (8211398) in the javadoc of Character class. Naoto From lance.andersen at oracle.com Thu Nov 1 18:26:14 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 14:26:14 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <384430af-6edd-e499-e004-622db81a7011@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> Message-ID: <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Hi Naoto + * The code point, U+32FF, is reserved by the Unicode Consortium + * to represent the Japanese square character for the new era that begins + * from May, 2019. Relevant methods in the Character class return the same + * properties as for the existing Japanese era characters (e.g., U+337E for + * "Meizi"). For the details of the code point, refer to + * + * http://blog.unicode.org/2018/09/new-japanese-era.html Is ?from? needed in the the above or could it be ? era that begins May, 2019 ? Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change > On Nov 1, 2018, at 2:11 PM, Naoto Sato wrote: > > Hello, > > Please review a javadoc fix to this issue: > > https://bugs.openjdk.java.net/browse/JDK-8213046 > > The proposed change is located at: > > http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ > > This is to clarify the previously pushed change (8211398) in the javadoc of Character class. > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Thu Nov 1 18:31:00 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 11:31:00 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: Hi Lance, On 11/1/18 11:26 AM, Lance Andersen wrote: > Hi Naoto > > + * The code point, U+32FF, is reserved by the Unicode Consortium > + * to represent the Japanese square character for the new era that begins > + **from* May, 2019. Relevant methods in the Character class return the same > + * properties as for the existing Japanese era characters (e.g., U+337E for > + * "Meizi"). For the details of the code point, refer to > + * > + *http://blog.unicode.org/2018/09/new-japanese-era.html > > > > > Is ?from? needed in the the above or could it be > > ? era that begins May, 2019 ? OK, will remove that "from". > > > Also is there a change that the URL for the blog could disappear or are > they typically a constant and do not change That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. Naoto > > >> On Nov 1, 2018, at 2:11 PM, Naoto Sato > > wrote: >> >> Hello, >> >> Please review a javadoc fix to this issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8213046 >> >> The proposed change is located at: >> >> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >> >> This is to clarify the previously pushed change (8211398) in the >> javadoc of Character class. >> >> Naoto > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From naoto.sato at oracle.com Thu Nov 1 19:53:51 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 12:53:51 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: Updated the webrev. Dropped the "," after "May" too. http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ Naoto On 11/1/18 11:31 AM, Naoto Sato wrote: > Hi Lance, > > On 11/1/18 11:26 AM, Lance Andersen wrote: >> Hi Naoto >> >> + * The code point, U+32FF, is reserved by the Unicode Consortium >> + * to represent the Japanese square character for the new era that >> begins >> + **from*? May, 2019. Relevant methods in the Character class return >> the same >> + * properties as for the existing Japanese era characters (e.g., >> U+337E for >> + * "Meizi"). For the details of the code point, refer to >> + * >> + *http://blog.unicode.org/2018/09/new-japanese-era.html >> >> >> >> >> Is ?from? needed in the the above or could it be >> >> ? era that begins May, 2019 ? > > OK, will remove that "from". > >> >> >> Also is there a change that the URL for the blog could disappear or >> are they typically a constant and do not change > > That blog is an official one from Unicode Consortium. The subtitle of it > reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE > UNICODE CONSORTIUM", so I don't expect the entry to disappear without > any apparent reason. > > Naoto > >> >> >>> On Nov 1, 2018, at 2:11 PM, Naoto Sato >> > wrote: >>> >>> Hello, >>> >>> Please review a javadoc fix to this issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>> >>> The proposed change is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>> >>> This is to clarify the previously pushed change (8211398) in the >>> javadoc of Character class. >>> >>> Naoto >> >> >> >> >> Lance >> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle?Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com >> >> >> From lance.andersen at oracle.com Thu Nov 1 20:03:22 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 16:03:22 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> Message-ID: <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Looks better. Unless it is my eyes, the period seems missing after the blog URL. > On Nov 1, 2018, at 3:53 PM, Naoto Sato wrote: > > Updated the webrev. Dropped the "," after "May" too. > > http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ > > Naoto > > On 11/1/18 11:31 AM, Naoto Sato wrote: >> Hi Lance, >> On 11/1/18 11:26 AM, Lance Andersen wrote: >>> Hi Naoto >>> >>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>> + * to represent the Japanese square character for the new era that begins >>> + **from* May, 2019. Relevant methods in the Character class return the same >>> + * properties as for the existing Japanese era characters (e.g., U+337E for >>> + * "Meizi"). For the details of the code point, refer to >>> + * >>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>> >>> >>> >>> Is ?from? needed in the the above or could it be >>> >>> ? era that begins May, 2019 ? >> OK, will remove that "from". >>> >>> >>> Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change >> That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. >> Naoto >>> >>> >>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato > wrote: >>>> >>>> Hello, >>>> >>>> Please review a javadoc fix to this issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>> >>>> The proposed change is located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>> >>>> This is to clarify the previously pushed change (8211398) in the javadoc of Character class. >>>> >>>> Naoto >>> >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>> Oracle Java Engineering >>> 1 Network Drive >>> Burlington, MA 01803 >>> Lance.Andersen at oracle.com >>> >>> >>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Thu Nov 1 20:51:19 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 1 Nov 2018 13:51:19 -0700 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Message-ID: Indeed. Added the period. http://cr.openjdk.java.net/~naoto/8213046/webrev.02/ Naoto On 11/1/18 1:03 PM, Lance Andersen wrote: > Looks better. ?Unless it is my eyes, the period seems missing after the > blog URL. > > >> On Nov 1, 2018, at 3:53 PM, Naoto Sato > > wrote: >> >> Updated the webrev. Dropped the "," after "May" too. >> >> http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ >> >> >> Naoto >> >> On 11/1/18 11:31 AM, Naoto Sato wrote: >>> Hi Lance, >>> On 11/1/18 11:26 AM, Lance Andersen wrote: >>>> Hi Naoto >>>> >>>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>>> + * to represent the Japanese square character for the new era that >>>> begins >>>> + **from*? May, 2019. Relevant methods in the Character class return >>>> the same >>>> + * properties as for the existing Japanese era characters (e.g., >>>> U+337E for >>>> + * "Meizi"). For the details of the code point, refer to >>>> + * >>>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>>> >>>> >>>> >>>> >>>> Is ?from? needed in the the above or could it be >>>> >>>> ? era that begins May, 2019 ? >>> OK, will remove that "from". >>>> >>>> >>>> Also is there a change that the URL for the blog could disappear or >>>> are they typically a constant and do not change >>> That blog is an official one from Unicode Consortium. The subtitle of >>> it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES >>> FROM THE UNICODE CONSORTIUM", so I don't expect the entry to >>> disappear without any apparent reason. >>> Naoto >>>> >>>> >>>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato >>>> > wrote: >>>>> >>>>> Hello, >>>>> >>>>> Please review a javadoc fix to this issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>>> >>>>> The proposed change is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>>> >>>>> This is to clarify the previously pushed change (8211398) in the >>>>> javadoc of Character class. >>>>> >>>>> Naoto >>>> >>>> >>>> >>>> >>>> Lance >>>> Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>> Oracle?Java Engineering >>>> 1 Network Drive >>>> Burlington, MA 01803 >>>> Lance.Andersen at oracle.com >>>> >>>> >>>> > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From lance.andersen at oracle.com Thu Nov 1 20:55:14 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 1 Nov 2018 16:55:14 -0400 Subject: [12] RFR: 8213046: Define Japanese new Era character In-Reply-To: References: <384430af-6edd-e499-e004-622db81a7011@oracle.com> <07C6D1E4-7D13-4F46-815C-E6C7020C7C18@oracle.com> <2CACDC2C-DD65-4FD3-9D8B-5089C7121026@oracle.com> Message-ID: <841AB14C-603F-47A0-8823-E865FA712794@oracle.com> ship it :-) > On Nov 1, 2018, at 4:51 PM, Naoto Sato wrote: > > Indeed. Added the period. > > http://cr.openjdk.java.net/~naoto/8213046/webrev.02/ > > Naoto > > On 11/1/18 1:03 PM, Lance Andersen wrote: >> Looks better. Unless it is my eyes, the period seems missing after the blog URL. >>> On Nov 1, 2018, at 3:53 PM, Naoto Sato > wrote: >>> >>> Updated the webrev. Dropped the "," after "May" too. >>> >>> http://cr.openjdk.java.net/~naoto/8213046/webrev.01/ >>> >>> Naoto >>> >>> On 11/1/18 11:31 AM, Naoto Sato wrote: >>>> Hi Lance, >>>> On 11/1/18 11:26 AM, Lance Andersen wrote: >>>>> Hi Naoto >>>>> >>>>> + * The code point, U+32FF, is reserved by the Unicode Consortium >>>>> + * to represent the Japanese square character for the new era that begins >>>>> + **from* May, 2019. Relevant methods in the Character class return the same >>>>> + * properties as for the existing Japanese era characters (e.g., U+337E for >>>>> + * "Meizi"). For the details of the code point, refer to >>>>> + * >>>>> + *http://blog.unicode.org/2018/09/new-japanese-era.html >>>>> >>>>> >>>>> >>>>> Is ?from? needed in the the above or could it be >>>>> >>>>> ? era that begins May, 2019 ? >>>> OK, will remove that "from". >>>>> >>>>> >>>>> Also is there a change that the URL for the blog could disappear or are they typically a constant and do not change >>>> That blog is an official one from Unicode Consortium. The subtitle of it reads "NEWS, ANNOUNCEMENTS, RELEASE INFO, AND CALENDAR UPDATES FROM THE UNICODE CONSORTIUM", so I don't expect the entry to disappear without any apparent reason. >>>> Naoto >>>>> >>>>> >>>>>> On Nov 1, 2018, at 2:11 PM, Naoto Sato > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> Please review a javadoc fix to this issue: >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8213046 >>>>>> >>>>>> The proposed change is located at: >>>>>> >>>>>> http://cr.openjdk.java.net/~naoto/8213046/webrev.00/ >>>>>> >>>>>> This is to clarify the previously pushed change (8211398) in the javadoc of Character class. >>>>>> >>>>>> Naoto >>>>> >>>>> >>>>> >>>>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >>>>> Oracle Java Engineering >>>>> 1 Network Drive >>>>> Burlington, MA 01803 >>>>> Lance.Andersen at oracle.com >>>>> >>>>> >>>>> >> >> >> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 >> Oracle Java Engineering >> 1 Network Drive >> Burlington, MA 01803 >> Lance.Andersen at oracle.com Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From naoto.sato at oracle.com Sat Nov 3 00:10:17 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 2 Nov 2018 17:10:17 -0700 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8213330 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ It is to remove "Classpath exception" copyright phrase from i18n related test files. Naoto From lance.andersen at oracle.com Sat Nov 3 13:12:48 2018 From: lance.andersen at oracle.com (Lance Andersen) Date: Sat, 3 Nov 2018 09:12:48 -0400 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests In-Reply-To: References: Message-ID: Hi Naoto Looks good over all. One question: I noticed that some of the files had a copyright date and others did not. For example: test/jdk/sun/util/calendar/zi/tzdata/gmt has a copyright test/jdk/sun/util/calendar/zi/tzdata/factory does not If this is not by design, perhaps this should be addressed as part of the put back? Best Lance > On Nov 2, 2018, at 8:10 PM, naoto.sato at oracle.com wrote: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8213330 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ > > It is to remove "Classpath exception" copyright phrase from i18n related test files. > > Naoto Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From deepak.kejriwal at oracle.com Mon Nov 5 06:26:51 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Sun, 4 Nov 2018 22:26:51 -0800 (PST) Subject: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology Message-ID: Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8171049 Webrev: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ Master Bug changeset and Review details: JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/965d4dde0086 JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/049037.html New test file "TestEraDisplayName.java" added as part of fix is modified as per jdk 8 release:- . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly. Regards, Deepak From naoto.sato at oracle.com Mon Nov 5 18:27:44 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 5 Nov 2018 10:27:44 -0800 Subject: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology In-Reply-To: References: Message-ID: <649f938c-e335-a58d-ebbc-f29095d8eb91@oracle.com> Looks good. Since you modified the test case, please add the copyright year 2018 in the test case before you push. Naoto On 11/4/18 10:26 PM, Deepak Kejriwal wrote: > Hi all, > > > > Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8171049 > > Webrev: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ > > > > Master Bug changeset and Review details: > > JDK Change set: http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/965d4dde0086 > > JDK Review Thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/049037.html > > > > New test file "TestEraDisplayName.java" added as part of fix is modified as per jdk 8 release:- > > > > . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. > > . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly. > > > > Regards, > > Deepak > From naoto.sato at oracle.com Mon Nov 5 19:12:14 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 5 Nov 2018 11:12:14 -0800 Subject: [12] RFR: 8213330: Fix legal headers in i18n tests In-Reply-To: References: Message-ID: <259cc590-9c52-e3fc-d8ff-d8d5f7c9a8b6@oracle.com> Hi Lance, On 11/3/18 6:12 AM, Lance Andersen wrote: > Hi Naoto > > Looks good over all. > > One question: > > * I noticed that some of the files had a copyright date and others did > not. ?For example: > o test/jdk/sun/util/calendar/zi/tzdata/gmt ?has a copyright > o test/jdk/sun/util/calendar/zi/tzdata/factory does not > > If this is not by design, perhaps this?should be addressed as part of > the put ?back? Yes, I noticed that too. I don't know any history of these files, so I left it unmodified, as the initial year is unknown. Naoto > > Best > Lance > >> On Nov 2, 2018, at 8:10 PM, naoto.sato at oracle.com >> wrote: >> >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8213330 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8213330/webrev.00/ >> >> It is to remove "Classpath exception" copyright phrase from i18n >> related test files. >> >> Naoto > > > > Lance Andersen| > Principal Member of Technical Staff | +1.781.442.2037 > Oracle?Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From TOSHIONA at jp.ibm.com Tue Nov 6 09:19:15 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Tue, 6 Nov 2018 18:19:15 +0900 Subject: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting Message-ID: Hello, Can I obtain a sponsor of this proposal about InputMethod issue on Linux? Bug: https://bugs.openjdk.java.net/browse/JDK-8213183 Webrev: http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/ I've got an author role and filled the bug report. Please refer the attached mail about the detail of this patch. Best Regards, Toshio Nakamura ----- Forwarded by Toshio 5 Nakamura/Japan/IBM on 2018/11/06 18:08 ----- From: "Toshio 5 Nakamura" To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net Date: 2018/06/26 17:46 Subject: Proposal: Input Method re-connection Sent by: "awt-dev" Hello, I'd like to contribute a proposal about Input Method (IM) re-connection on Linux. This is a part of contribution of IBM enhancements. Issue: After IM process (fcitx, kinput2, etc.) was down, Java GUI application cannot use it even if IM process is restarted. This change try to re-connect IM when its process was restarted on Linux. Description of changes: - XRegisterIMInstantiateCallback is set in DestroyXIMCallback. - Saved the latest activated X11InputMethod instance and use it to call its activate method in the instantiate callback. - XSelectInput in XMSelection.java may reset the XRegisterIMInstantiateCallback entry, so it's changed to keep the current registers. Patch: http://cr.openjdk.java.net/~aleonard/im_resume/webrev.00/ (I asked my colleague to store my patch for easy reference. I'm a contributor and need a sponsor of the proposal.) Could I ask someone to kindly become a sponsor of this proposal? Thanks, Toshio Nakamura, IBM Japan From deepak.kejriwal at oracle.com Wed Nov 7 12:09:28 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Wed, 7 Nov 2018 04:09:28 -0800 (PST) Subject: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology In-Reply-To: <649f938c-e335-a58d-ebbc-f29095d8eb91@oracle.com> References: <649f938c-e335-a58d-ebbc-f29095d8eb91@oracle.com> Message-ID: <0bec2b37-a5f6-4b37-959a-cd98f8a16be9@default> Hi Naoto, Thanks for reviewing the fix. As you mentioned in review comment, I will add the copyright year 2018 in test case. Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Monday, November 5, 2018 11:58 PM To: Deepak Kejriwal ; core-libs-dev ; i18n-dev at openjdk.java.net Subject: Re: RFR: JDK8U Backport of 8171049: Era.getDisplayName doesn't work with non-IsoChronology Looks good. Since you modified the test case, please add the copyright year 2018 in the test case before you push. Naoto On 11/4/18 10:26 PM, Deepak Kejriwal wrote: > Hi all, > > > > Please review the fix for JDK8u Backport of > https://bugs.openjdk.java.net/browse/JDK-8171049 > > Webrev: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ > > > > Master Bug changeset and Review details: > > JDK Change set: > http://hg.openjdk.java.net/jdk10/jdk10/jdk/rev/965d4dde0086 > > JDK Review Thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/04903 > 7.html > > > > New test file "TestEraDisplayName.java" added as part of fix is > modified as per jdk 8 release:- > > > > . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. > > . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly. > > > > Regards, > > Deepak > From deepak.kejriwal at oracle.com Thu Nov 8 15:02:47 2018 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Thu, 8 Nov 2018 07:02:47 -0800 (PST) Subject: [8u] Request for Approval : Backport of 8171049 : Era.getDisplayName doesn't work with non-IsoChronology Message-ID: <1e9752c6-7aa4-4895-bd69-a9a76b5eb826@default> Hi, Please approve the backport of JDK-8171049 to 8u-dev. Master bug : https://bugs.openjdk.java.net/browse/JDK-8171049 Webrev for [8u-dev]: http://cr.openjdk.java.net/~rpatil/8171049/webrev.00/ JDK Review Thread: http://mail.openjdk.java.net/pipermail/i18n-dev/2018-November/002682.html Master Bug Change set: http://hg.openjdk.java.net/jdk/jdk/rev/8dfed4387312 Master Review Thread : http://mail.openjdk.java.net/pipermail/core-libs-dev/2017-August/049037.html Summary: The fix was clean backport but new test file "TestEraDisplayName.java" added as part of fix is modified as per jdk 8 release:- . All test written in jdk 10 are written to verify the CLDR resource. Since, in case of jdk 8 "CLDR" is not default locale providers, added Djava.locale.providers=CLDR as JVM parameter to test. . Some resource keys in jdk 8 does not exist in both CLDR and JRE due to which Era.getDisplayName() returns numeric value. Modified such test cases accordingly All the related testing is done and is a pass. Regards, Deepak From Sergey.Bylokhov at oracle.com Sat Nov 10 03:46:14 2018 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 9 Nov 2018 19:46:14 -0800 Subject: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting In-Reply-To: References: Message-ID: <8dc96063-e998-6fd4-fca7-d7e597dc1352@oracle.com> Hi, Toshio. Can you please add the steps to reproduce to the bug description. On 06/11/2018 01:19, Toshio 5 Nakamura wrote: > Hello, > > Can I obtain a sponsor of this proposal about InputMethod issue on Linux? > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8213183 > Webrev: > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/ > > I've got an author role and filled the bug report. > Please refer the attached mail about the detail of this patch. > > Best Regards, > Toshio Nakamura > > ----- Forwarded by Toshio 5 Nakamura/Japan/IBMon 2018/11/06 18:08----- > > From: "Toshio 5 Nakamura" > To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/06/26 17:46 > Subject: Proposal: Input Method re-connection > Sent by: "awt-dev" > > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ > > > > Hello, > > I'd like to contribute a proposal about Input Method (IM) re-connection > on Linux. This is a part of contribution of IBM enhancements. > > Issue: > After IM process (fcitx, kinput2, etc.) was down, Java GUI application > cannot use it even if IM process is restarted. This change try to > re-connect IM when its process was restarted on Linux. > > Description of changes: > - XRegisterIMInstantiateCallback is set in DestroyXIMCallback. > - Saved the latest activated X11InputMethod instance and use it to > call its activate method in the instantiate callback. > - XSelectInput in XMSelection.java may reset the > XRegisterIMInstantiateCallback entry, so it's changed to keep the > current registers. > > Patch:_ > __http://cr.openjdk.java.net/~aleonard/im_resume/webrev.00/_ > (I asked my colleague to store my patch for easy reference. > I'm a contributor and need a sponsor of the proposal.) > > Could I ask someone to kindly become a sponsor of this proposal? > > Thanks, > Toshio Nakamura, IBM Japan > -- Best regards, Sergey. From takiguc at linux.vnet.ibm.com Wed Nov 14 18:11:57 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 15 Nov 2018 03:11:57 +0900 Subject: Fwd: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset Message-ID: <8763927aab93dedfe07189845776cf53@linux.vnet.ibm.com> Hello. Martin Buchholz suggested me via bugs.openjdk.java.net, I should not touch non AIX side. So I rewrote another code. Could you review the fix again ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.01/ I don't want to touch non AIX side code, but I need to rename 3 files to avoid compilation issue. IBM33722.java -> IBM33722.java.template IBM964.java -> IBM964.java.template SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template Thanks, Ichiroh Takiguchi IBM Japan, Ltd. -------- Original Message -------- Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset Date: 2018-11-08 20:13 From: Volker Simonis To: Ichiroh Takiguchi Cc: Java Core Libs , ppc-aix-port-dev at openjdk.java.net, "SHEN, XUEMING" , Alan Bateman Hi Ichiroh, sorry, but unfortunately, this change is way beyond my level of expertise :) You should try to get a review from Sherman or Alan. Regards, Volker On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi wrote: > > Hello. > > Could you review the fix ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/ > > I'd like to obtain a sponsor for this issue. > > > IBM964 charset and IBM29626C charset are required for default charset > on AIX zh_TW and ja_JP locale. > OpenJDK already has IBM964, but it could not be configured for default > charset. > IBM29626C is new one. > (IBM33722 extends IBM29626C class) > > I knew IBM charsets would need to move to somewhere. > The discussion was started by "Adding new IBM extended charsets". [1] > But it's related default charset issue. > Please put them inside of OpenJDK. > > About IBM964, > Bhaktavatsal started the discussion [2]. > Sherman said that [3] > the new model (open/make/data/charetmapping), instead of hard-coding > the map > into the source code. > > This fix only has small sized hard-coded mapping, > IBM964/IBM29626C/IBM33722 refer other charsets conversion table > which are using the new model. > And class file is smaller then before. > Still I used SimpleEUCEncoder class because it's stable. > I think we may re-write it by IBM charsets renewal. > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html > [2] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html > [3] > http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html > From takiguc at linux.vnet.ibm.com Wed Nov 14 18:20:20 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Thu, 15 Nov 2018 03:20:20 +0900 Subject: Fwd: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX default charset In-Reply-To: <8763927aab93dedfe07189845776cf53@linux.vnet.ibm.com> References: <8763927aab93dedfe07189845776cf53@linux.vnet.ibm.com> Message-ID: <05e10841d7389dfcb6b33a07d3b9b9bf@linux.vnet.ibm.com> I'm very sorry for your confusion, please ignore previous mail. I posted it on wrong mailing list. Ichiroh Takiguchi On 2018-11-15 03:11, Ichiroh Takiguchi wrote: > Hello. > > Martin Buchholz suggested me via bugs.openjdk.java.net, > I should not touch non AIX side. > So I rewrote another code. > Could you review the fix again ? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 > Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.01/ > > I don't want to touch non AIX side code, but I need to rename 3 files > to avoid compilation issue. > IBM33722.java -> IBM33722.java.template > IBM964.java -> IBM964.java.template > SimpleEUCEncoder.java -> SimpleEUCEncoder.java.template > > Thanks, > Ichiroh Takiguchi > IBM Japan, Ltd. > > -------- Original Message -------- > Subject: Re: RFR: 8212794 IBM-964 and IBM-29626C are required for AIX > default charset > Date: 2018-11-08 20:13 > From: Volker Simonis > To: Ichiroh Takiguchi > Cc: Java Core Libs , > ppc-aix-port-dev at openjdk.java.net, "SHEN, XUEMING" > , Alan Bateman > > > Hi Ichiroh, > > sorry, but unfortunately, this change is way beyond my level of > expertise :) > > You should try to get a review from Sherman or Alan. > > Regards, > Volker > On Fri, Oct 26, 2018 at 3:33 PM Ichiroh Takiguchi > wrote: >> >> Hello. >> >> Could you review the fix ? >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8212794 >> Change: https://cr.openjdk.java.net/~itakiguchi/8212794/webrev.00/ >> >> I'd like to obtain a sponsor for this issue. >> >> >> IBM964 charset and IBM29626C charset are required for default charset >> on AIX zh_TW and ja_JP locale. >> OpenJDK already has IBM964, but it could not be configured for default >> charset. >> IBM29626C is new one. >> (IBM33722 extends IBM29626C class) >> >> I knew IBM charsets would need to move to somewhere. >> The discussion was started by "Adding new IBM extended charsets". [1] >> But it's related default charset issue. >> Please put them inside of OpenJDK. >> >> About IBM964, >> Bhaktavatsal started the discussion [2]. >> Sherman said that [3] >> the new model (open/make/data/charetmapping), instead of >> hard-coding >> the map >> into the source code. >> >> This fix only has small sized hard-coded mapping, >> IBM964/IBM29626C/IBM33722 refer other charsets conversion table >> which are using the new model. >> And class file is smaller then before. >> Still I used SimpleEUCEncoder class because it's stable. >> I think we may re-write it by IBM charsets renewal. >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-July/054248.html >> [2] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053050.html >> [3] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-May/053096.html >> From dan.z.zhou at oracle.com Thu Nov 15 02:39:24 2018 From: dan.z.zhou at oracle.com (Dora Zhou) Date: Thu, 15 Nov 2018 10:39:24 +0800 Subject: [12]RFR 8210408: Refactor java.util.ResourceBundle:i18n shell tests to plain java tests Message-ID: <08c054e1-222e-aca3-af24-aca316ded166@oracle.com> Hello, Please help review the fix for refactor java.util.ResourceBundle:i18n shell tests to plain java tests. Thank you. Shell Tests: test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh test/java/util/ResourceBundle/modules/xmlformat/xmlformat.sh test/java/util/ResourceBundle/modules/unnamed/unnamed.sh test/java/util/ResourceBundle/modules/appbasic/appbasic.sh test/java/util/ResourceBundle/modules/visibility/visibility.sh test/java/util/ResourceBundle/modules/modlocal/modlocal.sh test/java/util/ResourceBundle/modules/simple/simple.sh test/java/util/ResourceBundle/modules/basic/basic.sh test/java/util/ResourceBundle/modules/layer/run.sh test/java/util/ResourceBundle/Bug6299235Test.sh I merged appbasic, appbasic2, basic, simple, xml, modlocal together with one BasicTest.main(). Bug: https://bugs.openjdk.java.net/browse/JDK-8210408 webrev: http://cr.openjdk.java.net/~dzhou/8210408/webrev.02/ Regards, Dora From naoto.sato at oracle.com Thu Nov 15 17:08:15 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 15 Nov 2018 09:08:15 -0800 Subject: [12]RFR 8210408: Refactor java.util.ResourceBundle:i18n shell tests to plain java tests In-Reply-To: <08c054e1-222e-aca3-af24-aca316ded166@oracle.com> References: <08c054e1-222e-aca3-af24-aca316ded166@oracle.com> Message-ID: <87358953-7a8e-3f42-8754-655d52fd00dc@oracle.com> Looks good to me. Naoto On 11/14/18 6:39 PM, Dora Zhou wrote: > Hello, > > Please help review the fix for refactor java.util.ResourceBundle:i18n > shell tests to plain java tests. Thank you. > > Shell Tests: > test/java/util/ResourceBundle/modules/appbasic2/appbasic2.sh > test/java/util/ResourceBundle/modules/xmlformat/xmlformat.sh > test/java/util/ResourceBundle/modules/unnamed/unnamed.sh > test/java/util/ResourceBundle/modules/appbasic/appbasic.sh > test/java/util/ResourceBundle/modules/visibility/visibility.sh > test/java/util/ResourceBundle/modules/modlocal/modlocal.sh > test/java/util/ResourceBundle/modules/simple/simple.sh > test/java/util/ResourceBundle/modules/basic/basic.sh > test/java/util/ResourceBundle/modules/layer/run.sh > test/java/util/ResourceBundle/Bug6299235Test.sh > > I merged appbasic, appbasic2, basic, simple, xml, modlocal together with > one BasicTest.main(). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8210408 > > webrev: http://cr.openjdk.java.net/~dzhou/8210408/webrev.02/ > > Regards, > Dora From nishit.jain at oracle.com Fri Nov 16 17:54:21 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 16 Nov 2018 23:24:21 +0530 Subject: RFR 8177552: Compact Number Formatting support Message-ID: Hi, Please review this non trivial feature addition to NumberFormat API. The existing NumberFormat API provides locale based support for formatting and parsing numbers which includes formatting decimal, percent, currency etc, but the support for formatting a number into a human readable or compact form is missing. This RFE adds that feature to format a decimal number in a compact format (e.g. 1000 -> 1K, 1000000 -> 1M in en_US locale) , which is useful for the environment where display space is limited, so that the formatted string can be displayed in that limited space. It is defined by LDML's specification for Compact Number Formats. http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 Request to please help review the the change. Regards, Nishit Jain From naoto.sato at oracle.com Fri Nov 16 23:22:14 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 16 Nov 2018 15:22:14 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: Message-ID: Hi Nishit, Here are my comments: - CLDRConverter: As the compact pattern no more employs List, can we eliminate stringListEntry/Element, and use Array equivalent instead? - CompactNumberFormat.java Multiple locations: Use StringBuilder instead of StringBuffer. line 268: The link points to NumberFormat.getNumberInstance(Locale) instead of DecimalFormat line 855: no need to do toString(). length() can detect whether it's empty or not. line 884: "Overloaded method" reads odd here. I'd prefer specializing in the "given number" into either long or biginteger. line 1500: subparseNumber() pretty much shares the same code with DecimalFormat.subparse(). can they be merged? line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls super. No need to override them. line 2231: You need to test the type before cast. Otherwise ClassCastException may be thrown. Naoto On 11/16/18 9:54 AM, Nishit Jain wrote: > Hi, > > Please review this non trivial feature addition to NumberFormat API. > > The existing NumberFormat API provides locale based support for > formatting and parsing numbers which includes formatting decimal, > percent, currency etc, but the support for formatting a number into a > human readable or compact form is missing. This RFE adds that feature to > format a decimal number in a compact format (e.g. 1000 -> 1K, 1000000 -> > 1M in en_US locale) , which is useful for the environment where display > space is limited, so that the formatted string can be displayed in that > limited space. It is defined by LDML's specification for Compact Number > Formats. > > http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats > > > RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 > Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ > CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 > > Request to please help review the the change. > > Regards, > Nishit Jain > > > > From takiguc at linux.vnet.ibm.com Sun Nov 18 13:22:23 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Sun, 18 Nov 2018 22:22:23 +0900 Subject: RFR: 8212678 Windows IME related patch In-Reply-To: References: Message-ID: <75b8dabc3f52417885a0a1f1e3aec719@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212678 Change: http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ Test instruction is in JDK-8212678. This fix may improve CJK IME operation. I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-15 02:26, Phil Race wrote: > This should go to i18n-dev as well. > > -phil. > > On 06/14/2018 10:14 AM, Ichiroh Takiguchi wrote: >> Hello, >> IBM would like to contribute Windows IME related Java Input Method >> Framework patch to OpenJDK project. >> >> Issue: >> This patch can fix following issues. >> A: Cannot display surrogate pair character on Windows floating IME >> window for passive component >> B: Control Windows IME status by using InputSubset and UnicodeBlock >> for CJK countries >> C: Check preedit string availability for Windows Chinese IME >> >> To recreate each issue. >> >> Issue A: >> 1. Run SwingSet2 Java demo program with Japanese IME. >> 2. Click InternalFrameDemo's "Frame 0". >> 3. Turn on Japanese IME, then type "2000B" and press F5 key. >> The character is not displayed properly. [1] >> >> Issue B: >> Test program (ImSubsetsTest.java) is as follow: >> http://cr.openjdk.java.net/~aleonard/winime/ImSubsetsTest.java >> >> 1. Compile and run ImSubsetsTest with CJK IMEs >> 2. Select language (ja:Japanese, ko:Korean, zh: Chinese). >> Windows IME (same langugae's one) should be turned on. >> 3. Click JTextField (active component) or JButton (passive component) >> (Please check IM status is changed or not) >> 4. Click different color's JTextField (active component) or JButton >> (passive component) >> (Please check IM status is changed or not) >> 5. Following operations did not work >> Korean IME : HANJA->LATIN_DIGIT,BASIC_LATIN >> Chinese IME : FULLWIDTH_DIGITS->LATIN_DIGIT,BASIC_LATIN >> >> Issue C: >> Test program is as follows: >> ====== >> import javax.swing.*; >> >> public class IMFTestA extends JFrame { >> IMFTestA(int width, int height, int x, int y) { >> super("JTextArea"); >> add(new JTextArea()); >> setSize(width, height); >> setLocation(x, y); >> setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> setVisible(true); >> } >> public static void main(String[] args) { >> new IMFTestA(300, 200, 0, 0); >> new IMFTestA(300, 200, 300, 0); >> } >> } >> ====== >> >> On Chinese IME (Microsoft Pinyin ABC), >> 1. Compile and run IMFTestA >> 2. Click one of JTextArea window, turn ON Chinese IME >> 3. Click the other window, turn ON Chinese IME >> 4. Type "nihao", then preedit string is displayed >> 5. Click the other window, turn OFF Chinese IME >> 6. Click the other window, preedit string is still displayed but it's >> not convertable >> >> Reason: >> Issue A, proper font is not specified for passive component >> Issue B, IME mode setting for CJK Windows IME is not correct >> Issue C, Chinese Windows IME shares IME status between windows, Java >> needs to check preedit string is available or not >> >> I'd like contribute following 3 files: >> M src/java.desktop/windows/classes/sun/awt/windows/WInputMethod.java >> M src/java.desktop/windows/native/libawt/windows/awt_Component.cpp >> M src/java.desktop/windows/native/libawt/windows/awt_InputMethod.cpp >> http://cr.openjdk.java.net/~aleonard/winime/webrev.00/ >> >> I appreciate any feedback please, and how I would go about obtaining a >> sponsor and contributor? >> >> [1] http://unicode.org/cgi-bin/GetUnihanData.pl?codepoint=2000B >> >> Thanks, >> Ichiroh Takiguchi >> IBM Japan, Ltd. >> From nishit.jain at oracle.com Mon Nov 19 06:29:52 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 19 Nov 2018 11:59:52 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: Message-ID: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> Hi Naoto, Please check my comments inline. On 17-11-2018 04:52, naoto.sato at oracle.com wrote: > Hi Nishit, > > Here are my comments: > > - CLDRConverter: As the compact pattern no more employs List, > can we eliminate stringListEntry/Element, and use Array equivalent > instead? Since the CNF design does not put any limit on the size of compact pattern, so at the time of parsing the CLDR xmls using SAX parser, it becomes difficult to identify the size of array when the parent element of compact pattern is encountered, so I think it is better to keep the List while extracting the resources. > > - CompactNumberFormat.java > > Multiple locations: Use StringBuilder instead of StringBuffer. OK > > line 268: The link points to NumberFormat.getNumberInstance(Locale) > instead of DecimalFormat OK. Changed it at line 165 also. > > line 855: no need to do toString(). length() can detect whether it's > empty or not. > > line 884: "Overloaded method" reads odd here. I'd prefer specializing > in the "given number" into either long or biginteger. OK > > line 1500: subparseNumber() pretty much shares the same code with > DecimalFormat.subparse(). can they be merged? The existing CNF.subParseNumber differs in the way parseIntegerOnly is handled, DecimalFormat.parse()/subparse() behaviour is unpredictable with parseIntegeronly = true when multipliers are involved (Please see JDK-8199223). Also, I had thought that the CNF.parse()/subparseNumber() should *not *parse the exponential notation e.g. while parsing "1.05E4K" the parsing should break at 'E' and returns 1.05, because 'E' should be considered as unparseable character for general number format pattern or compact number pattern, but this is not the case with DecimalFormat.parse(). The below DecimalFormat general number format instance NumberFormat nf =? NumberFormat.getNumberInstance(); nf.parse("1.05E4") Successfully parse the string and returns 10500. The same behaviour is there with other DecimalFormat instances also e.g. currency instance. Do you think this is an issue with DecimalFormat.parse() and CNF should avoid parsing exponential numbers? Or, should CNF.parse() be modified to be consistent with DecimalFormat.parse() in this aspect? > > line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls > super. No need to override them. Since setters are overridden, I think that it is better to override getters also (even if they are just calling super and have same javadoc) to keep them at same level. But, if you see no point in keeping them in CNF, I will remove them. Does that need CSR change? > > line 2231: You need to test the type before cast. Otherwise > ClassCastException may be thrown. The type is checked in the superclass equals method getClass() != obj.getClass(), so I think there is no need to check the type here. Regards, Nishit Jain > > Naoto > > On 11/16/18 9:54 AM, Nishit Jain wrote: >> Hi, >> >> Please review this non trivial feature addition to NumberFormat API. >> >> The existing NumberFormat API provides locale based support for >> formatting and parsing numbers which includes formatting decimal, >> percent, currency etc, but the support for formatting a number into a >> human readable or compact form is missing. This RFE adds that feature >> to format a decimal number in a compact format (e.g. 1000 -> 1K, >> 1000000 -> 1M in en_US locale) , which is useful for the environment >> where display space is limited, so that the formatted string can be >> displayed in that limited space. It is defined by LDML's >> specification for Compact Number Formats. >> >> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >> >> >> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >> Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >> >> Request to please help review the the change. >> >> Regards, >> Nishit Jain >> >> >> >> From naoto.sato at oracle.com Mon Nov 19 19:03:36 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 19 Nov 2018 11:03:36 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> Message-ID: Hi Nishit, On 11/18/18 10:29 PM, Nishit Jain wrote: > Hi Naoto, > > Please check my comments inline. > > On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> Here are my comments: >> >> - CLDRConverter: As the compact pattern no more employs List, >> can we eliminate stringListEntry/Element, and use Array equivalent >> instead? > Since the CNF design does not put any limit on the size of compact > pattern, so at the time of parsing the CLDR xmls using SAX parser, it > becomes difficult to identify the size of array when the parent element > of compact pattern is encountered, so I think it is better to keep the > List while extracting the resources. OK. However I'd not keep the List format on generating the resource bundle, as there is no reason to introduce yet another bundle format other than the existing array of String. >> >> - CompactNumberFormat.java >> >> Multiple locations: Use StringBuilder instead of StringBuffer. > OK >> >> line 268: The link points to NumberFormat.getNumberInstance(Locale) >> instead of DecimalFormat > OK. Changed it at line 165 also. >> >> line 855: no need to do toString(). length() can detect whether it's >> empty or not. >> >> line 884: "Overloaded method" reads odd here. I'd prefer specializing >> in the "given number" into either long or biginteger. > OK >> >> line 1500: subparseNumber() pretty much shares the same code with >> DecimalFormat.subparse(). can they be merged? > The existing CNF.subParseNumber differs in the way parseIntegerOnly is > handled, DecimalFormat.parse()/subparse() behaviour is unpredictable > with parseIntegeronly = true when multipliers are involved (Please see > JDK-8199223). > > Also, I had thought that the CNF.parse()/subparseNumber() should *not > *parse the exponential notation e.g. while parsing "1.05E4K" the parsing > should break at 'E' and returns 1.05, because 'E' should be considered > as unparseable character for general number format pattern or compact > number pattern, but this is not the case with DecimalFormat.parse(). The > below DecimalFormat general number format instance > > NumberFormat nf =? NumberFormat.getNumberInstance(); > nf.parse("1.05E4") > > Successfully parse the string and returns 10500. The same behaviour is > there with other DecimalFormat instances also e.g. currency instance. > > Do you think this is an issue with DecimalFormat.parse() and CNF should > avoid parsing exponential numbers? Or, should CNF.parse() be modified to > be consistent with DecimalFormat.parse() in this aspect? No, I understand there are differences. But I see a lot of duplicated piece of code which I would like to eliminate. > >> >> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >> super. No need to override them. > Since setters are overridden, I think that it is better to override > getters also (even if they are just calling super and have same javadoc) > to keep them at same level. But, if you see no point in keeping them in > CNF, I will remove them. Does that need CSR change? I don't see any point for override. I don't think there needs a CSR, but better ask Joe about it. >> >> line 2231: You need to test the type before cast. Otherwise >> ClassCastException may be thrown. > The type is checked in the superclass equals method getClass() != > obj.getClass(), so I think there is no need to check the type here. OK. Naoto > > Regards, > Nishit Jain >> >> Naoto >> >> On 11/16/18 9:54 AM, Nishit Jain wrote: >>> Hi, >>> >>> Please review this non trivial feature addition to NumberFormat API. >>> >>> The existing NumberFormat API provides locale based support for >>> formatting and parsing numbers which includes formatting decimal, >>> percent, currency etc, but the support for formatting a number into a >>> human readable or compact form is missing. This RFE adds that feature >>> to format a decimal number in a compact format (e.g. 1000 -> 1K, >>> 1000000 -> 1M in en_US locale) , which is useful for the environment >>> where display space is limited, so that the formatted string can be >>> displayed in that limited space. It is defined by LDML's >>> specification for Compact Number Formats. >>> >>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>> >>> >>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>> Webrev: http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>> >>> Request to please help review the the change. >>> >>> Regards, >>> Nishit Jain >>> >>> >>> >>> > From rachna.goel at oracle.com Tue Nov 20 12:56:32 2018 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 20 Nov 2018 18:26:32 +0530 Subject: RFR: [12] JDK-8209923 : Unicode 11.0.0 Message-ID: Hi, Kindly review this enhancement to support Unicode version in JDK to 11.0.0. Bug: https://bugs.openjdk.java.net/browse/JDK-8209923 patch: http://cr.openjdk.java.net/~rgoel/JDK-8209923/webrev.02/ -- Thanks, Rachna From naoto.sato at oracle.com Tue Nov 20 17:33:05 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 20 Nov 2018 09:33:05 -0800 Subject: RFR: [12] JDK-8209923 : Unicode 11.0.0 In-Reply-To: References: Message-ID: Hi Rachna, The comment in CharacterData00.java.template is misleading. Those Georgian characters are not new in Unicode 11, but they are modified to have the title case characters with the same code points. Otherwise it looks OK. Naoto On 11/20/18 4:56 AM, Rachna Goel wrote: > Hi, > > Kindly review this enhancement to support Unicode version in JDK to 11.0.0. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8209923 > > patch: http://cr.openjdk.java.net/~rgoel/JDK-8209923/webrev.02/ > From nishit.jain at oracle.com Wed Nov 21 08:53:16 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 21 Nov 2018 14:23:16 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> Message-ID: <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> Hi Naoto, Updated the webrev based on suggestions http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ Changes made: - Replaced List with String[] to be added to the the resource bundles - refactored DecimalFormat.subparse() to be used by the CNF.parse(), to reduce code duplication. - Also updated it with other changes as suggested in the comments Regards, Nishit Jain On 20-11-2018 00:33, naoto.sato at oracle.com wrote: > Hi Nishit, > > On 11/18/18 10:29 PM, Nishit Jain wrote: >> Hi Naoto, >> >> Please check my comments inline. >> >> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>> Hi Nishit, >>> >>> Here are my comments: >>> >>> - CLDRConverter: As the compact pattern no more employs >>> List, can we eliminate stringListEntry/Element, and use >>> Array equivalent instead? >> Since the CNF design does not put any limit on the size of compact >> pattern, so at the time of parsing the CLDR xmls using SAX parser, it >> becomes difficult to identify the size of array when the parent >> element of compact pattern is encountered, so I think it is better to >> keep the List while extracting the resources. > > OK. However I'd not keep the List format on generating the > resource bundle, as there is no reason to introduce yet another bundle > format other than the existing array of String. > >>> >>> - CompactNumberFormat.java >>> >>> Multiple locations: Use StringBuilder instead of StringBuffer. >> OK >>> >>> line 268: The link points to NumberFormat.getNumberInstance(Locale) >>> instead of DecimalFormat >> OK. Changed it at line 165 also. >>> >>> line 855: no need to do toString(). length() can detect whether it's >>> empty or not. >>> >>> line 884: "Overloaded method" reads odd here. I'd prefer >>> specializing in the "given number" into either long or biginteger. >> OK >>> >>> line 1500: subparseNumber() pretty much shares the same code with >>> DecimalFormat.subparse(). can they be merged? >> The existing CNF.subParseNumber differs in the way parseIntegerOnly >> is handled, DecimalFormat.parse()/subparse() behaviour is >> unpredictable with parseIntegeronly = true when multipliers are >> involved (Please see JDK-8199223). >> >> Also, I had thought that the CNF.parse()/subparseNumber() should *not >> *parse the exponential notation e.g. while parsing "1.05E4K" the >> parsing should break at 'E' and returns 1.05, because 'E' should be >> considered as unparseable character for general number format pattern >> or compact number pattern, but this is not the case with >> DecimalFormat.parse(). The below DecimalFormat general number format >> instance >> >> NumberFormat nf =? NumberFormat.getNumberInstance(); >> nf.parse("1.05E4") >> >> Successfully parse the string and returns 10500. The same behaviour >> is there with other DecimalFormat instances also e.g. currency instance. >> >> Do you think this is an issue with DecimalFormat.parse() and CNF >> should avoid parsing exponential numbers? Or, should CNF.parse() be >> modified to be consistent with DecimalFormat.parse() in this aspect? > > No, I understand there are differences. But I see a lot of duplicated > piece of code which I would like to eliminate. > >> >>> >>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >>> super. No need to override them. >> Since setters are overridden, I think that it is better to override >> getters also (even if they are just calling super and have same >> javadoc) to keep them at same level. But, if you see no point in >> keeping them in CNF, I will remove them. Does that need CSR change? > > I don't see any point for override. I don't think there needs a CSR, > but better ask Joe about it. > >>> >>> line 2231: You need to test the type before cast. Otherwise >>> ClassCastException may be thrown. >> The type is checked in the superclass equals method getClass() != >> obj.getClass(), so I think there is no need to check the type here. > > OK. > > Naoto > >> >> Regards, >> Nishit Jain >>> >>> Naoto >>> >>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>> Hi, >>>> >>>> Please review this non trivial feature addition to NumberFormat API. >>>> >>>> The existing NumberFormat API provides locale based support for >>>> formatting and parsing numbers which includes formatting decimal, >>>> percent, currency etc, but the support for formatting a number into >>>> a human readable or compact form is missing. This RFE adds that >>>> feature to format a decimal number in a compact format (e.g. 1000 >>>> -> 1K, 1000000 -> 1M in en_US locale) , which is useful for the >>>> environment where display space is limited, so that the formatted >>>> string can be displayed in that limited space. It is defined by >>>> LDML's specification for Compact Number Formats. >>>> >>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>> >>>> >>>> >>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>> Webrev: >>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>> >>>> Request to please help review the the change. >>>> >>>> Regards, >>>> Nishit Jain >>>> >>>> >>>> >>>> >> From naoto.sato at oracle.com Wed Nov 21 20:32:56 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 21 Nov 2018 12:32:56 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> Message-ID: Hi Nishit, On 11/21/18 12:53 AM, Nishit Jain wrote: > Hi Naoto, > > Updated the webrev based on suggestions > > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ > > Changes made: > - Replaced List with String[] to be added to the the resource > bundles Good. > - refactored DecimalFormat.subparse() to be used by the CNF.parse(), to > reduce code duplication. I presume CNF is calling package-private methods in DF to share the same code. Some comments noting the sharing would be helpful. > - Also updated it with other changes as suggested in the comments Sorry I missed your question the last time: >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>> should avoid parsing exponential numbers? Or, should CNF.parse() be >>> modified to be consistent with DecimalFormat.parse() in this aspect? I think DecimalFormat and CNF should behave the same, ie. 'E' should be treated as the exponent without a quote. Some more comments (all in CompactNumberFormat.java) line 807: expandAffix() seems to treat localizable special pattern characters, but currently the implementation only cares for the minus sign. Should other localizable pattern chars be taken care of, such as percent sign? line 869, 888: Define what -1 means as a ret value. line 897: iterMultiplier be better all capitalized as it is a constant. And it could be statically defined in the class to be shared with other locations that use "10" for arithmetic operation. line 1531: Any possibility this could lead to divide-by-zero? Naoto > > Regards, > Nishit Jain > On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> On 11/18/18 10:29 PM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Please check my comments inline. >>> >>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>> Hi Nishit, >>>> >>>> Here are my comments: >>>> >>>> - CLDRConverter: As the compact pattern no more employs >>>> List, can we eliminate stringListEntry/Element, and use >>>> Array equivalent instead? >>> Since the CNF design does not put any limit on the size of compact >>> pattern, so at the time of parsing the CLDR xmls using SAX parser, it >>> becomes difficult to identify the size of array when the parent >>> element of compact pattern is encountered, so I think it is better to >>> keep the List while extracting the resources. >> >> OK. However I'd not keep the List format on generating the >> resource bundle, as there is no reason to introduce yet another bundle >> format other than the existing array of String. >> >>>> >>>> - CompactNumberFormat.java >>>> >>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>> OK >>>> >>>> line 268: The link points to NumberFormat.getNumberInstance(Locale) >>>> instead of DecimalFormat >>> OK. Changed it at line 165 also. >>>> >>>> line 855: no need to do toString(). length() can detect whether it's >>>> empty or not. >>>> >>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>> specializing in the "given number" into either long or biginteger. >>> OK >>>> >>>> line 1500: subparseNumber() pretty much shares the same code with >>>> DecimalFormat.subparse(). can they be merged? >>> The existing CNF.subParseNumber differs in the way parseIntegerOnly >>> is handled, DecimalFormat.parse()/subparse() behaviour is >>> unpredictable with parseIntegeronly = true when multipliers are >>> involved (Please see JDK-8199223). >>> >>> Also, I had thought that the CNF.parse()/subparseNumber() should *not >>> *parse the exponential notation e.g. while parsing "1.05E4K" the >>> parsing should break at 'E' and returns 1.05, because 'E' should be >>> considered as unparseable character for general number format pattern >>> or compact number pattern, but this is not the case with >>> DecimalFormat.parse(). The below DecimalFormat general number format >>> instance >>> >>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>> nf.parse("1.05E4") >>> >>> Successfully parse the string and returns 10500. The same behaviour >>> is there with other DecimalFormat instances also e.g. currency instance. >>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>> should avoid parsing exponential numbers? Or, should CNF.parse() be >>> modified to be consistent with DecimalFormat.parse() in this aspect? >> >> No, I understand there are differences. But I see a lot of duplicated >> piece of code which I would like to eliminate. >> >>> >>>> >>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >>>> super. No need to override them. >>> Since setters are overridden, I think that it is better to override >>> getters also (even if they are just calling super and have same >>> javadoc) to keep them at same level. But, if you see no point in >>> keeping them in CNF, I will remove them. Does that need CSR change? >> >> I don't see any point for override. I don't think there needs a CSR, >> but better ask Joe about it. >> >>>> >>>> line 2231: You need to test the type before cast. Otherwise >>>> ClassCastException may be thrown. >>> The type is checked in the superclass equals method getClass() != >>> obj.getClass(), so I think there is no need to check the type here. >> >> OK. >> >> Naoto >> >>> >>> Regards, >>> Nishit Jain >>>> >>>> Naoto >>>> >>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>> Hi, >>>>> >>>>> Please review this non trivial feature addition to NumberFormat API. >>>>> >>>>> The existing NumberFormat API provides locale based support for >>>>> formatting and parsing numbers which includes formatting decimal, >>>>> percent, currency etc, but the support for formatting a number into >>>>> a human readable or compact form is missing. This RFE adds that >>>>> feature to format a decimal number in a compact format (e.g. 1000 >>>>> -> 1K, 1000000 -> 1M in en_US locale) , which is useful for the >>>>> environment where display space is limited, so that the formatted >>>>> string can be displayed in that limited space. It is defined by >>>>> LDML's specification for Compact Number Formats. >>>>> >>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>> >>>>> >>>>> >>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>> >>>>> Request to please help review the the change. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> >>>>> >>>>> >>>>> >>> > From TOSHIONA at jp.ibm.com Thu Nov 22 06:48:10 2018 From: TOSHIONA at jp.ibm.com (Toshio 5 Nakamura) Date: Thu, 22 Nov 2018 15:48:10 +0900 Subject: Fw: [PATCH] JDK-8213183: InputMethod cannot be used after its restarting Message-ID: Ping. Thanks, Toshio Nakamura "awt-dev" wrote on 2018/11/15 17:15:25: > From: "Toshio 5 Nakamura" > To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/11/15 17:16 > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > used after its restarting > Sent by: "awt-dev" > > Hello, > > I'd like to re-propose minimized patch in this thread. > > The key fix of this patch is for XMSelection.java. Its initScreen() cleared > previous XRegisterIMInstantiateCallback() entry, but it should keep the > current mask. By this change only, we can reuse Input Method after > changing focus. > (Original patch didn't need focus change, but it may be hard to be reviewed.) > > Additionally, this change may unveil a potential problem in awt_InputMethod.c. > It needs to clear all pX11IMData, not only the current one. Without > the change, > multi-window application with IM may crash after IM restart. > > So, I'd like to propose only two parts in this thread. > Can I obtain a sponsor for this minimized fix? > > Revised webrev: > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.01/ > > Thanks, > Toshio Nakamura > > From: "Toshio 5 Nakamura" > To: Sergey Bylokhov > Cc: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/11/12 20:22 > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > used after its restarting > Sent by: "awt-dev" > > > > Hi Sergey, > > Thank you for your reply. Yes, I've added the steps to the bug. > https://bugs.openjdk.java.net/browse/JDK-8213183 > > Please let me know if you have any question or any advice. > > Thanks, > Toshio Nakamura > > From: Sergey Bylokhov > To: Toshio 5 Nakamura , awt- > dev at openjdk.java.net, i18n-dev at openjdk.java.net > Date: 2018/11/10 12:46 > Subject: Re: [PATCH] JDK-8213183: InputMethod cannot be > used after its restarting > > > > Hi, Toshio. > > Can you please add the steps to reproduce to the bug description. > > On 06/11/2018 01:19, Toshio 5 Nakamura wrote: > > Hello, > > > > Can I obtain a sponsor of this proposal about InputMethod issue on Linux? > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8213183 > > Webrev: > > http://cr.openjdk.java.net/~tnakamura/8213183/webrev.00/ > > > > I've got an author role and filled the bug report. > > Please refer the attached mail about the detail of this patch. > > > > Best Regards, > > Toshio Nakamura > > > > ----- Forwarded by Toshio 5 Nakamura/Japan/IBMon 2018/11/06 18:08----- > > > > From: "Toshio 5 Nakamura" > > To: awt-dev at openjdk.java.net, i18n-dev at openjdk.java.net > > Date: 2018/06/26 17:46 > > Subject: Proposal: Input Method re-connection > > Sent by: "awt-dev" > > > > > > Hello, > > > > I'd like to contribute a proposal about Input Method (IM) re-connection > > on Linux. This is a part of contribution of IBM enhancements. > > > > Issue: > > After IM process (fcitx, kinput2, etc.) was down, Java GUI application > > cannot use it even if IM process is restarted. This change try to > > re-connect IM when its process was restarted on Linux. > > > > Description of changes: > > - XRegisterIMInstantiateCallback is set in DestroyXIMCallback. > > - Saved the latest activated X11InputMethod instance and use it to > > call its activate method in the instantiate callback. > > - XSelectInput in XMSelection.java may reset the > > XRegisterIMInstantiateCallback entry, so it's changed to keep the > > current registers. > > > > Patch:_ > > __INVALID URI REMOVED > u=http-3A__cr.openjdk.java.net_-7Ealeonard_im-5Fresume_webrev. > 00_-5F&d=DwIG-g&c=jf_iaSHvJObTbx-siA1ZOg&r=EVbFABcgo-X99_TGI2- > qsMtyulHUruf8lAzMlVpVRqw&m=1u3dU946QiLq2yqf7qJ2YMbFMDCXL0zbwk7IdBWttvI&s=6kjP8gXqLxsirUEGjxIwgkO0URfMSs9pVJX2u9TeQnI&e= > > (I asked my colleague to store my patch for easy reference. > > I'm a contributor and need a sponsor of the proposal.) > > > > Could I ask someone to kindly become a sponsor of this proposal? > > > > Thanks, > > Toshio Nakamura, IBM Japan > > > > > -- > Best regards, Sergey. > > > > From nishit.jain at oracle.com Fri Nov 23 10:25:14 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 23 Nov 2018 15:55:14 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> Message-ID: <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> Hi Naoto, > I think DecimalFormat and CNF should behave the same, ie. 'E' should be treated as the exponent without a quote. Personally I don't think that the exponential parsing should be supported by CompactNumberFormat, because the objective of compact numbers is to represent numbers in short form. So, parsing of number format like "1.05E4K" should not be expected from CompactNumberFormat, I am even doubtful that such forms ("1.05E4K") are used anywhere where exponential and compact form are together used. If formatting and parsing of exponential numbers are needed it should be done by DecimalFormat scientific instance *not *with the general number instance.So, I don't think that we should allow parsing of exponential numbers.Comments welcome. Regards, Nishit Jain On 22-11-2018 02:02, naoto.sato at oracle.com wrote: > Hi Nishit, > > On 11/21/18 12:53 AM, Nishit Jain wrote: >> Hi Naoto, >> >> Updated the webrev based on suggestions >> >> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >> >> Changes made: >> - Replaced List with String[] to be added to the the resource >> bundles > > Good. > >> - refactored DecimalFormat.subparse() to be used by the CNF.parse(), >> to reduce code duplication. > > I presume CNF is calling package-private methods in DF to share the > same code. Some comments noting the sharing would be helpful. > >> - Also updated it with other changes as suggested in the comments > > Sorry I missed your question the last time: > >>> Do you think this is an issue with DecimalFormat.parse() and CNF > >>> should avoid parsing exponential numbers? Or, should CNF.parse() be > >>> modified to be consistent with DecimalFormat.parse() in this aspect? > > I think DecimalFormat and CNF should behave the same, ie. 'E' should > be treated as the exponent without a quote. > > Some more comments (all in CompactNumberFormat.java) > > line 807: expandAffix() seems to treat localizable special pattern > characters, but currently the implementation only cares for the minus > sign. Should other localizable pattern chars be taken care of, such as > percent sign? > > line 869, 888: Define what -1 means as a ret value. > > line 897: iterMultiplier be better all capitalized as it is a > constant. And it could be statically defined in the class to be shared > with other locations that use "10" for arithmetic operation. > > line 1531: Any possibility this could lead to divide-by-zero? > > Naoto > >> >> Regards, >> Nishit Jain >> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>> Hi Nishit, >>> >>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> Please check my comments inline. >>>> >>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>> Hi Nishit, >>>>> >>>>> Here are my comments: >>>>> >>>>> - CLDRConverter: As the compact pattern no more employs >>>>> List, can we eliminate stringListEntry/Element, and use >>>>> Array equivalent instead? >>>> Since the CNF design does not put any limit on the size of compact >>>> pattern, so at the time of parsing the CLDR xmls using SAX parser, >>>> it becomes difficult to identify the size of array when the parent >>>> element of compact pattern is encountered, so I think it is better >>>> to keep the List while extracting the resources. >>> >>> OK. However I'd not keep the List format on generating the >>> resource bundle, as there is no reason to introduce yet another >>> bundle format other than the existing array of String. >>> >>>>> >>>>> - CompactNumberFormat.java >>>>> >>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>> OK >>>>> >>>>> line 268: The link points to >>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>> OK. Changed it at line 165 also. >>>>> >>>>> line 855: no need to do toString(). length() can detect whether >>>>> it's empty or not. >>>>> >>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>> specializing in the "given number" into either long or biginteger. >>>> OK >>>>> >>>>> line 1500: subparseNumber() pretty much shares the same code with >>>>> DecimalFormat.subparse(). can they be merged? >>>> The existing CNF.subParseNumber differs in the way parseIntegerOnly >>>> is handled, DecimalFormat.parse()/subparse() behaviour is >>>> unpredictable with parseIntegeronly = true when multipliers are >>>> involved (Please see JDK-8199223). >>>> >>>> Also, I had thought that the CNF.parse()/subparseNumber() should >>>> *not *parse the exponential notation e.g. while parsing "1.05E4K" >>>> the parsing should break at 'E' and returns 1.05, because 'E' >>>> should be considered as unparseable character for general number >>>> format pattern or compact number pattern, but this is not the case >>>> with DecimalFormat.parse(). The below DecimalFormat general number >>>> format instance >>>> >>>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>>> nf.parse("1.05E4") >>>> >>>> Successfully parse the string and returns 10500. The same behaviour >>>> is there with other DecimalFormat instances also e.g. currency >>>> instance. >>>> >>>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>> should avoid parsing exponential numbers? Or, should CNF.parse() be >>>> modified to be consistent with DecimalFormat.parse() in this aspect? >>> >>> No, I understand there are differences. But I see a lot of >>> duplicated piece of code which I would like to eliminate. >>> >>>> >>>>> >>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >>>>> super. No need to override them. >>>> Since setters are overridden, I think that it is better to override >>>> getters also (even if they are just calling super and have same >>>> javadoc) to keep them at same level. But, if you see no point in >>>> keeping them in CNF, I will remove them. Does that need CSR change? >>> >>> I don't see any point for override. I don't think there needs a CSR, >>> but better ask Joe about it. >>> >>>>> >>>>> line 2231: You need to test the type before cast. Otherwise >>>>> ClassCastException may be thrown. >>>> The type is checked in the superclass equals method getClass() != >>>> obj.getClass(), so I think there is no need to check the type here. >>> >>> OK. >>> >>> Naoto >>> >>>> >>>> Regards, >>>> Nishit Jain >>>>> >>>>> Naoto >>>>> >>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>> Hi, >>>>>> >>>>>> Please review this non trivial feature addition to NumberFormat API. >>>>>> >>>>>> The existing NumberFormat API provides locale based support for >>>>>> formatting and parsing numbers which includes formatting decimal, >>>>>> percent, currency etc, but the support for formatting a number >>>>>> into a human readable or compact form is missing. This RFE adds >>>>>> that feature to format a decimal number in a compact format (e.g. >>>>>> 1000 -> 1K, 1000000 -> 1M in en_US locale) , which is useful for >>>>>> the environment where display space is limited, so that the >>>>>> formatted string can be displayed in that limited space. It is >>>>>> defined by LDML's specification for Compact Number Formats. >>>>>> >>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>> >>>>>> >>>>>> >>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>> >>>>>> Request to please help review the the change. >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>> >>>>>> >>>>>> >>>>>> >>>> >> From nishit.jain at oracle.com Mon Nov 26 08:41:50 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 26 Nov 2018 14:11:50 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> Message-ID: Hi Naoto, To add to my previous mail comment, the DecimalFormat spec also says that /*"DecimalFormat can be instructed to format and parse scientific notation only via a pattern; there is currently no factory method that creates a scientific notation format. In a pattern, the exponent character immediately followed by one or more digit characters indicates scientific notation. " */That is, exponent formatting and parsing is instructed only via a scientific notation pattern and I think should not be there with *general number* formatting. Updated webrev based on the other comments http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ > Some more comments (all in CompactNumberFormat.java) > line 807: expandAffix() seems to treat localizable special pattern characters, but currently the implementation only cares for the minus sign. Should other localizable pattern chars be taken care of, such as percent sign? - Other special characters like '%' percent sign are not allowed as per CNF compact pattern spec > line 869, 888: Define what -1 means as a ret value. - OK. > line 897: iterMultiplier be better all capitalized as it is a constant. And it could be statically defined in the class to be shared with other locations that use "10" for arithmetic operation. - OK, made it static final and renamed it as RANGE_MULTIPLIER > line 1531: Any possibility this could lead to divide-by-zero? - None which I am aware of, unless you are pointing to the issue like JDK-8211161, which we know is not an issue. Regards, Nishit Jain On 23-11-2018 15:55, Nishit Jain wrote: > Hi Naoto, > > > I think DecimalFormat and CNF should behave the same, ie. 'E' should > be treated as the exponent without a quote. > > Personally I don't think that the exponential parsing should be > supported by CompactNumberFormat, because the objective of compact > numbers is to represent numbers in short form. So, parsing of number > format like "1.05E4K" should not be expected from CompactNumberFormat, > I am even doubtful that such forms ("1.05E4K") are used anywhere where > exponential and compact form are together used. If formatting and > parsing of exponential numbers are needed it should be done by > DecimalFormat scientific instance *not *with the general number > instance.So, I don't think that we should allow parsing of exponential > numbers.Comments welcome. > > Regards, > Nishit Jain > On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> On 11/21/18 12:53 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> Updated the webrev based on suggestions >>> >>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>> >>> Changes made: >>> - Replaced List with String[] to be added to the the >>> resource bundles >> >> Good. >> >>> - refactored DecimalFormat.subparse() to be used by the CNF.parse(), >>> to reduce code duplication. >> >> I presume CNF is calling package-private methods in DF to share the >> same code. Some comments noting the sharing would be helpful. >> >>> - Also updated it with other changes as suggested in the comments >> >> Sorry I missed your question the last time: >> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >> >>> should avoid parsing exponential numbers? Or, should CNF.parse() be >> >>> modified to be consistent with DecimalFormat.parse() in this aspect? >> >> I think DecimalFormat and CNF should behave the same, ie. 'E' should >> be treated as the exponent without a quote. >> >> Some more comments (all in CompactNumberFormat.java) >> >> line 807: expandAffix() seems to treat localizable special pattern >> characters, but currently the implementation only cares for the minus >> sign. Should other localizable pattern chars be taken care of, such >> as percent sign? >> >> line 869, 888: Define what -1 means as a ret value. >> >> line 897: iterMultiplier be better all capitalized as it is a >> constant. And it could be statically defined in the class to be >> shared with other locations that use "10" for arithmetic operation. >> >> line 1531: Any possibility this could lead to divide-by-zero? >> >> Naoto >> >>> >>> Regards, >>> Nishit Jain >>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>> Hi Nishit, >>>> >>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> Please check my comments inline. >>>>> >>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>> Hi Nishit, >>>>>> >>>>>> Here are my comments: >>>>>> >>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>> List, can we eliminate stringListEntry/Element, and use >>>>>> Array equivalent instead? >>>>> Since the CNF design does not put any limit on the size of compact >>>>> pattern, so at the time of parsing the CLDR xmls using SAX parser, >>>>> it becomes difficult to identify the size of array when the parent >>>>> element of compact pattern is encountered, so I think it is better >>>>> to keep the List while extracting the resources. >>>> >>>> OK. However I'd not keep the List format on generating the >>>> resource bundle, as there is no reason to introduce yet another >>>> bundle format other than the existing array of String. >>>> >>>>>> >>>>>> - CompactNumberFormat.java >>>>>> >>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>> OK >>>>>> >>>>>> line 268: The link points to >>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>> OK. Changed it at line 165 also. >>>>>> >>>>>> line 855: no need to do toString(). length() can detect whether >>>>>> it's empty or not. >>>>>> >>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>> specializing in the "given number" into either long or biginteger. >>>>> OK >>>>>> >>>>>> line 1500: subparseNumber() pretty much shares the same code with >>>>>> DecimalFormat.subparse(). can they be merged? >>>>> The existing CNF.subParseNumber differs in the way >>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>> multipliers are involved (Please see JDK-8199223). >>>>> >>>>> Also, I had thought that the CNF.parse()/subparseNumber() should >>>>> *not *parse the exponential notation e.g. while parsing "1.05E4K" >>>>> the parsing should break at 'E' and returns 1.05, because 'E' >>>>> should be considered as unparseable character for general number >>>>> format pattern or compact number pattern, but this is not the case >>>>> with DecimalFormat.parse(). The below DecimalFormat general number >>>>> format instance >>>>> >>>>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>>>> nf.parse("1.05E4") >>>>> >>>>> Successfully parse the string and returns 10500. The same >>>>> behaviour is there with other DecimalFormat instances also e.g. >>>>> currency instance. >>>>> >>>>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>> should avoid parsing exponential numbers? Or, should CNF.parse() >>>>> be modified to be consistent with DecimalFormat.parse() in this >>>>> aspect? >>>> >>>> No, I understand there are differences. But I see a lot of >>>> duplicated piece of code which I would like to eliminate. >>>> >>>>> >>>>>> >>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >>>>>> super. No need to override them. >>>>> Since setters are overridden, I think that it is better to >>>>> override getters also (even if they are just calling super and >>>>> have same javadoc) to keep them at same level. But, if you see no >>>>> point in keeping them in CNF, I will remove them. Does that need >>>>> CSR change? >>>> >>>> I don't see any point for override. I don't think there needs a >>>> CSR, but better ask Joe about it. >>>> >>>>>> >>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>> ClassCastException may be thrown. >>>>> The type is checked in the superclass equals method getClass() != >>>>> obj.getClass(), so I think there is no need to check the type here. >>>> >>>> OK. >>>> >>>> Naoto >>>> >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>>> >>>>>> Naoto >>>>>> >>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Please review this non trivial feature addition to NumberFormat >>>>>>> API. >>>>>>> >>>>>>> The existing NumberFormat API provides locale based support for >>>>>>> formatting and parsing numbers which includes formatting >>>>>>> decimal, percent, currency etc, but the support for formatting a >>>>>>> number into a human readable or compact form is missing. This >>>>>>> RFE adds that feature to format a decimal number in a compact >>>>>>> format (e.g. 1000 -> 1K, 1000000 -> 1M in en_US locale) , which >>>>>>> is useful for the environment where display space is limited, so >>>>>>> that the formatted string can be displayed in that limited >>>>>>> space. It is defined by LDML's specification for Compact Number >>>>>>> Formats. >>>>>>> >>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>> >>>>>>> >>>>>>> >>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>> Webrev: >>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>> >>>>>>> Request to please help review the the change. >>>>>>> >>>>>>> Regards, >>>>>>> Nishit Jain >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>> >>> > From takiguc at linux.vnet.ibm.com Mon Nov 26 12:27:11 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 26 Nov 2018 21:27:11 +0900 Subject: RFR: 8212676 AIX's CDE/MWM support In-Reply-To: <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> References: <5f309d9c612f2c16aef75846e0ff14fa@linux.vnet.ibm.com> <0ede447e30ed05ce7a52f6d133b2c15b@linux.vnet.ibm.com> <180114e58e98f339332e3a781a34126b@linux.vnet.ibm.com> Message-ID: Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212676 Change: https://cr.openjdk.java.net/~itakiguchi/8212676/webrev.00/ Test instructions and screen shots are in JDK-8212676. GUI environment for AIX platform still needs CDE support. This fix is required to avoid unexpected working behavior on AIX platform. I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-18 18:57, Ichiroh Takiguchi wrote: > Hello. > > This fix is really required for AIX's GUI. > System color setting and window manager's working behavior are very > important. > > I appreciate any feedback, and how I would go about obtaining a > sponsor and contributor ? > > On 2018-05-25 11:02, Ichiroh Takiguchi wrote: >> Hello Phil. >> >> webrev file was extracted. >> Please see >> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev.00/ >> >> On 2018-05-19 02:48, Ichiroh Takiguchi wrote: >>> Hello Phil. >>> >>> Webrev.zip file is stored into >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/webrev-aixgui.zip >>> >>> Test programs are also stored: >>> No testcase is available for FontUtilities.java and >>> XDecoratedPeer.java. >>> >>> MotifColorUtilities.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/SystemColorTest2.java >>> Run SystemColorTest2, system colors should be displayed >>> AIX sample is >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/aix_systemcolor.txt >>> >>> XWM.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/XWMTest1.java >>> On AIX CDE, isMotif and isCDE were true. >>> On AIX MWM, every entry is false. >>> >>> XWindowPeer.java >>> http://cr.openjdk.java.net/~aleonard/AIX_GUI/JFrameTest.java >>> On AIX CDE, click inside of "Non-Focusable" window (not window >>> frame). >>> Window focus should not be changed because of "click on focus" >>> feature. >>> But input focus is moved to "Non-Focusable" window. >>> >>> >>> On 2018-05-18 01:00, Phil Race wrote: >>>> I think we'd need to see the actual proposed changes and understand >>>> the implications >>>> for ongoing support as we no longer support any platform which has a >>>> CDE desktop. >>>> Solaris 11.3 uses Gnome, so we'd be more inclined to be ripping out >>>> such support rather >>>> than adding to it. >>>> >>>> -phil. >>>> >>>> On 05/17/2018 04:18 AM, Ichiroh Takiguchi wrote: >>>>> Hello, >>>>> IBM would like to contribute AIX's CDE (Common Desktop Environment) >>>>> DTWM (Desktop Window Manager) /MWM (Motif Window Manager) support >>>>> to OpenJDK project. >>>>> >>>>> I'd like contribute following 5 files: >>>>> >>>>> M src/java.desktop/share/classes/sun/font/FontUtilities.java >>>>> (Add isAIX flag to determine AIX platform for GUI environment) >>>>> M >>>>> src/java.desktop/unix/classes/sun/awt/X11/MotifColorUtilities.java >>>>> (Add High Color support on CDE, OpenJDK just supports Medium Color) >>>>> [1] >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XDecoratedPeer.java >>>>> (Avoid miss calculation for window position under DTWM/MWM by >>>>> XMapRaised/XMapWindow) >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWM.java >>>>> (Detect MWM on AIX platform) >>>>> M src/java.desktop/unix/classes/sun/awt/X11/XWindowPeer.java >>>>> (Add non-focusable window support on DTWM/MWM for AIX, because >>>>> DTWM/MWM does not have enough features for ICCCM) >>>>> >>>>> I appreciate any feedback please, and how I would go about >>>>> obtaining a sponsor and contributor ? >>>>> >>>>> Thanks, >>>>> Ichiroh Takiguchi >>>>> IBM Japan, Ltd. >>>>> >>>>> [1] >>>>> https://docs.oracle.com/cd/E19253-01/806-7492/fontsandcolors-15233/index.html >>>>> From takiguc at linux.vnet.ibm.com Mon Nov 26 13:02:12 2018 From: takiguc at linux.vnet.ibm.com (Ichiroh Takiguchi) Date: Mon, 26 Nov 2018 22:02:12 +0900 Subject: RFR: X11 default visual support for IM status window on VNC In-Reply-To: <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com> References: <46b05293c2bab165a413ac1ac18e0703@linux.vnet.ibm.com> <4cb2abda-706f-8b1a-320c-64285ebfafae@oracle.com> <34954ce768b5b3254a3122cb8c0ed268@linux.vnet.ibm.com> <2f1d4840-7140-861e-cdac-5bfac039a5c4@oracle.com> <068fccf8-05a9-0e32-0540-551ade446f96@oracle.com> <5B2A6160.5000107@oracle.com> <674fa1d548764758a051953ce9a97d95@linux.vnet.ibm.com> Message-ID: <47596f79d10fcfac856172db4d8cffd2@linux.vnet.ibm.com> Hello. Could you review the fix ? Bug: https://bugs.openjdk.java.net/browse/JDK-8212677 Change: https://cr.openjdk.java.net/~itakiguchi/8212677/webrev.00/ Screen shots are in JDK-8212677. I'd like to obtain a sponsor for this issue. Thanks, Ichiroh Takiguchi IBM Japan, Ltd. On 2018-06-21 21:58, Ichiroh Takiguchi wrote: > Hello Phil. > > I'm sorry, I forgot to put my comment against your question. > >> Is this changing the default visual for all WIndows, not just the IM >> status window? >> I think we need to understand the implications before this can be >> accepted. > I put following debug code: > ======= > diff -r e1b3def12624 > src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > Wed Jun 13 06:35:04 2018 +0200 > +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c > Thu Jun 21 21:23:11 2018 +0900 > @@ -667,6 +667,7 @@ > InputOutput, > adata->awt_visInfo.visual, > attribmask, &attrib); > + fprintf(stderr, "status window id = 0x%X\n", status); > XSelectInput(dpy, status, > ExposureMask | StructureNotifyMask | EnterWindowMask > | > LeaveWindowMask | VisibilityChangeMask); > @@ -680,6 +681,21 @@ > statusWindow->fontset = XCreateFontSet(dpy, > > "-*-*-medium-r-normal-*-*-120-*-*-*-*", > &mclr, &mccr, &dsr); > + { > + int cntFonts; > + for(cntFonts = 0; cntFonts < mccr; cntFonts++) { > + fprintf(stderr, "[M][%d] %s\n", cntFonts, mclr[cntFonts]); > + } > + } > + { > + XFontStruct **font_struct_list; > + char **font_name_list; > + int cntFonts; > + int numFonts = XFontsOfFontSet(statusWindow->fontset, > &font_struct_list, &font_name_list); > + for(cntFonts = 0; cntFonts < numFonts; cntFonts++) { > + fprintf(stderr, "[L][%d] %s\n", cntFonts, > font_name_list[cntFonts]); > + } > + } > /* In case we didn't find the font set, release the list of > missing characters */ > if (mccr > 0) { > XFreeStringList(mclr); > ======= > > I tested it on RHEL7. > I thought since window id was assigned, but it was gone on current > code. > ======= > $ java -jar Notepad.jar > status window id = 0x4000055 > ... > $ xwininfo -id 0x4000055 > X Error: 9: Bad Drawable: 0x4000055 > Request Major code: 14 > Request serial number: 3 > xwininfo: error: No such window with id 0x4000055. > ======= > > ======= > $ java -jar Notepad.jar > status window id = 0x40000CA > ... > $ xwininfo -id 0x40000CA > > xwininfo: Window id: 0x40000ca (has no name) > > Absolute upper-left X: 0 > Absolute upper-left Y: 600 > Relative upper-left X: 0 > Relative upper-left Y: 600 > Width: 80 > Height: 22 > Depth: 24 > Visual: 0x21 > Visual Class: TrueColor > Border width: 0 > Class: InputOutput > Colormap: 0x20 (installed) > Bit Gravity State: ForgetGravity > Window Gravity State: NorthWestGravity > Backing Store State: NotUseful > Save Under State: no > Map State: IsUnMapped > Override Redirect State: yes > Corners: +0+600 -944+600 -944-146 +0-146 > -geometry 80x22+0+600 > ======= > > According to main window: (Left side: without fix, right side: with > fix) > ======= > xwininfo: Window id: 0x4000009 " (failure | xwininfo: Window id: > 0x460007e " (failure > > Absolute upper-left X: 4 Absolute upper-left > X: 4 > Absolute upper-left Y: 25 Absolute upper-left > Y: 25 > Relative upper-left X: 0 Relative upper-left > X: 0 > Relative upper-left Y: 0 Relative upper-left > Y: 0 > Width: 492 Width: 492 > Height: 571 Height: 571 > Depth: 24 Depth: 24 > Visual: 0x169 | Visual: 0x21 > Visual Class: TrueColor Visual Class: > TrueColor > Border width: 0 Border width: 0 > Class: InputOutput Class: InputOutput > Colormap: 0x4000008 (not installed) | Colormap: 0x20 > (installed) > Bit Gravity State: NorthWestGravity Bit Gravity State: > NorthWestGravity > Window Gravity State: NorthWestGravity Window Gravity > State: NorthWestGravity > Backing Store State: NotUseful Backing Store State: > NotUseful > Save Under State: no Save Under State: no > Map State: IsViewable Map State: IsViewable > Override Redirect State: no Override Redirect > State: no > Corners: +4+25 -528+25 -528-172 +4-1 Corners: +4+25 > -528+25 -528-172 +4-1 > -geometry 492x571+0+0 -geometry 492x571+0+0 > ======= > > So main window's visual also changed by this fix. > >> Similarly for the fontset change .. this might change what others get. >> The fontset spec. there seems very loose to me .. > > Without fix > ======= > $ java -jar Notepad.jar > status window id = 0x4000055 > [M][0] JISX0208.1983-0 > [M][1] GB2312.1980-0 > [L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 > [L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 > [L][2] > -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 > [L][3] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0 > [L][4] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 > ======= > > With fix > ======= > $ java -jar Notepad.jar > status window id = 0x40000CA > [M][0] GB2312.1980-0 > [L][0] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 > [L][1] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso8859-1 > [L][2] -misc-fixed-medium-r-normal--14-130-75-75-c-140-jisx0208.1983-0 > [L][3] > -daewoo-gothic-medium-r-normal--16-120-100-100-c-160-ksc5601.1987-0 > [L][4] -sony-fixed-medium-r-normal--16-120-100-100-c-80-jisx0201.1976-0 > [L][5] -misc-fixed-medium-r-normal--13-120-75-75-c-70-iso10646-1 > ======= > > [M] means "Missing" font, [L] means "Loaded". > > On 2018-06-20 23:14, Philip Race wrote: >> My question has not been answered. I don't think this is ready to go >> in. >> >> -phil. >> >> On 6/20/18, 4:23 AM, Ichiroh Takiguchi wrote: >>> Hello. >>> >>> New fixed code is in: >>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.02/ >>> >>> Could you check fixed files again ? >>> >>> I only updated following part between webrev.01 and webrev.02 >>> ====== >>> diff -r 70a582d110a1 -r 6f04164a9d62 >>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> --- a/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> Wed Jun 06 21:03:25 2018 +0900 >>> +++ b/src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>> Wed Jun 20 16:54:24 2018 +0900 >>> @@ -677,7 +677,7 @@ >>> return NULL; >>> } >>> statusWindow->w = status; >>> - //12-point font >>> + //12, 13-point fonts >>> statusWindow->fontset = XCreateFontSet(dpy, >>> >>> "-*-*-medium-r-normal-*-*-120-*-*-*-*," \ >>> >>> "-*-*-medium-r-normal-*-*-130-*-*-*-*", >>> ====== >>> >>> >>> Please create bugid and handle it. >>> >>> Thanks, >>> Ichiroh Takiguchi >>> IBM Japan, Ltd. >>> >>> On 2018-06-20 04:59, Naoto Sato wrote: >>>> Please change the comment in line 680, which should also mention 13 >>>> point font. >>>> >>>> Naoto >>>> >>>> On 6/19/18 12:54 PM, Naoto Sato wrote: >>>>> Looks OK wrt awt_InputMethod.c change. >>>>> >>>>> Naoto >>>>> >>>>> On 6/19/18 11:32 AM, Phil Race wrote: >>>>>> Where's the bug ID ? >>>>>> >>>>>> The review should have a bug ID in the subject line so we can all >>>>>> find it later ! >>>>>> >>>>>> Is this changing the default visual for all WIndows, not just the >>>>>> IM status window? >>>>>> I think we need to understand the implications before this can be >>>>>> accepted. >>>>>> >>>>>> Similarly for the fontset change .. this might change what others >>>>>> get. >>>>>> The fontset spec. there seems very loose to me .. >>>>>> >>>>>> I think I18N-DEV should be asked about this too. >>>>>> >>>>>> -phil. >>>>>> >>>>>> On 06/19/2018 11:07 AM, Sergey Bylokhov wrote: >>>>>>> Looks fine, if there are no other comments I'll push the fix >>>>>>> using the new bugid. >>>>>>> >>>>>>> On 06/06/2018 17:54, Ichiroh Takiguchi wrote: >>>>>>>> Hello Sergey. >>>>>>>> Thank you for your review. >>>>>>>> >>>>>>>> Could you review following patch ? >>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/webrev.01/ >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Ichiroh Takiguchi >>>>>>>> IBM Japan, Ltd. >>>>>>>> >>>>>>>> On 2018-06-06 07:15, Sergey Bylokhov wrote: >>>>>>>>> Hi, Ichiroh. >>>>>>>>> The approach looks fine, but maybe it is possible to decrees >>>>>>>>> code >>>>>>>>> duplication in findWithTemplate(). After the fix it will have >>>>>>>>> two >>>>>>>>> similar loops. >>>>>>>>> >>>>>>>>> On 24/05/2018 22:24, Ichiroh Takiguchi wrote: >>>>>>>>>> Hello, >>>>>>>>>> IBM would like to contribute X11 default visual support for IM >>>>>>>>>> status window patch to OpenJDK project. >>>>>>>>>> >>>>>>>>>> Issue: >>>>>>>>>> Java's Native IM status window is not displayed even if it's >>>>>>>>>> there. >>>>>>>>>> Because of this issue, user cannot get proper visual feedback >>>>>>>>>> during key input operation. >>>>>>>>>> We found this issue on Tiger VNC. >>>>>>>>>> >>>>>>>>>> Reason: >>>>>>>>>> Java may pick up unexpected visual for Java's Native IM status >>>>>>>>>> window when Xserver supports multiple visual. >>>>>>>>>> >>>>>>>>>> Workaround: >>>>>>>>>> X11 default visual can be changed by FORCEDEFVIS environment >>>>>>>>>> variable, but it's not easy to find out default visual id. >>>>>>>>>> >>>>>>>>>> I'd like contribute following 2 files: >>>>>>>>>> M >>>>>>>>>> src/java.desktop/unix/native/libawt_xawt/awt/awt_GraphicsEnv.c >>>>>>>>>> (Change X11 visual setting) >>>>>>>>>> M >>>>>>>>>> src/java.desktop/unix/native/libawt_xawt/awt/awt_InputMethod.c >>>>>>>>>> (Support 13 point X11 misc fonts (like k14 font for Japanese), >>>>>>>>>> since the fonts may defined for unscaled fonts.) >>>>>>>>>> >>>>>>>>>> webrev files are in >>>>>>>>>> http://cr.openjdk.java.net/~aleonard/defvis/ >>>>>>>>>> >>>>>>>>>> I appreciate any feedback please, and how I would go about >>>>>>>>>> obtaining a sponsor and contributor? >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Ichiroh Takiguchi >>>>>>>>>> IBM Japan, Ltd. >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>> From naoto.sato at oracle.com Mon Nov 26 15:31:59 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 26 Nov 2018 07:31:59 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> Message-ID: <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> Hi Nishit, On 11/26/18 12:41 AM, Nishit Jain wrote: > Hi Naoto, > > To add to my previous mail comment, the DecimalFormat spec also says that > > /*"DecimalFormat can be instructed to format and parse scientific > notation only via a pattern; there is currently no factory method that > creates a scientific notation format. In a pattern, the exponent > character immediately followed by one or more digit characters indicates > scientific notation. " > > */That is, exponent formatting and parsing is instructed only via a > scientific notation pattern and I think should not be there with > *general number* formatting. I am not sure the quoted sentence should be interpreted that way. My understanding is that the section means there is no public NumberFormat.getScientificInstance() method (cf. line 601 at NumberFormat.java), so that users will have to use 'E' in their pattern string. Anyway, my point is that if you prefer to treat the scientific notation differently between DecimalFormat and CompactDecimalFormat, then it will need to be clarified in the spec. Personally I agree that it is not practical to interpret E in the CNF. Naoto > > Updated webrev based on the other comments > > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ > > > Some more comments (all in CompactNumberFormat.java) > > > line 807: expandAffix() seems to treat localizable special pattern > characters, but currently the implementation only cares for the minus > sign. Should other localizable pattern chars be taken care of, such as > percent sign? > - Other special characters like '%' percent sign are not allowed as per > CNF compact pattern spec > > > line 869, 888: Define what -1 means as a ret value. > - OK. > > > line 897: iterMultiplier be better all capitalized as it is a > constant. And it could be statically defined in the class to be shared > with other locations that use "10" for arithmetic operation. > - OK, made it static final and renamed it as RANGE_MULTIPLIER > > > line 1531: Any possibility this could lead to divide-by-zero? > - None which I am aware of, unless you are pointing to the issue like > JDK-8211161, which we know is not an issue. > > Regards, > Nishit Jain > On 23-11-2018 15:55, Nishit Jain wrote: >> Hi Naoto, >> >> > I think DecimalFormat and CNF should behave the same, ie. 'E' should >> be treated as the exponent without a quote. >> >> Personally I don't think that the exponential parsing should be >> supported by CompactNumberFormat, because the objective of compact >> numbers is to represent numbers in short form. So, parsing of number >> format like "1.05E4K" should not be expected from CompactNumberFormat, >> I am even doubtful that such forms ("1.05E4K") are used anywhere where >> exponential and compact form are together used. If formatting and >> parsing of exponential numbers are needed it should be done by >> DecimalFormat scientific instance *not *with the general number >> instance.So, I don't think that we should allow parsing of exponential >> numbers.Comments welcome. >> >> Regards, >> Nishit Jain >> On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >>> Hi Nishit, >>> >>> On 11/21/18 12:53 AM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> Updated the webrev based on suggestions >>>> >>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>>> >>>> Changes made: >>>> - Replaced List with String[] to be added to the the >>>> resource bundles >>> >>> Good. >>> >>>> - refactored DecimalFormat.subparse() to be used by the CNF.parse(), >>>> to reduce code duplication. >>> >>> I presume CNF is calling package-private methods in DF to share the >>> same code. Some comments noting the sharing would be helpful. >>> >>>> - Also updated it with other changes as suggested in the comments >>> >>> Sorry I missed your question the last time: >>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>> >>> should avoid parsing exponential numbers? Or, should CNF.parse() be >>> >>> modified to be consistent with DecimalFormat.parse() in this aspect? >>> >>> I think DecimalFormat and CNF should behave the same, ie. 'E' should >>> be treated as the exponent without a quote. >>> >>> Some more comments (all in CompactNumberFormat.java) >>> >>> line 807: expandAffix() seems to treat localizable special pattern >>> characters, but currently the implementation only cares for the minus >>> sign. Should other localizable pattern chars be taken care of, such >>> as percent sign? >>> >>> line 869, 888: Define what -1 means as a ret value. >>> >>> line 897: iterMultiplier be better all capitalized as it is a >>> constant. And it could be statically defined in the class to be >>> shared with other locations that use "10" for arithmetic operation. >>> >>> line 1531: Any possibility this could lead to divide-by-zero? >>> >>> Naoto >>> >>>> >>>> Regards, >>>> Nishit Jain >>>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>>> Hi Nishit, >>>>> >>>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Please check my comments inline. >>>>>> >>>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>>> Hi Nishit, >>>>>>> >>>>>>> Here are my comments: >>>>>>> >>>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>>> List, can we eliminate stringListEntry/Element, and use >>>>>>> Array equivalent instead? >>>>>> Since the CNF design does not put any limit on the size of compact >>>>>> pattern, so at the time of parsing the CLDR xmls using SAX parser, >>>>>> it becomes difficult to identify the size of array when the parent >>>>>> element of compact pattern is encountered, so I think it is better >>>>>> to keep the List while extracting the resources. >>>>> >>>>> OK. However I'd not keep the List format on generating the >>>>> resource bundle, as there is no reason to introduce yet another >>>>> bundle format other than the existing array of String. >>>>> >>>>>>> >>>>>>> - CompactNumberFormat.java >>>>>>> >>>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>>> OK >>>>>>> >>>>>>> line 268: The link points to >>>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>>> OK. Changed it at line 165 also. >>>>>>> >>>>>>> line 855: no need to do toString(). length() can detect whether >>>>>>> it's empty or not. >>>>>>> >>>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>>> specializing in the "given number" into either long or biginteger. >>>>>> OK >>>>>>> >>>>>>> line 1500: subparseNumber() pretty much shares the same code with >>>>>>> DecimalFormat.subparse(). can they be merged? >>>>>> The existing CNF.subParseNumber differs in the way >>>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>>> multipliers are involved (Please see JDK-8199223). >>>>>> >>>>>> Also, I had thought that the CNF.parse()/subparseNumber() should >>>>>> *not *parse the exponential notation e.g. while parsing "1.05E4K" >>>>>> the parsing should break at 'E' and returns 1.05, because 'E' >>>>>> should be considered as unparseable character for general number >>>>>> format pattern or compact number pattern, but this is not the case >>>>>> with DecimalFormat.parse(). The below DecimalFormat general number >>>>>> format instance >>>>>> >>>>>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>>>>> nf.parse("1.05E4") >>>>>> >>>>>> Successfully parse the string and returns 10500. The same >>>>>> behaviour is there with other DecimalFormat instances also e.g. >>>>>> currency instance. >>>>>> >>>>>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>>> should avoid parsing exponential numbers? Or, should CNF.parse() >>>>>> be modified to be consistent with DecimalFormat.parse() in this >>>>>> aspect? >>>>> >>>>> No, I understand there are differences. But I see a lot of >>>>> duplicated piece of code which I would like to eliminate. >>>>> >>>>>> >>>>>>> >>>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply calls >>>>>>> super. No need to override them. >>>>>> Since setters are overridden, I think that it is better to >>>>>> override getters also (even if they are just calling super and >>>>>> have same javadoc) to keep them at same level. But, if you see no >>>>>> point in keeping them in CNF, I will remove them. Does that need >>>>>> CSR change? >>>>> >>>>> I don't see any point for override. I don't think there needs a >>>>> CSR, but better ask Joe about it. >>>>> >>>>>>> >>>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>>> ClassCastException may be thrown. >>>>>> The type is checked in the superclass equals method getClass() != >>>>>> obj.getClass(), so I think there is no need to check the type here. >>>>> >>>>> OK. >>>>> >>>>> Naoto >>>>> >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Please review this non trivial feature addition to NumberFormat >>>>>>>> API. >>>>>>>> >>>>>>>> The existing NumberFormat API provides locale based support for >>>>>>>> formatting and parsing numbers which includes formatting >>>>>>>> decimal, percent, currency etc, but the support for formatting a >>>>>>>> number into a human readable or compact form is missing. This >>>>>>>> RFE adds that feature to format a decimal number in a compact >>>>>>>> format (e.g. 1000 -> 1K, 1000000 -> 1M in en_US locale) , which >>>>>>>> is useful for the environment where display space is limited, so >>>>>>>> that the formatted string can be displayed in that limited >>>>>>>> space. It is defined by LDML's specification for Compact Number >>>>>>>> Formats. >>>>>>>> >>>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>>> Webrev: >>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>>> >>>>>>>> Request to please help review the the change. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nishit Jain >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>> >> > From naoto.sato at oracle.com Tue Nov 27 01:07:13 2018 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 26 Nov 2018 17:07:13 -0800 Subject: [12] RFR: 8214170: ResourceBundle.Control.newBundle should throw IllegalAccessException when constructor of the resource bundle is not public. Message-ID: <57279396-2b4b-ceff-0b80-b1ba7e305f89@oracle.com> Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8214170 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8214170/webrev.00/ The existing logic to determine if there is a pubic constructor for the ResourceBundle class is incorrect. Moved the catch clause for NoSuchMethodException to handle it correctly. A shell based test was modified according to this (intentionally omitted the case for windows as chmod does not work - it will be addressed with the test case clean up (8213127). Naoto From nishit.jain at oracle.com Tue Nov 27 07:11:55 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Tue, 27 Nov 2018 12:41:55 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> Message-ID: <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> Hi Naoto, On 26-11-2018 21:01, naoto.sato at oracle.com wrote: > Hi Nishit, > > On 11/26/18 12:41 AM, Nishit Jain wrote: >> Hi Naoto, >> >> To add to my previous mail comment, the DecimalFormat spec also says >> that >> >> /*"DecimalFormat can be instructed to format and parse scientific >> notation only via a pattern; there is currently no factory method >> that creates a scientific notation format. In a pattern, the exponent >> character immediately followed by one or more digit characters >> indicates scientific notation. " >> >> */That is, exponent formatting and parsing is instructed only via a >> scientific notation pattern and I think should not be there with >> *general number* formatting. > > I am not sure the quoted sentence should be interpreted that way. My > understanding is that the section means there is no public > NumberFormat.getScientificInstance() method (cf. line 601 at > NumberFormat.java), so that users will have to use 'E' in their > pattern string. > > Anyway, my point is that if you prefer to treat the scientific > notation differently between DecimalFormat and CompactDecimalFormat, > then it will need to be clarified in the spec. Personally I agree that > it is not practical to interpret E in the CNF. OK. If it is better to specify the parsing behavior w.r.t. the exponential numbers, I have added a statement in the parse() API. */"CompactNumberFormat parse does not allow parsing exponential number strings. For example, parsing a string "1.05E4K" in US locale breaks at character 'E' and returns 1.05."/* Updated the webrev http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.03/ Will also update the CSR and refinalize it. Regards, Nishit Jain > > Naoto > >> >> Updated webrev based on the other comments >> >> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ >> >> ?> Some more comments (all in CompactNumberFormat.java) >> >> ?> line 807: expandAffix() seems to treat localizable special pattern >> characters, but currently the implementation only cares for the minus >> sign. Should other localizable pattern chars be taken care of, such >> as percent sign? >> - Other special characters like '%' percent sign are not allowed as >> per CNF compact pattern spec >> >> ?> line 869, 888: Define what -1 means as a ret value. >> - OK. >> >> ?> line 897: iterMultiplier be better all capitalized as it is a >> constant. And it could be statically defined in the class to be >> shared with other locations that use "10" for arithmetic operation. >> - OK, made it static final and renamed it as RANGE_MULTIPLIER >> >> ?> line 1531: Any possibility this could lead to divide-by-zero? >> - None which I am aware of, unless you are pointing to the issue like >> JDK-8211161, which we know is not an issue. >> >> Regards, >> Nishit Jain >> On 23-11-2018 15:55, Nishit Jain wrote: >>> Hi Naoto, >>> >>> > I think DecimalFormat and CNF should behave the same, ie. 'E' >>> should be treated as the exponent without a quote. >>> >>> Personally I don't think that the exponential parsing should be >>> supported by CompactNumberFormat, because the objective of compact >>> numbers is to represent numbers in short form. So, parsing of number >>> format like "1.05E4K" should not be expected from >>> CompactNumberFormat, I am even doubtful that such forms ("1.05E4K") >>> are used anywhere where exponential and compact form are together >>> used. If formatting and parsing of exponential numbers are needed it >>> should be done by DecimalFormat scientific instance *not *with the >>> general number instance.So, I don't think that we should allow >>> parsing of exponential numbers.Comments welcome. >>> >>> Regards, >>> Nishit Jain >>> On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >>>> Hi Nishit, >>>> >>>> On 11/21/18 12:53 AM, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> Updated the webrev based on suggestions >>>>> >>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>>>> >>>>> Changes made: >>>>> - Replaced List with String[] to be added to the the >>>>> resource bundles >>>> >>>> Good. >>>> >>>>> - refactored DecimalFormat.subparse() to be used by the >>>>> CNF.parse(), to reduce code duplication. >>>> >>>> I presume CNF is calling package-private methods in DF to share the >>>> same code. Some comments noting the sharing would be helpful. >>>> >>>>> - Also updated it with other changes as suggested in the comments >>>> >>>> Sorry I missed your question the last time: >>>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>> >>> should avoid parsing exponential numbers? Or, should >>>> CNF.parse() be >>>> >>> modified to be consistent with DecimalFormat.parse() in this >>>> aspect? >>>> >>>> I think DecimalFormat and CNF should behave the same, ie. 'E' >>>> should be treated as the exponent without a quote. >>>> >>>> Some more comments (all in CompactNumberFormat.java) >>>> >>>> line 807: expandAffix() seems to treat localizable special pattern >>>> characters, but currently the implementation only cares for the >>>> minus sign. Should other localizable pattern chars be taken care >>>> of, such as percent sign? >>>> >>>> line 869, 888: Define what -1 means as a ret value. >>>> >>>> line 897: iterMultiplier be better all capitalized as it is a >>>> constant. And it could be statically defined in the class to be >>>> shared with other locations that use "10" for arithmetic operation. >>>> >>>> line 1531: Any possibility this could lead to divide-by-zero? >>>> >>>> Naoto >>>> >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>>>> Hi Nishit, >>>>>> >>>>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>>>> Hi Naoto, >>>>>>> >>>>>>> Please check my comments inline. >>>>>>> >>>>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>>>> Hi Nishit, >>>>>>>> >>>>>>>> Here are my comments: >>>>>>>> >>>>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>>>> List, can we eliminate stringListEntry/Element, and use >>>>>>>> Array equivalent instead? >>>>>>> Since the CNF design does not put any limit on the size of >>>>>>> compact pattern, so at the time of parsing the CLDR xmls using >>>>>>> SAX parser, it becomes difficult to identify the size of array >>>>>>> when the parent element of compact pattern is encountered, so I >>>>>>> think it is better to keep the List while extracting the >>>>>>> resources. >>>>>> >>>>>> OK. However I'd not keep the List format on generating >>>>>> the resource bundle, as there is no reason to introduce yet >>>>>> another bundle format other than the existing array of String. >>>>>> >>>>>>>> >>>>>>>> - CompactNumberFormat.java >>>>>>>> >>>>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>>>> OK >>>>>>>> >>>>>>>> line 268: The link points to >>>>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>>>> OK. Changed it at line 165 also. >>>>>>>> >>>>>>>> line 855: no need to do toString(). length() can detect whether >>>>>>>> it's empty or not. >>>>>>>> >>>>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>>>> specializing in the "given number" into either long or biginteger. >>>>>>> OK >>>>>>>> >>>>>>>> line 1500: subparseNumber() pretty much shares the same code >>>>>>>> with DecimalFormat.subparse(). can they be merged? >>>>>>> The existing CNF.subParseNumber differs in the way >>>>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>>>> multipliers are involved (Please see JDK-8199223). >>>>>>> >>>>>>> Also, I had thought that the CNF.parse()/subparseNumber() should >>>>>>> *not *parse the exponential notation e.g. while parsing >>>>>>> "1.05E4K" the parsing should break at 'E' and returns 1.05, >>>>>>> because 'E' should be considered as unparseable character for >>>>>>> general number format pattern or compact number pattern, but >>>>>>> this is not the case with DecimalFormat.parse(). The below >>>>>>> DecimalFormat general number format instance >>>>>>> >>>>>>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>>>>>> nf.parse("1.05E4") >>>>>>> >>>>>>> Successfully parse the string and returns 10500. The same >>>>>>> behaviour is there with other DecimalFormat instances also e.g. >>>>>>> currency instance. >>>>>>> >>>>>>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>>>> should avoid parsing exponential numbers? Or, should CNF.parse() >>>>>>> be modified to be consistent with DecimalFormat.parse() in this >>>>>>> aspect? >>>>>> >>>>>> No, I understand there are differences. But I see a lot of >>>>>> duplicated piece of code which I would like to eliminate. >>>>>> >>>>>>> >>>>>>>> >>>>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply >>>>>>>> calls super. No need to override them. >>>>>>> Since setters are overridden, I think that it is better to >>>>>>> override getters also (even if they are just calling super and >>>>>>> have same javadoc) to keep them at same level. But, if you see >>>>>>> no point in keeping them in CNF, I will remove them. Does that >>>>>>> need CSR change? >>>>>> >>>>>> I don't see any point for override. I don't think there needs a >>>>>> CSR, but better ask Joe about it. >>>>>> >>>>>>>> >>>>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>>>> ClassCastException may be thrown. >>>>>>> The type is checked in the superclass equals method getClass() >>>>>>> != obj.getClass(), so I think there is no need to check the type >>>>>>> here. >>>>>> >>>>>> OK. >>>>>> >>>>>> Naoto >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Nishit Jain >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Please review this non trivial feature addition to >>>>>>>>> NumberFormat API. >>>>>>>>> >>>>>>>>> The existing NumberFormat API provides locale based support >>>>>>>>> for formatting and parsing numbers which includes formatting >>>>>>>>> decimal, percent, currency etc, but the support for formatting >>>>>>>>> a number into a human readable or compact form is missing. >>>>>>>>> This RFE adds that feature to format a decimal number in a >>>>>>>>> compact format (e.g. 1000 -> 1K, 1000000 -> 1M in en_US >>>>>>>>> locale) , which is useful for the environment where display >>>>>>>>> space is limited, so that the formatted string can be >>>>>>>>> displayed in that limited space. It is defined by LDML's >>>>>>>>> specification for Compact Number Formats. >>>>>>>>> >>>>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>>>> Webrev: >>>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>>>> >>>>>>>>> Request to please help review the the change. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Nishit Jain >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>> >> From naoto.sato at oracle.com Tue Nov 27 15:25:19 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 27 Nov 2018 07:25:19 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> Message-ID: <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> Hi Nishit, On 11/26/18 11:11 PM, Nishit Jain wrote: > Hi Naoto, > > On 26-11-2018 21:01, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> On 11/26/18 12:41 AM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> To add to my previous mail comment, the DecimalFormat spec also says >>> that >>> >>> /*"DecimalFormat can be instructed to format and parse scientific >>> notation only via a pattern; there is currently no factory method >>> that creates a scientific notation format. In a pattern, the exponent >>> character immediately followed by one or more digit characters >>> indicates scientific notation. " >>> >>> */That is, exponent formatting and parsing is instructed only via a >>> scientific notation pattern and I think should not be there with >>> *general number* formatting. >> >> I am not sure the quoted sentence should be interpreted that way. My >> understanding is that the section means there is no public >> NumberFormat.getScientificInstance() method (cf. line 601 at >> NumberFormat.java), so that users will have to use 'E' in their >> pattern string. >> >> Anyway, my point is that if you prefer to treat the scientific >> notation differently between DecimalFormat and CompactDecimalFormat, >> then it will need to be clarified in the spec. Personally I agree that >> it is not practical to interpret E in the CNF. > OK. If it is better to specify the parsing behavior w.r.t. the > exponential numbers, I have added a statement in the parse() API. > > */"CompactNumberFormat parse does not allow parsing exponential number > strings. For example, parsing a string "1.05E4K" in US locale breaks at > character 'E' and returns 1.05."/* That's better. I'd replace "exponential number strings" with "scientific notations." You may want to check the final wording with English natives. > > Updated the webrev > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.03/ > > Will also update the CSR and refinalize it. Thanks. Naoto > > Regards, > Nishit Jain >> >> Naoto >> >>> >>> Updated webrev based on the other comments >>> >>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ >>> >>> ?> Some more comments (all in CompactNumberFormat.java) >>> >>> ?> line 807: expandAffix() seems to treat localizable special pattern >>> characters, but currently the implementation only cares for the minus >>> sign. Should other localizable pattern chars be taken care of, such >>> as percent sign? >>> - Other special characters like '%' percent sign are not allowed as >>> per CNF compact pattern spec >>> >>> ?> line 869, 888: Define what -1 means as a ret value. >>> - OK. >>> >>> ?> line 897: iterMultiplier be better all capitalized as it is a >>> constant. And it could be statically defined in the class to be >>> shared with other locations that use "10" for arithmetic operation. >>> - OK, made it static final and renamed it as RANGE_MULTIPLIER >>> >>> ?> line 1531: Any possibility this could lead to divide-by-zero? >>> - None which I am aware of, unless you are pointing to the issue like >>> JDK-8211161, which we know is not an issue. >>> >>> Regards, >>> Nishit Jain >>> On 23-11-2018 15:55, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> > I think DecimalFormat and CNF should behave the same, ie. 'E' >>>> should be treated as the exponent without a quote. >>>> >>>> Personally I don't think that the exponential parsing should be >>>> supported by CompactNumberFormat, because the objective of compact >>>> numbers is to represent numbers in short form. So, parsing of number >>>> format like "1.05E4K" should not be expected from >>>> CompactNumberFormat, I am even doubtful that such forms ("1.05E4K") >>>> are used anywhere where exponential and compact form are together >>>> used. If formatting and parsing of exponential numbers are needed it >>>> should be done by DecimalFormat scientific instance *not *with the >>>> general number instance.So, I don't think that we should allow >>>> parsing of exponential numbers.Comments welcome. >>>> >>>> Regards, >>>> Nishit Jain >>>> On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >>>>> Hi Nishit, >>>>> >>>>> On 11/21/18 12:53 AM, Nishit Jain wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> Updated the webrev based on suggestions >>>>>> >>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>>>>> >>>>>> Changes made: >>>>>> - Replaced List with String[] to be added to the the >>>>>> resource bundles >>>>> >>>>> Good. >>>>> >>>>>> - refactored DecimalFormat.subparse() to be used by the >>>>>> CNF.parse(), to reduce code duplication. >>>>> >>>>> I presume CNF is calling package-private methods in DF to share the >>>>> same code. Some comments noting the sharing would be helpful. >>>>> >>>>>> - Also updated it with other changes as suggested in the comments >>>>> >>>>> Sorry I missed your question the last time: >>>>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>> >>> should avoid parsing exponential numbers? Or, should >>>>> CNF.parse() be >>>>> >>> modified to be consistent with DecimalFormat.parse() in this >>>>> aspect? >>>>> >>>>> I think DecimalFormat and CNF should behave the same, ie. 'E' >>>>> should be treated as the exponent without a quote. >>>>> >>>>> Some more comments (all in CompactNumberFormat.java) >>>>> >>>>> line 807: expandAffix() seems to treat localizable special pattern >>>>> characters, but currently the implementation only cares for the >>>>> minus sign. Should other localizable pattern chars be taken care >>>>> of, such as percent sign? >>>>> >>>>> line 869, 888: Define what -1 means as a ret value. >>>>> >>>>> line 897: iterMultiplier be better all capitalized as it is a >>>>> constant. And it could be statically defined in the class to be >>>>> shared with other locations that use "10" for arithmetic operation. >>>>> >>>>> line 1531: Any possibility this could lead to divide-by-zero? >>>>> >>>>> Naoto >>>>> >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>>>>> Hi Nishit, >>>>>>> >>>>>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>>>>> Hi Naoto, >>>>>>>> >>>>>>>> Please check my comments inline. >>>>>>>> >>>>>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>>>>> Hi Nishit, >>>>>>>>> >>>>>>>>> Here are my comments: >>>>>>>>> >>>>>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>>>>> List, can we eliminate stringListEntry/Element, and use >>>>>>>>> Array equivalent instead? >>>>>>>> Since the CNF design does not put any limit on the size of >>>>>>>> compact pattern, so at the time of parsing the CLDR xmls using >>>>>>>> SAX parser, it becomes difficult to identify the size of array >>>>>>>> when the parent element of compact pattern is encountered, so I >>>>>>>> think it is better to keep the List while extracting the >>>>>>>> resources. >>>>>>> >>>>>>> OK. However I'd not keep the List format on generating >>>>>>> the resource bundle, as there is no reason to introduce yet >>>>>>> another bundle format other than the existing array of String. >>>>>>> >>>>>>>>> >>>>>>>>> - CompactNumberFormat.java >>>>>>>>> >>>>>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>>>>> OK >>>>>>>>> >>>>>>>>> line 268: The link points to >>>>>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>>>>> OK. Changed it at line 165 also. >>>>>>>>> >>>>>>>>> line 855: no need to do toString(). length() can detect whether >>>>>>>>> it's empty or not. >>>>>>>>> >>>>>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>>>>> specializing in the "given number" into either long or biginteger. >>>>>>>> OK >>>>>>>>> >>>>>>>>> line 1500: subparseNumber() pretty much shares the same code >>>>>>>>> with DecimalFormat.subparse(). can they be merged? >>>>>>>> The existing CNF.subParseNumber differs in the way >>>>>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>>>>> multipliers are involved (Please see JDK-8199223). >>>>>>>> >>>>>>>> Also, I had thought that the CNF.parse()/subparseNumber() should >>>>>>>> *not *parse the exponential notation e.g. while parsing >>>>>>>> "1.05E4K" the parsing should break at 'E' and returns 1.05, >>>>>>>> because 'E' should be considered as unparseable character for >>>>>>>> general number format pattern or compact number pattern, but >>>>>>>> this is not the case with DecimalFormat.parse(). The below >>>>>>>> DecimalFormat general number format instance >>>>>>>> >>>>>>>> NumberFormat nf =? NumberFormat.getNumberInstance(); >>>>>>>> nf.parse("1.05E4") >>>>>>>> >>>>>>>> Successfully parse the string and returns 10500. The same >>>>>>>> behaviour is there with other DecimalFormat instances also e.g. >>>>>>>> currency instance. >>>>>>>> >>>>>>>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>>>>> should avoid parsing exponential numbers? Or, should CNF.parse() >>>>>>>> be modified to be consistent with DecimalFormat.parse() in this >>>>>>>> aspect? >>>>>>> >>>>>>> No, I understand there are differences. But I see a lot of >>>>>>> duplicated piece of code which I would like to eliminate. >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply >>>>>>>>> calls super. No need to override them. >>>>>>>> Since setters are overridden, I think that it is better to >>>>>>>> override getters also (even if they are just calling super and >>>>>>>> have same javadoc) to keep them at same level. But, if you see >>>>>>>> no point in keeping them in CNF, I will remove them. Does that >>>>>>>> need CSR change? >>>>>>> >>>>>>> I don't see any point for override. I don't think there needs a >>>>>>> CSR, but better ask Joe about it. >>>>>>> >>>>>>>>> >>>>>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>>>>> ClassCastException may be thrown. >>>>>>>> The type is checked in the superclass equals method getClass() >>>>>>>> != obj.getClass(), so I think there is no need to check the type >>>>>>>> here. >>>>>>> >>>>>>> OK. >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nishit Jain >>>>>>>>> >>>>>>>>> Naoto >>>>>>>>> >>>>>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> Please review this non trivial feature addition to >>>>>>>>>> NumberFormat API. >>>>>>>>>> >>>>>>>>>> The existing NumberFormat API provides locale based support >>>>>>>>>> for formatting and parsing numbers which includes formatting >>>>>>>>>> decimal, percent, currency etc, but the support for formatting >>>>>>>>>> a number into a human readable or compact form is missing. >>>>>>>>>> This RFE adds that feature to format a decimal number in a >>>>>>>>>> compact format (e.g. 1000 -> 1K, 1000000 -> 1M in en_US >>>>>>>>>> locale) , which is useful for the environment where display >>>>>>>>>> space is limited, so that the formatted string can be >>>>>>>>>> displayed in that limited space. It is defined by LDML's >>>>>>>>>> specification for Compact Number Formats. >>>>>>>>>> >>>>>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>>>>> Webrev: >>>>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>>>>> >>>>>>>>>> Request to please help review the the change. >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nishit Jain >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From nishit.jain at oracle.com Wed Nov 28 11:46:42 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 28 Nov 2018 17:16:42 +0530 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> Message-ID: <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> Thanks Naoto, Updated. http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ Regards, Nishit Jain On 27-11-2018 20:55, naoto.sato at oracle.com wrote: > Hi Nishit, > > On 11/26/18 11:11 PM, Nishit Jain wrote: >> Hi Naoto, >> >> On 26-11-2018 21:01, naoto.sato at oracle.com wrote: >>> Hi Nishit, >>> >>> On 11/26/18 12:41 AM, Nishit Jain wrote: >>>> Hi Naoto, >>>> >>>> To add to my previous mail comment, the DecimalFormat spec also >>>> says that >>>> >>>> /*"DecimalFormat can be instructed to format and parse scientific >>>> notation only via a pattern; there is currently no factory method >>>> that creates a scientific notation format. In a pattern, the >>>> exponent character immediately followed by one or more digit >>>> characters indicates scientific notation. " >>>> >>>> */That is, exponent formatting and parsing is instructed only via a >>>> scientific notation pattern and I think should not be there with >>>> *general number* formatting. >>> >>> I am not sure the quoted sentence should be interpreted that way. My >>> understanding is that the section means there is no public >>> NumberFormat.getScientificInstance() method (cf. line 601 at >>> NumberFormat.java), so that users will have to use 'E' in their >>> pattern string. >>> >>> Anyway, my point is that if you prefer to treat the scientific >>> notation differently between DecimalFormat and CompactDecimalFormat, >>> then it will need to be clarified in the spec. Personally I agree >>> that it is not practical to interpret E in the CNF. >> OK. If it is better to specify the parsing behavior w.r.t. the >> exponential numbers, I have added a statement in the parse() API. >> >> */"CompactNumberFormat parse does not allow parsing exponential >> number strings. For example, parsing a string "1.05E4K" in US locale >> breaks at character 'E' and returns 1.05."/* > > That's better. I'd replace "exponential number strings" with > "scientific notations." You may want to check the final wording with > English natives. > >> >> Updated the webrev >> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.03/ >> >> Will also update the CSR and refinalize it. > > Thanks. > > Naoto > >> >> Regards, >> Nishit Jain >>> >>> Naoto >>> >>>> >>>> Updated webrev based on the other comments >>>> >>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ >>>> >>>> ?> Some more comments (all in CompactNumberFormat.java) >>>> >>>> ?> line 807: expandAffix() seems to treat localizable special >>>> pattern characters, but currently the implementation only cares for >>>> the minus sign. Should other localizable pattern chars be taken >>>> care of, such as percent sign? >>>> - Other special characters like '%' percent sign are not allowed as >>>> per CNF compact pattern spec >>>> >>>> ?> line 869, 888: Define what -1 means as a ret value. >>>> - OK. >>>> >>>> ?> line 897: iterMultiplier be better all capitalized as it is a >>>> constant. And it could be statically defined in the class to be >>>> shared with other locations that use "10" for arithmetic operation. >>>> - OK, made it static final and renamed it as RANGE_MULTIPLIER >>>> >>>> ?> line 1531: Any possibility this could lead to divide-by-zero? >>>> - None which I am aware of, unless you are pointing to the issue >>>> like JDK-8211161, which we know is not an issue. >>>> >>>> Regards, >>>> Nishit Jain >>>> On 23-11-2018 15:55, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> > I think DecimalFormat and CNF should behave the same, ie. 'E' >>>>> should be treated as the exponent without a quote. >>>>> >>>>> Personally I don't think that the exponential parsing should be >>>>> supported by CompactNumberFormat, because the objective of compact >>>>> numbers is to represent numbers in short form. So, parsing of >>>>> number format like "1.05E4K" should not be expected from >>>>> CompactNumberFormat, I am even doubtful that such forms >>>>> ("1.05E4K") are used anywhere where exponential and compact form >>>>> are together used. If formatting and parsing of exponential >>>>> numbers are needed it should be done by DecimalFormat scientific >>>>> instance *not *with the general number instance.So, I don't think >>>>> that we should allow parsing of exponential numbers.Comments welcome. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >>>>>> Hi Nishit, >>>>>> >>>>>> On 11/21/18 12:53 AM, Nishit Jain wrote: >>>>>>> Hi Naoto, >>>>>>> >>>>>>> Updated the webrev based on suggestions >>>>>>> >>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>>>>>> >>>>>>> Changes made: >>>>>>> - Replaced List with String[] to be added to the the >>>>>>> resource bundles >>>>>> >>>>>> Good. >>>>>> >>>>>>> - refactored DecimalFormat.subparse() to be used by the >>>>>>> CNF.parse(), to reduce code duplication. >>>>>> >>>>>> I presume CNF is calling package-private methods in DF to share >>>>>> the same code. Some comments noting the sharing would be helpful. >>>>>> >>>>>>> - Also updated it with other changes as suggested in the comments >>>>>> >>>>>> Sorry I missed your question the last time: >>>>>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>>> >>> should avoid parsing exponential numbers? Or, should >>>>>> CNF.parse() be >>>>>> >>> modified to be consistent with DecimalFormat.parse() in this >>>>>> aspect? >>>>>> >>>>>> I think DecimalFormat and CNF should behave the same, ie. 'E' >>>>>> should be treated as the exponent without a quote. >>>>>> >>>>>> Some more comments (all in CompactNumberFormat.java) >>>>>> >>>>>> line 807: expandAffix() seems to treat localizable special >>>>>> pattern characters, but currently the implementation only cares >>>>>> for the minus sign. Should other localizable pattern chars be >>>>>> taken care of, such as percent sign? >>>>>> >>>>>> line 869, 888: Define what -1 means as a ret value. >>>>>> >>>>>> line 897: iterMultiplier be better all capitalized as it is a >>>>>> constant. And it could be statically defined in the class to be >>>>>> shared with other locations that use "10" for arithmetic operation. >>>>>> >>>>>> line 1531: Any possibility this could lead to divide-by-zero? >>>>>> >>>>>> Naoto >>>>>> >>>>>>> >>>>>>> Regards, >>>>>>> Nishit Jain >>>>>>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>>>>>> Hi Nishit, >>>>>>>> >>>>>>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>>>>>> Hi Naoto, >>>>>>>>> >>>>>>>>> Please check my comments inline. >>>>>>>>> >>>>>>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>>>>>> Hi Nishit, >>>>>>>>>> >>>>>>>>>> Here are my comments: >>>>>>>>>> >>>>>>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>>>>>> List, can we eliminate stringListEntry/Element, and >>>>>>>>>> use Array equivalent instead? >>>>>>>>> Since the CNF design does not put any limit on the size of >>>>>>>>> compact pattern, so at the time of parsing the CLDR xmls using >>>>>>>>> SAX parser, it becomes difficult to identify the size of array >>>>>>>>> when the parent element of compact pattern is encountered, so >>>>>>>>> I think it is better to keep the List while extracting >>>>>>>>> the resources. >>>>>>>> >>>>>>>> OK. However I'd not keep the List format on generating >>>>>>>> the resource bundle, as there is no reason to introduce yet >>>>>>>> another bundle format other than the existing array of String. >>>>>>>> >>>>>>>>>> >>>>>>>>>> - CompactNumberFormat.java >>>>>>>>>> >>>>>>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>>>>>> OK >>>>>>>>>> >>>>>>>>>> line 268: The link points to >>>>>>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>>>>>> OK. Changed it at line 165 also. >>>>>>>>>> >>>>>>>>>> line 855: no need to do toString(). length() can detect >>>>>>>>>> whether it's empty or not. >>>>>>>>>> >>>>>>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>>>>>> specializing in the "given number" into either long or >>>>>>>>>> biginteger. >>>>>>>>> OK >>>>>>>>>> >>>>>>>>>> line 1500: subparseNumber() pretty much shares the same code >>>>>>>>>> with DecimalFormat.subparse(). can they be merged? >>>>>>>>> The existing CNF.subParseNumber differs in the way >>>>>>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>>>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>>>>>> multipliers are involved (Please see JDK-8199223). >>>>>>>>> >>>>>>>>> Also, I had thought that the CNF.parse()/subparseNumber() >>>>>>>>> should *not *parse the exponential notation e.g. while parsing >>>>>>>>> "1.05E4K" the parsing should break at 'E' and returns 1.05, >>>>>>>>> because 'E' should be considered as unparseable character for >>>>>>>>> general number format pattern or compact number pattern, but >>>>>>>>> this is not the case with DecimalFormat.parse(). The below >>>>>>>>> DecimalFormat general number format instance >>>>>>>>> >>>>>>>>> NumberFormat nf = NumberFormat.getNumberInstance(); >>>>>>>>> nf.parse("1.05E4") >>>>>>>>> >>>>>>>>> Successfully parse the string and returns 10500. The same >>>>>>>>> behaviour is there with other DecimalFormat instances also >>>>>>>>> e.g. currency instance. >>>>>>>>> >>>>>>>>> Do you think this is an issue with DecimalFormat.parse() and >>>>>>>>> CNF should avoid parsing exponential numbers? Or, should >>>>>>>>> CNF.parse() be modified to be consistent with >>>>>>>>> DecimalFormat.parse() in this aspect? >>>>>>>> >>>>>>>> No, I understand there are differences. But I see a lot of >>>>>>>> duplicated piece of code which I would like to eliminate. >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply >>>>>>>>>> calls super. No need to override them. >>>>>>>>> Since setters are overridden, I think that it is better to >>>>>>>>> override getters also (even if they are just calling super and >>>>>>>>> have same javadoc) to keep them at same level. But, if you see >>>>>>>>> no point in keeping them in CNF, I will remove them. Does that >>>>>>>>> need CSR change? >>>>>>>> >>>>>>>> I don't see any point for override. I don't think there needs a >>>>>>>> CSR, but better ask Joe about it. >>>>>>>> >>>>>>>>>> >>>>>>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>>>>>> ClassCastException may be thrown. >>>>>>>>> The type is checked in the superclass equals method getClass() >>>>>>>>> != obj.getClass(), so I think there is no need to check the >>>>>>>>> type here. >>>>>>>> >>>>>>>> OK. >>>>>>>> >>>>>>>> Naoto >>>>>>>> >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Nishit Jain >>>>>>>>>> >>>>>>>>>> Naoto >>>>>>>>>> >>>>>>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> Please review this non trivial feature addition to >>>>>>>>>>> NumberFormat API. >>>>>>>>>>> >>>>>>>>>>> The existing NumberFormat API provides locale based support >>>>>>>>>>> for formatting and parsing numbers which includes formatting >>>>>>>>>>> decimal, percent, currency etc, but the support for >>>>>>>>>>> formatting a number into a human readable or compact form is >>>>>>>>>>> missing. This RFE adds that feature to format a decimal >>>>>>>>>>> number in a compact format (e.g. 1000 -> 1K, 1000000 -> 1M >>>>>>>>>>> in en_US locale) , which is useful for the environment where >>>>>>>>>>> display space is limited, so that the formatted string can >>>>>>>>>>> be displayed in that limited space. It is defined by LDML's >>>>>>>>>>> specification for Compact Number Formats. >>>>>>>>>>> >>>>>>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>>>>>> Webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>>>>>> >>>>>>>>>>> Request to please help review the the change. >>>>>>>>>>> >>>>>>>>>>> Regards, >>>>>>>>>>> Nishit Jain >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>> >>>> >> From naoto.sato at oracle.com Wed Nov 28 14:02:21 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 28 Nov 2018 06:02:21 -0800 Subject: RFR 8177552: Compact Number Formatting support In-Reply-To: <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> References: <9ab69c32-4873-697c-388c-416069fff9b2@oracle.com> <5af036a7-750c-b265-3d6b-0b88b3008aad@oracle.com> <3bc51280-278f-0c98-c9f9-b088fefd71f7@oracle.com> <1b89f702-5dfe-ecbc-afff-58c5b017a069@oracle.com> <27748ff4-a11a-5612-8958-a32e84ce9034@oracle.com> <0234d5ff-d1c8-3f02-f457-3c9804a72972@oracle.com> <8bc23ea9-1ee2-4da9-36e0-3ad689c41229@oracle.com> Message-ID: <60acf63c-b9f8-49f2-e04d-4484a5327982@oracle.com> Looks good to me. Naoto On 11/28/18 3:46 AM, Nishit Jain wrote: > Thanks Naoto, > > Updated. > > http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.04/ > > Regards, > Nishit Jain > On 27-11-2018 20:55, naoto.sato at oracle.com wrote: >> Hi Nishit, >> >> On 11/26/18 11:11 PM, Nishit Jain wrote: >>> Hi Naoto, >>> >>> On 26-11-2018 21:01, naoto.sato at oracle.com wrote: >>>> Hi Nishit, >>>> >>>> On 11/26/18 12:41 AM, Nishit Jain wrote: >>>>> Hi Naoto, >>>>> >>>>> To add to my previous mail comment, the DecimalFormat spec also >>>>> says that >>>>> >>>>> /*"DecimalFormat can be instructed to format and parse scientific >>>>> notation only via a pattern; there is currently no factory method >>>>> that creates a scientific notation format. In a pattern, the >>>>> exponent character immediately followed by one or more digit >>>>> characters indicates scientific notation. " >>>>> >>>>> */That is, exponent formatting and parsing is instructed only via a >>>>> scientific notation pattern and I think should not be there with >>>>> *general number* formatting. >>>> >>>> I am not sure the quoted sentence should be interpreted that way. My >>>> understanding is that the section means there is no public >>>> NumberFormat.getScientificInstance() method (cf. line 601 at >>>> NumberFormat.java), so that users will have to use 'E' in their >>>> pattern string. >>>> >>>> Anyway, my point is that if you prefer to treat the scientific >>>> notation differently between DecimalFormat and CompactDecimalFormat, >>>> then it will need to be clarified in the spec. Personally I agree >>>> that it is not practical to interpret E in the CNF. >>> OK. If it is better to specify the parsing behavior w.r.t. the >>> exponential numbers, I have added a statement in the parse() API. >>> >>> */"CompactNumberFormat parse does not allow parsing exponential >>> number strings. For example, parsing a string "1.05E4K" in US locale >>> breaks at character 'E' and returns 1.05."/* >> >> That's better. I'd replace "exponential number strings" with >> "scientific notations." You may want to check the final wording with >> English natives. >> >>> >>> Updated the webrev >>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.03/ >>> >>> Will also update the CSR and refinalize it. >> >> Thanks. >> >> Naoto >> >>> >>> Regards, >>> Nishit Jain >>>> >>>> Naoto >>>> >>>>> >>>>> Updated webrev based on the other comments >>>>> >>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.02/ >>>>> >>>>> ?> Some more comments (all in CompactNumberFormat.java) >>>>> >>>>> ?> line 807: expandAffix() seems to treat localizable special >>>>> pattern characters, but currently the implementation only cares for >>>>> the minus sign. Should other localizable pattern chars be taken >>>>> care of, such as percent sign? >>>>> - Other special characters like '%' percent sign are not allowed as >>>>> per CNF compact pattern spec >>>>> >>>>> ?> line 869, 888: Define what -1 means as a ret value. >>>>> - OK. >>>>> >>>>> ?> line 897: iterMultiplier be better all capitalized as it is a >>>>> constant. And it could be statically defined in the class to be >>>>> shared with other locations that use "10" for arithmetic operation. >>>>> - OK, made it static final and renamed it as RANGE_MULTIPLIER >>>>> >>>>> ?> line 1531: Any possibility this could lead to divide-by-zero? >>>>> - None which I am aware of, unless you are pointing to the issue >>>>> like JDK-8211161, which we know is not an issue. >>>>> >>>>> Regards, >>>>> Nishit Jain >>>>> On 23-11-2018 15:55, Nishit Jain wrote: >>>>>> Hi Naoto, >>>>>> >>>>>> > I think DecimalFormat and CNF should behave the same, ie. 'E' >>>>>> should be treated as the exponent without a quote. >>>>>> >>>>>> Personally I don't think that the exponential parsing should be >>>>>> supported by CompactNumberFormat, because the objective of compact >>>>>> numbers is to represent numbers in short form. So, parsing of >>>>>> number format like "1.05E4K" should not be expected from >>>>>> CompactNumberFormat, I am even doubtful that such forms >>>>>> ("1.05E4K") are used anywhere where exponential and compact form >>>>>> are together used. If formatting and parsing of exponential >>>>>> numbers are needed it should be done by DecimalFormat scientific >>>>>> instance *not *with the general number instance.So, I don't think >>>>>> that we should allow parsing of exponential numbers.Comments welcome. >>>>>> >>>>>> Regards, >>>>>> Nishit Jain >>>>>> On 22-11-2018 02:02, naoto.sato at oracle.com wrote: >>>>>>> Hi Nishit, >>>>>>> >>>>>>> On 11/21/18 12:53 AM, Nishit Jain wrote: >>>>>>>> Hi Naoto, >>>>>>>> >>>>>>>> Updated the webrev based on suggestions >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.01/ >>>>>>>> >>>>>>>> Changes made: >>>>>>>> - Replaced List with String[] to be added to the the >>>>>>>> resource bundles >>>>>>> >>>>>>> Good. >>>>>>> >>>>>>>> - refactored DecimalFormat.subparse() to be used by the >>>>>>>> CNF.parse(), to reduce code duplication. >>>>>>> >>>>>>> I presume CNF is calling package-private methods in DF to share >>>>>>> the same code. Some comments noting the sharing would be helpful. >>>>>>> >>>>>>>> - Also updated it with other changes as suggested in the comments >>>>>>> >>>>>>> Sorry I missed your question the last time: >>>>>>> >>> Do you think this is an issue with DecimalFormat.parse() and CNF >>>>>>> >>> should avoid parsing exponential numbers? Or, should >>>>>>> CNF.parse() be >>>>>>> >>> modified to be consistent with DecimalFormat.parse() in this >>>>>>> aspect? >>>>>>> >>>>>>> I think DecimalFormat and CNF should behave the same, ie. 'E' >>>>>>> should be treated as the exponent without a quote. >>>>>>> >>>>>>> Some more comments (all in CompactNumberFormat.java) >>>>>>> >>>>>>> line 807: expandAffix() seems to treat localizable special >>>>>>> pattern characters, but currently the implementation only cares >>>>>>> for the minus sign. Should other localizable pattern chars be >>>>>>> taken care of, such as percent sign? >>>>>>> >>>>>>> line 869, 888: Define what -1 means as a ret value. >>>>>>> >>>>>>> line 897: iterMultiplier be better all capitalized as it is a >>>>>>> constant. And it could be statically defined in the class to be >>>>>>> shared with other locations that use "10" for arithmetic operation. >>>>>>> >>>>>>> line 1531: Any possibility this could lead to divide-by-zero? >>>>>>> >>>>>>> Naoto >>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Nishit Jain >>>>>>>> On 20-11-2018 00:33, naoto.sato at oracle.com wrote: >>>>>>>>> Hi Nishit, >>>>>>>>> >>>>>>>>> On 11/18/18 10:29 PM, Nishit Jain wrote: >>>>>>>>>> Hi Naoto, >>>>>>>>>> >>>>>>>>>> Please check my comments inline. >>>>>>>>>> >>>>>>>>>> On 17-11-2018 04:52, naoto.sato at oracle.com wrote: >>>>>>>>>>> Hi Nishit, >>>>>>>>>>> >>>>>>>>>>> Here are my comments: >>>>>>>>>>> >>>>>>>>>>> - CLDRConverter: As the compact pattern no more employs >>>>>>>>>>> List, can we eliminate stringListEntry/Element, and >>>>>>>>>>> use Array equivalent instead? >>>>>>>>>> Since the CNF design does not put any limit on the size of >>>>>>>>>> compact pattern, so at the time of parsing the CLDR xmls using >>>>>>>>>> SAX parser, it becomes difficult to identify the size of array >>>>>>>>>> when the parent element of compact pattern is encountered, so >>>>>>>>>> I think it is better to keep the List while extracting >>>>>>>>>> the resources. >>>>>>>>> >>>>>>>>> OK. However I'd not keep the List format on generating >>>>>>>>> the resource bundle, as there is no reason to introduce yet >>>>>>>>> another bundle format other than the existing array of String. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> - CompactNumberFormat.java >>>>>>>>>>> >>>>>>>>>>> Multiple locations: Use StringBuilder instead of StringBuffer. >>>>>>>>>> OK >>>>>>>>>>> >>>>>>>>>>> line 268: The link points to >>>>>>>>>>> NumberFormat.getNumberInstance(Locale) instead of DecimalFormat >>>>>>>>>> OK. Changed it at line 165 also. >>>>>>>>>>> >>>>>>>>>>> line 855: no need to do toString(). length() can detect >>>>>>>>>>> whether it's empty or not. >>>>>>>>>>> >>>>>>>>>>> line 884: "Overloaded method" reads odd here. I'd prefer >>>>>>>>>>> specializing in the "given number" into either long or >>>>>>>>>>> biginteger. >>>>>>>>>> OK >>>>>>>>>>> >>>>>>>>>>> line 1500: subparseNumber() pretty much shares the same code >>>>>>>>>>> with DecimalFormat.subparse(). can they be merged? >>>>>>>>>> The existing CNF.subParseNumber differs in the way >>>>>>>>>> parseIntegerOnly is handled, DecimalFormat.parse()/subparse() >>>>>>>>>> behaviour is unpredictable with parseIntegeronly = true when >>>>>>>>>> multipliers are involved (Please see JDK-8199223). >>>>>>>>>> >>>>>>>>>> Also, I had thought that the CNF.parse()/subparseNumber() >>>>>>>>>> should *not *parse the exponential notation e.g. while parsing >>>>>>>>>> "1.05E4K" the parsing should break at 'E' and returns 1.05, >>>>>>>>>> because 'E' should be considered as unparseable character for >>>>>>>>>> general number format pattern or compact number pattern, but >>>>>>>>>> this is not the case with DecimalFormat.parse(). The below >>>>>>>>>> DecimalFormat general number format instance >>>>>>>>>> >>>>>>>>>> NumberFormat nf = NumberFormat.getNumberInstance(); >>>>>>>>>> nf.parse("1.05E4") >>>>>>>>>> >>>>>>>>>> Successfully parse the string and returns 10500. The same >>>>>>>>>> behaviour is there with other DecimalFormat instances also >>>>>>>>>> e.g. currency instance. >>>>>>>>>> >>>>>>>>>> Do you think this is an issue with DecimalFormat.parse() and >>>>>>>>>> CNF should avoid parsing exponential numbers? Or, should >>>>>>>>>> CNF.parse() be modified to be consistent with >>>>>>>>>> DecimalFormat.parse() in this aspect? >>>>>>>>> >>>>>>>>> No, I understand there are differences. But I see a lot of >>>>>>>>> duplicated piece of code which I would like to eliminate. >>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> line 1913-1923, 1950-1960, 1987-1997, 2024-2034: It simply >>>>>>>>>>> calls super. No need to override them. >>>>>>>>>> Since setters are overridden, I think that it is better to >>>>>>>>>> override getters also (even if they are just calling super and >>>>>>>>>> have same javadoc) to keep them at same level. But, if you see >>>>>>>>>> no point in keeping them in CNF, I will remove them. Does that >>>>>>>>>> need CSR change? >>>>>>>>> >>>>>>>>> I don't see any point for override. I don't think there needs a >>>>>>>>> CSR, but better ask Joe about it. >>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> line 2231: You need to test the type before cast. Otherwise >>>>>>>>>>> ClassCastException may be thrown. >>>>>>>>>> The type is checked in the superclass equals method getClass() >>>>>>>>>> != obj.getClass(), so I think there is no need to check the >>>>>>>>>> type here. >>>>>>>>> >>>>>>>>> OK. >>>>>>>>> >>>>>>>>> Naoto >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Regards, >>>>>>>>>> Nishit Jain >>>>>>>>>>> >>>>>>>>>>> Naoto >>>>>>>>>>> >>>>>>>>>>> On 11/16/18 9:54 AM, Nishit Jain wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Please review this non trivial feature addition to >>>>>>>>>>>> NumberFormat API. >>>>>>>>>>>> >>>>>>>>>>>> The existing NumberFormat API provides locale based support >>>>>>>>>>>> for formatting and parsing numbers which includes formatting >>>>>>>>>>>> decimal, percent, currency etc, but the support for >>>>>>>>>>>> formatting a number into a human readable or compact form is >>>>>>>>>>>> missing. This RFE adds that feature to format a decimal >>>>>>>>>>>> number in a compact format (e.g. 1000 -> 1K, 1000000 -> 1M >>>>>>>>>>>> in en_US locale) , which is useful for the environment where >>>>>>>>>>>> display space is limited, so that the formatted string can >>>>>>>>>>>> be displayed in that limited space. It is defined by LDML's >>>>>>>>>>>> specification for Compact Number Formats. >>>>>>>>>>>> >>>>>>>>>>>> http://unicode.org/reports/tr35/tr35-numbers.html#Compact_Number_Formats >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> RFE: https://bugs.openjdk.java.net/browse/JDK-8177552 >>>>>>>>>>>> Webrev: >>>>>>>>>>>> http://cr.openjdk.java.net/~nishjain/8177552/webrevs/webrev.00/ >>>>>>>>>>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8188147 >>>>>>>>>>>> >>>>>>>>>>>> Request to please help review the the change. >>>>>>>>>>>> >>>>>>>>>>>> Regards, >>>>>>>>>>>> Nishit Jain >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >>>>> >>> > From nishit.jain at oracle.com Fri Nov 30 06:14:00 2018 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 30 Nov 2018 11:44:00 +0530 Subject: [12] RFR 8213294: Upgrade IANA LSR data Message-ID: Hi, Please review the fix for 8213294, which upgrades the IANA LSR data to the latest available version. Bug: https://bugs.openjdk.java.net/browse/JDK-8213294 Webrev: http://cr.openjdk.java.net/~nishjain/8213294/webrev.00 Regards, Nishit Jain From naoto.sato at oracle.com Fri Nov 30 16:20:13 2018 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 30 Nov 2018 08:20:13 -0800 Subject: [12] RFR 8213294: Upgrade IANA LSR data In-Reply-To: References: Message-ID: <40e4637a-01c9-1426-ce2d-7a91f80b502a@oracle.com> Looks good. Please add noreg-* keyword to the issue. Naoto On 11/29/18 10:14 PM, Nishit Jain wrote: > Hi, > > Please review the fix for 8213294, which upgrades the IANA LSR data to > the latest available version. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8213294 > Webrev: http://cr.openjdk.java.net/~nishjain/8213294/webrev.00 > > > Regards, > Nishit Jain