From naoto.sato at oracle.com Mon May 6 17:24:18 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 6 May 2019 10:24:18 -0700 Subject: [13] RFR: 8220037: Inconsistencies of generated timezone files between Windows and Linux Message-ID: <970a6046-f5b7-3e73-c9b1-72227be18e1e@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8220037 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8220037/webrev.00/ The inconsistency comes from the different enumeration order of CLDR source files on each platform. Fix is to sort its order uniquely. Naoto From naoto.sato at oracle.com Tue May 7 20:12:00 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 7 May 2019 13:12:00 -0700 Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1 Message-ID: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221432 The proposed changeset is located at: http://cr.openjdk.java.net/~naoto/8221432/webrev.02/ The webrev is big, but the large amount of the changes is simply replacing the CLDR data files from v33 to v35.1, which includes the translations for the Japanese new era, Reiwa. Naoto From srl at icu-project.org Tue May 7 20:32:32 2019 From: srl at icu-project.org (Steven R. Loomis) Date: Tue, 7 May 2019 13:32:32 -0700 Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1 In-Reply-To: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> Message-ID: <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org> Hi Naoto, The comment in http://cr.openjdk.java.net/~naoto/8221432/webrev.02/make/jdk/src/classes/build/tools/cldrconverter/Bundle.java.udiff.html "fix up 'Reiwa' era, which can be missing in some locales? seems to imply that fallback resolution isn?t working properly, because that data (R) is present in root.xml. The deleted comment in the same file, "Some locale data has no default script for numbering even with mutiple scripts? is not true for the same reason. Otherwise the changes look as expected on a spot check. -- Steven R. Loomis | @srl295 | git.io/srl295 > El may. 7, 2019, a las 1:12 p. m., naoto.sato at oracle.com escribi?: > > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8221432 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8221432/webrev.02/ > > The webrev is big, but the large amount of the changes is simply replacing the CLDR data files from v33 to v35.1, which includes the translations for the Japanese new era, Reiwa. > > Naoto From naoto.sato at oracle.com Tue May 7 20:43:54 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 7 May 2019 13:43:54 -0700 Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1 In-Reply-To: <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org> References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> <18F4381E-FBD2-4306-B5BB-F69CA847943D@icu-project.org> Message-ID: <43c14b37-26ba-34ee-6415-b7ca572ac0a4@oracle.com> Hi Steven, Thanks for your comments. My comments are embedded below. On 5/7/19 1:32 PM, Steven R. Loomis wrote: > Hi Naoto, > ? The comment in > http://cr.openjdk.java.net/~naoto/8221432/webrev.02/make/jdk/src/classes/build/tools/cldrconverter/Bundle.java.udiff.html > "fix up 'Reiwa' era, which can be missing in some locales? seems to > imply that fallback resolution isn?t working properly, because that data > (R) is present in root.xml. > Right. Currently it is a known restriction, as Java holds the Japanese era names as a string array in the resource bundle, and it won't fallback per array elements. Thus it is fixed using the names in root on resource bundle generation. > ?The deleted comment in the same file, "Some locale data has no default > script for numbering even with mutiple scripts? is not true for the same > reason. Contrary to the above, now this is working as you would expect as this is a single resource bundle element. If the default numbering system is missing, it is retrieved from the parent resource bundle (thus the comment is deleted). Naoto > > ?Otherwise the changes look as expected on a spot check. > > -- > Steven R. Loomis | @srl295 | git.io/srl295 > > > >> El may. 7, 2019, a las 1:12 p. m., naoto.sato at oracle.com >> escribi?: >> >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8221432 >> >> The proposed changeset is located at: >> >> http://cr.openjdk.java.net/~naoto/8221432/webrev.02/ >> >> The webrev is big, but the large amount of the changes is simply >> replacing the CLDR data files from v33 to v35.1, which includes the >> translations for the Japanese new era, Reiwa. >> >> Naoto > From Roger.Riggs at oracle.com Wed May 8 16:32:12 2019 From: Roger.Riggs at oracle.com (Roger Riggs) Date: Wed, 8 May 2019 12:32:12 -0400 Subject: [13] RFR: 8221432: Upgrade CLDR to Version 35.1 In-Reply-To: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> References: <8c6a4634-869b-28a3-d832-94497e460e98@oracle.com> Message-ID: Hi Naoto, The changes look fine. Thanks, Roger On 05/07/2019 04:12 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8221432 > > The proposed changeset is located at: > > http://cr.openjdk.java.net/~naoto/8221432/webrev.02/ > > The webrev is big, but the large amount of the changes is simply > replacing the CLDR data files from v33 to v35.1, which includes the > translations for the Japanese new era, Reiwa. > > Naoto From ying.z.zhou at oracle.com Thu May 9 05:01:26 2019 From: ying.z.zhou at oracle.com (Ying Zhou) Date: Thu, 9 May 2019 13:01:26 +0800 Subject: [13]RFR 8222969 : Migrate RuleBasedCollatorTest to JDK Repo Message-ID: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com> Hello, Please help to review this patch for migrating RuleBasedCollatorTest from Tong to Jtreg. Bug: https://bugs.openjdk.java.net/browse/JDK-8222969 webrev: http://cr.openjdk.java.net/~yzhou/8222969/webrev.03/ Thanks, Daisy From naoto.sato at oracle.com Thu May 9 15:33:00 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Thu, 9 May 2019 08:33:00 -0700 Subject: [13]RFR 8222969 : Migrate RuleBasedCollatorTest to JDK Repo In-Reply-To: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com> References: <327de3c2-0e22-1a44-262b-2f35be351822@oracle.com> Message-ID: <0d00bf8a-4a2b-8b6f-8dc9-d8cc478a2f33@oracle.com> Looks good. Please add "noreg-self" label to the issue. Naoto On 5/8/19 10:01 PM, Ying Zhou wrote: > Hello, > > Please help to review this patch for migrating RuleBasedCollatorTest > from Tong to Jtreg. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8222969 > > webrev: http://cr.openjdk.java.net/~yzhou/8222969/webrev.03/ > > Thanks, > > Daisy > > From deepak.kejriwal at oracle.com Fri May 10 11:25:37 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Fri, 10 May 2019 11:25:37 +0000 (UTC) Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru Message-ID: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8206879 The proposed fix is located at: http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ Summary In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). Regard, Deepak From naoto.sato at oracle.com Fri May 10 12:42:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 10 May 2019 05:42:08 -0700 Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> Message-ID: <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> Hi Deepak, here are my comments. - FormatData_es_PE.java: Modify the copyright year to 2019. - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. - Bug8206879.java does not have proper copyright header. Naoto On 5/10/19 4:25 AM, Deepak Kejriwal wrote: > Hello, > > > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8206879 > > > > The proposed fix is located at: > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ > > > > Summary > > In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). > > > > Regard, > > Deepak > > > From ramanand.patil at oracle.com Mon May 13 07:10:25 2019 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Mon, 13 May 2019 00:10:25 -0700 (PDT) Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> Message-ID: <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> Hi Deepak, Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. Regards, Ramanand. -----Original Message----- From: Naoto Sato Sent: Friday, May 10, 2019 6:12 PM To: Deepak Kejriwal ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru Hi Deepak, here are my comments. - FormatData_es_PE.java: Modify the copyright year to 2019. - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. - Bug8206879.java does not have proper copyright header. Naoto On 5/10/19 4:25 AM, Deepak Kejriwal wrote: > Hello, > > > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8206879 > > > > The proposed fix is located at: > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ > > > > Summary > > In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). > > > > Regard, > > Deepak > > > From deepak.kejriwal at oracle.com Tue May 14 11:19:37 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Tue, 14 May 2019 04:19:37 -0700 (PDT) Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> Message-ID: <4c9d3c0b-2970-4cf8-a218-edef84751720@default> Thanks Ramanand and Naoto for review. Please find updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/ Regards, Deepak -----Original Message----- From: Ramanand Patil Sent: Monday, May 13, 2019 12:40 PM To: Naoto Sato ; Deepak Kejriwal ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: RE: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru Hi Deepak, Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. Regards, Ramanand. -----Original Message----- From: Naoto Sato Sent: Friday, May 10, 2019 6:12 PM To: Deepak Kejriwal ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru Hi Deepak, here are my comments. - FormatData_es_PE.java: Modify the copyright year to 2019. - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. - Bug8206879.java does not have proper copyright header. Naoto On 5/10/19 4:25 AM, Deepak Kejriwal wrote: > Hello, > > > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8206879 > > > > The proposed fix is located at: > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ > > > > Summary > > In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). > > > > Regard, > > Deepak > > > From naoto.sato at oracle.com Tue May 14 16:47:07 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 14 May 2019 09:47:07 -0700 Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: <4c9d3c0b-2970-4cf8-a218-edef84751720@default> References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> <4c9d3c0b-2970-4cf8-a218-edef84751720@default> Message-ID: There is a typo in the test file name (and other related locations, such as class name, constructor name, etc): "Fomat" -> "Format" Otherwise looks good. Naoto On 5/14/19 4:19 AM, Deepak Kejriwal wrote: > Thanks Ramanand and Naoto for review. Please find updated version of webrev:- > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Ramanand Patil > Sent: Monday, May 13, 2019 12:40 PM > To: Naoto Sato ; Deepak Kejriwal ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: RE: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru > > Hi Deepak, > Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. > > Regards, > Ramanand. > > -----Original Message----- > From: Naoto Sato > Sent: Friday, May 10, 2019 6:12 PM > To: Deepak Kejriwal ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru > > Hi Deepak, here are my comments. > > - FormatData_es_PE.java: Modify the copyright year to 2019. > > - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. > > - Bug8206879.java does not have proper copyright header. > > Naoto > > On 5/10/19 4:25 AM, Deepak Kejriwal wrote: >> Hello, >> >> >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8206879 >> >> >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ >> >> >> >> Summary >> >> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). >> >> >> >> Regard, >> >> Deepak >> >> >> From deepak.kejriwal at oracle.com Wed May 15 13:13:39 2019 From: deepak.kejriwal at oracle.com (Deepak Kejriwal) Date: Wed, 15 May 2019 06:13:39 -0700 (PDT) Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> <4c9d3c0b-2970-4cf8-a218-edef84751720@default> Message-ID: <714af9f3-8011-4b69-864a-3c6c717953c6@default> Thanks Naoto for review, please find below updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/ Regards, Deepak -----Original Message----- From: Naoto Sato Sent: Tuesday, May 14, 2019 10:17 PM To: Deepak Kejriwal ; Ramanand Patil ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru There is a typo in the test file name (and other related locations, such as class name, constructor name, etc): "Fomat" -> "Format" Otherwise looks good. Naoto On 5/14/19 4:19 AM, Deepak Kejriwal wrote: > Thanks Ramanand and Naoto for review. Please find updated version of > webrev:- > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/ > > Regards, > Deepak > > -----Original Message----- > From: Ramanand Patil > Sent: Monday, May 13, 2019 12:40 PM > To: Naoto Sato ; Deepak Kejriwal > ; i18n-dev at openjdk.java.net; > core-libs-dev at openjdk.java.net > Subject: RE: [13] RFR: JDK-8206879: Currency decimal marker > incorrect for Peru > > Hi Deepak, > Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. > > Regards, > Ramanand. > > -----Original Message----- > From: Naoto Sato > Sent: Friday, May 10, 2019 6:12 PM > To: Deepak Kejriwal ; > i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker > incorrect for Peru > > Hi Deepak, here are my comments. > > - FormatData_es_PE.java: Modify the copyright year to 2019. > > - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. > > - Bug8206879.java does not have proper copyright header. > > Naoto > > On 5/10/19 4:25 AM, Deepak Kejriwal wrote: >> Hello, >> >> >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8206879 >> >> >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ >> >> >> >> Summary >> >> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). >> >> >> >> Regard, >> >> Deepak >> >> >> From naoto.sato at oracle.com Wed May 15 16:19:57 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 15 May 2019 09:19:57 -0700 Subject: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru In-Reply-To: <714af9f3-8011-4b69-864a-3c6c717953c6@default> References: <8de575b1-7c47-47fd-925f-1caa93c3a38e@default> <23bfe1bb-315f-df96-9f13-71925f5ee084@oracle.com> <4d89bcfd-f772-4c0b-bacd-8ecd7899ddf4@default> <4c9d3c0b-2970-4cf8-a218-edef84751720@default> <714af9f3-8011-4b69-864a-3c6c717953c6@default> Message-ID: Thanks, Deepak. Looks good. Naoto On 5/15/19 6:13 AM, Deepak Kejriwal wrote: > Thanks Naoto for review, please find below updated version of webrev:- > > http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.02/ > > Regards, > Deepak > > -----Original Message----- > From: Naoto Sato > Sent: Tuesday, May 14, 2019 10:17 PM > To: Deepak Kejriwal ; Ramanand Patil ; i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker incorrect for Peru > > There is a typo in the test file name (and other related locations, such as class name, constructor name, etc): > > "Fomat" -> "Format" > > Otherwise looks good. > > Naoto > > On 5/14/19 4:19 AM, Deepak Kejriwal wrote: >> Thanks Ramanand and Naoto for review. Please find updated version of >> webrev:- >> >> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.01/ >> >> Regards, >> Deepak >> >> -----Original Message----- >> From: Ramanand Patil >> Sent: Monday, May 13, 2019 12:40 PM >> To: Naoto Sato ; Deepak Kejriwal >> ; i18n-dev at openjdk.java.net; >> core-libs-dev at openjdk.java.net >> Subject: RE: [13] RFR: JDK-8206879: Currency decimal marker >> incorrect for Peru >> >> Hi Deepak, >> Minor, but it will be good if you change the test case name to something like TestPeruDecimalFormat.java or TestPeruCurrencyDecimalFormat instead of just using BugID. >> >> Regards, >> Ramanand. >> >> -----Original Message----- >> From: Naoto Sato >> Sent: Friday, May 10, 2019 6:12 PM >> To: Deepak Kejriwal ; >> i18n-dev at openjdk.java.net; core-libs-dev at openjdk.java.net >> Subject: Re: [13] RFR: JDK-8206879: Currency decimal marker >> incorrect for Peru >> >> Hi Deepak, here are my comments. >> >> - FormatData_es_PE.java: Modify the copyright year to 2019. >> >> - Changes in "LocaleData" may be placed at the bottom of the file, explicitly indicating it is changed with 8206879. Please follow the similar changes' format. >> >> - Bug8206879.java does not have proper copyright header. >> >> Naoto >> >> On 5/10/19 4:25 AM, Deepak Kejriwal wrote: >>> Hello, >>> >>> >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8206879 >>> >>> >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~dkejriwal/8206879/webrev.00/ >>> >>> >>> >>> Summary >>> >>> In case of JRE locale provider, for Peru comma (,) is used as decimal marker which is incorrect. The fix is to correct decimal marker for Peru from comma (,) to dot (.). >>> >>> >>> >>> Regard, >>> >>> Deepak >>> >>> >>> From li.jiang at oracle.com Fri May 17 04:04:29 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Fri, 17 May 2019 12:04:29 +0800 Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider Message-ID: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> Hi all, Please review the change to update the l10n names for Japanese era Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please refer this unicode chart[1] for l10n definitions. Bug: https://bugs.openjdk.java.net/browse/JDK-8218781 Webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ In this change, - update the l10n names if they are defined in CLDR 35.1. - update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW style respectively. - In FormatData_th.java, the localized single character was used for previous eras. But we don't find the corresponding name in CLDR 35.1. Update it to 'R' according to CLDR 35.1. [1] https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html Thanks, Leo From naoto.sato at oracle.com Fri May 17 16:39:35 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 17 May 2019 09:39:35 -0700 Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> Message-ID: <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com> Hi Leo, Overall looks good. One comment to the test case is that I would avoid using the name "JavaTimeSupplementary" or "JTS", as they are the implementation detail. Actually, a DateTimeFormatException may not necessarily be caused by a missing JavaTimeSupplementary resource in the runtime. Naoto On 5/16/19 9:04 PM, li.jiang at oracle.com wrote: > Hi all, > > Please review the change to update the l10n names for Japanese era Reiwa > in JDK COMPAT provider. The l10n names come from the CLDR 35.1, please > refer this unicode chart[1] for l10n definitions. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8218781 > Webrev: > http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ > > In this change, > ?- update the l10n names if they are defined in CLDR 35.1. > ?- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW > style respectively. > ?- In FormatData_th.java, the localized single character was used for > previous eras. But we don't find the corresponding name in CLDR 35.1. > Update it to 'R' according to CLDR 35.1. > > [1] > https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html > > > > Thanks, > Leo From naoto.sato at oracle.com Fri May 17 22:43:09 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 17 May 2019 15:43:09 -0700 Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales Message-ID: Hi, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8224105 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ CLDR does not provide entire localized Japanese era names in locales mentioned in the bug report. The parsing has been failing as they have duplicate names, despite the duplicates are empty strings. Naoto From li.jiang at oracle.com Sat May 18 13:23:23 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Sat, 18 May 2019 21:23:23 +0800 Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com> References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com> Message-ID: Hi Naoto, Please review the updated webrev: http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/ In this update, renamed the data provider names and test case name to improve the readability. Thanks, Leo On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote: > Hi Leo, > > Overall looks good. One comment to the test case is that I would avoid > using the name "JavaTimeSupplementary" or "JTS", as they are the > implementation detail. Actually, a DateTimeFormatException may not > necessarily be caused by a missing JavaTimeSupplementary resource in the > runtime. > > Naoto > > On 5/16/19 9:04 PM, li.jiang at oracle.com wrote: >> Hi all, >> >> Please review the change to update the l10n names for Japanese era >> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, >> please refer this unicode chart[1] for l10n definitions. >> >> Bug: >> https://bugs.openjdk.java.net/browse/JDK-8218781 >> Webrev: >> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ >> >> In this change, >> ??- update the l10n names if they are defined in CLDR 35.1. >> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW >> style respectively. >> ??- In FormatData_th.java, the localized single character was used for >> previous eras. But we don't find the corresponding name in CLDR 35.1. >> Update it to 'R' according to CLDR 35.1. >> >> [1] >> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html >> >> >> >> Thanks, >> Leo From naoto.sato at oracle.com Sun May 19 13:55:25 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Sun, 19 May 2019 06:55:25 -0700 Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com> Message-ID: Looks good. Naoto On 5/18/19 6:23 AM, li.jiang at oracle.com wrote: > Hi Naoto, > > Please review the updated webrev: > http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/ > > In this update, renamed the data provider names and test case name to > improve the readability. > > Thanks, > Leo > > On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote: >> Hi Leo, >> >> Overall looks good. One comment to the test case is that I would avoid >> using the name "JavaTimeSupplementary" or "JTS", as they are the >> implementation detail. Actually, a DateTimeFormatException may not >> necessarily be caused by a missing JavaTimeSupplementary resource in >> the runtime. >> >> Naoto >> >> On 5/16/19 9:04 PM, li.jiang at oracle.com wrote: >>> Hi all, >>> >>> Please review the change to update the l10n names for Japanese era >>> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR 35.1, >>> please refer this unicode chart[1] for l10n definitions. >>> >>> Bug: >>> https://bugs.openjdk.java.net/browse/JDK-8218781 >>> Webrev: >>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ >>> >>> In this change, >>> ??- update the l10n names if they are defined in CLDR 35.1. >>> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW >>> style respectively. >>> ??- In FormatData_th.java, the localized single character was used >>> for previous eras. But we don't find the corresponding name in CLDR >>> 35.1. Update it to 'R' according to CLDR 35.1. >>> >>> [1] >>> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html >>> >>> >>> >>> Thanks, >>> Leo From li.jiang at oracle.com Sun May 19 14:16:19 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Sun, 19 May 2019 22:16:19 +0800 Subject: RFR: 8218781 : Localized names for Japanese Era Reiwa in COMPAT provider In-Reply-To: References: <389a71f0-cf2a-c26f-7ff3-fbb1eaf4ae79@oracle.com> <17c58d5d-c26c-09e1-2ae5-b5109646ecc0@oracle.com> Message-ID: <63483dac-f105-3feb-0855-8ea9bb7dddec@oracle.com> Thank you, pushed. /Leo On 5/19/19 9:55 PM, naoto.sato at oracle.com wrote: > Looks good. > > Naoto > > On 5/18/19 6:23 AM, li.jiang at oracle.com wrote: >> Hi Naoto, >> >> Please review the updated webrev: >> http://cr.openjdk.java.net/~ljiang/8218781/webrev.01/ >> >> In this update, renamed the data provider names and test case name to >> improve the readability. >> >> Thanks, >> Leo >> >> On 5/18/19 12:39 AM, naoto.sato at oracle.com wrote: >>> Hi Leo, >>> >>> Overall looks good. One comment to the test case is that I would >>> avoid using the name "JavaTimeSupplementary" or "JTS", as they are >>> the implementation detail. Actually, a DateTimeFormatException may >>> not necessarily be caused by a missing JavaTimeSupplementary resource >>> in the runtime. >>> >>> Naoto >>> >>> On 5/16/19 9:04 PM, li.jiang at oracle.com wrote: >>>> Hi all, >>>> >>>> Please review the change to update the l10n names for Japanese era >>>> Reiwa in JDK COMPAT provider. The l10n names come from the CLDR >>>> 35.1, please refer this unicode chart[1] for l10n definitions. >>>> >>>> Bug: >>>> https://bugs.openjdk.java.net/browse/JDK-8218781 >>>> Webrev: >>>> http://cr.openjdk.java.net/~ljiang/8218781/webrev.00/ >>>> >>>> In this change, >>>> ??- update the l10n names if they are defined in CLDR 35.1. >>>> ??- update the l10n names to Reiwa, Reiwa, R for FULL, SHORT, NARROW >>>> style respectively. >>>> ??- In FormatData_th.java, the localized single character was used >>>> for previous eras. But we don't find the corresponding name in CLDR >>>> 35.1. Update it to 'R' according to CLDR 35.1. >>>> >>>> [1] >>>> https://www.unicode.org/cldr/charts/latest/by_type/date_&_time.japanese.html >>>> >>>> >>>> >>>> Thanks, >>>> Leo From naoto.sato at oracle.com Tue May 21 00:20:19 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 20 May 2019 17:20:19 -0700 Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales In-Reply-To: References: Message-ID: Ping? Naoto On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8224105 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ > > CLDR does not provide entire localized Japanese era names in locales > mentioned in the bug report. The parsing has been failing as they have > duplicate names, despite the duplicates are empty strings. > > Naoto From chengjingwei1 at huawei.com Tue May 21 03:47:56 2019 From: chengjingwei1 at huawei.com (chengjingwei (A)) Date: Tue, 21 May 2019 03:47:56 +0000 Subject: jtreg test failed with Japanese datetime formatting on win32 Message-ID: The failure occurred on windows-32bit platform only. The test case was jdk8u/jdk/test/java/time/test/java/time/format/TestNonIsoFormatter.java Failure message: test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Meiji 123", "Heisei 2"): failure java.time.format.DateTimeParseException: Text 'Meiji 123-01-01' could not be parsed at index 0 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.LocalDate.parse(LocalDate.java:400) at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Showa 65", "Heisei 2"): failure java.time.format.DateTimeParseException: Text 'Showa 65-01-01' could not be parsed at index 0 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.LocalDate.parse(LocalDate.java:400) at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Heisei 32", "Reiwa 2"): failure java.time.format.DateTimeParseException: Text 'Heisei 32-01-01' could not be parsed at index 0 at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) at java.time.LocalDate.parse(LocalDate.java:400) at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) at org.testng.TestRunner.privateRun(TestRunner.java:773) at org.testng.TestRunner.run(TestRunner.java:623) at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) at org.testng.SuiteRunner.run(SuiteRunner.java:259) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) at org.testng.TestNG.run(TestNG.java:1018) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseInvalidText("??65?1?1????): success config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Japanese, ja, ja, Japanese Heisei 25-02-11, "??25?2?11?"): success config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Hijrah-umalqura, ar, ar, Hijrah-umalqura AH 1434-04-01, "???????? 1 ???? ????? 1434"): success config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Minguo, zh_TW, zh_TW, Minguo ROC 102-02-11, "??102?2?11????"): success config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(ThaiBuddhist, th_TH, th_TH, ThaiBuddhist BE 2556-02-11, "???????????? 11 ?????????? ?.?. 2556"): success config test.java.time.format.TestNonIsoFormatter.setUp(): success test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(ThaiBuddhist, th_TH, th_TH_#u-nu-thai, ThaiBuddhist BE 2556-02-11, "???????????? ?? ?????????? ?.?. ????"): success =============================================== java/time/test/java/time/format/TestNonIsoFormatter.java Total tests run: 26, Failures: 3, Skips: 0 =============================================== STDERR: java.lang.Exception: failures: 3 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) at java.lang.Thread.run(Thread.java:748) From li.jiang at oracle.com Tue May 21 09:36:17 2019 From: li.jiang at oracle.com (li.jiang at oracle.com) Date: Tue, 21 May 2019 17:36:17 +0800 Subject: jtreg test failed with Japanese datetime formatting on win32 In-Reply-To: References: Message-ID: <5e224dec-1b0a-d5c0-1bca-0efb2d2ff13a@oracle.com> This issue should have been fixed by bug JDK-8224142[1]. The fix had been integrated into openjdk8u222. Would you provide the OS version and Java version in your test environment? Kinder reminder, before report the issue and paste the log here, you can search the JBS[2] first. [1] https://bugs.openjdk.java.net/browse/JDK-8224142 [2] https://bugs.openjdk.java.net/ Thanks, Leo On 21/05/2019 11:47 AM, chengjingwei (A) wrote: > The failure occurred on windows-32bit platform only. The test case was > jdk8u/jdk/test/java/time/test/java/time/format/TestNonIsoFormatter.java > > Failure message: > test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Meiji 123", "Heisei 2"): failure > java.time.format.DateTimeParseException: Text 'Meiji 123-01-01' could not be parsed at index 0 > at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) > at java.time.LocalDate.parse(LocalDate.java:400) > at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.lang.Thread.run(Thread.java:748) > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Showa 65", "Heisei 2"): failure > java.time.format.DateTimeParseException: Text 'Showa 65-01-01' could not be parsed at index 0 > at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) > at java.time.LocalDate.parse(LocalDate.java:400) > at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.lang.Thread.run(Thread.java:748) > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(Japanese, "Heisei 32", "Reiwa 2"): failure > java.time.format.DateTimeParseException: Text 'Heisei 32-01-01' could not be parsed at index 0 > at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1949) > at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1851) > at java.time.LocalDate.parse(LocalDate.java:400) > at test.java.time.format.TestNonIsoFormatter.test_lenientEraYear(TestNonIsoFormatter.java:196) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at org.testng.internal.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:85) > at org.testng.internal.Invoker.invokeMethod(Invoker.java:639) > at org.testng.internal.Invoker.invokeTestMethod(Invoker.java:821) > at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1131) > at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:124) > at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:108) > at org.testng.TestRunner.privateRun(TestRunner.java:773) > at org.testng.TestRunner.run(TestRunner.java:623) > at org.testng.SuiteRunner.runTest(SuiteRunner.java:357) > at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:352) > at org.testng.SuiteRunner.privateRun(SuiteRunner.java:310) > at org.testng.SuiteRunner.run(SuiteRunner.java:259) > at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) > at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) > at org.testng.TestNG.runSuitesSequentially(TestNG.java:1185) > at org.testng.TestNG.runSuitesLocally(TestNG.java:1110) > at org.testng.TestNG.run(TestNG.java:1018) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:94) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.lang.Thread.run(Thread.java:748) > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseInvalidText("??65?1?1????): success > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Japanese, ja, ja, Japanese Heisei 25-02-11, "??25?2?11?"): success > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Hijrah-umalqura, ar, ar, Hijrah-umalqura AH 1434-04-01, "???????? 1 ???? ????? 1434"): success > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(Minguo, zh_TW, zh_TW, Minguo ROC 102-02-11, "??102?2?11????"): success > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(ThaiBuddhist, th_TH, th_TH, ThaiBuddhist BE 2556-02-11, "???????????? 11 ?????????? ?.?. 2556"): success > config test.java.time.format.TestNonIsoFormatter.setUp(): success > test test.java.time.format.TestNonIsoFormatter.test_parseLocalizedText(ThaiBuddhist, th_TH, th_TH_#u-nu-thai, ThaiBuddhist BE 2556-02-11, "???????????? ?? ?????????? ?.?. ????"): success > > =============================================== > java/time/test/java/time/format/TestNonIsoFormatter.java > Total tests run: 26, Failures: 3, Skips: 0 > =============================================== > > STDERR: > java.lang.Exception: failures: 3 > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:96) > at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:127) > at java.lang.Thread.run(Thread.java:748) > From brent.christian at oracle.com Tue May 21 18:03:04 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 21 May 2019 11:03:04 -0700 Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales In-Reply-To: References: Message-ID: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com> Hi, Naoto. I have a couple comments. src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java String.isEmpty() could be used in place of equals(""). test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java Maybe give the new constants names in all-caps. -Brent On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote: > Ping? > > Naoto > > On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8224105 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ >> >> CLDR does not provide entire localized Japanese era names in locales >> mentioned in the bug report. The parsing has been failing as they have >> duplicate names, despite the duplicates are empty strings. >> >> Naoto From naoto.sato at oracle.com Tue May 21 18:33:20 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 21 May 2019 11:33:20 -0700 Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales In-Reply-To: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com> References: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com> Message-ID: <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com> Thanks, Brent. Modified the webrev accordingly: http://cr.openjdk.java.net/~naoto/8224105/webrev.01/ Naoto On 5/21/19 11:03 AM, Brent Christian wrote: > Hi, Naoto.? I have a couple comments. > > src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java > > > > String.isEmpty() could be used in place of equals(""). > > > test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java > > > Maybe give the new constants names in all-caps. > > > -Brent > > On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote: >> Ping? >> >> Naoto >> >> On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8224105 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ >>> >>> CLDR does not provide entire localized Japanese era names in locales >>> mentioned in the bug report. The parsing has been failing as they >>> have duplicate names, despite the duplicates are empty strings. >>> >>> Naoto From brent.christian at oracle.com Tue May 21 20:36:41 2019 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 21 May 2019 13:36:41 -0700 Subject: [13] RFR: 8224105: Cannot parse JapaneseDate string on some specified locales In-Reply-To: <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com> References: <01e6d7f9-e7df-4458-518f-20d455b31263@oracle.com> <36c05c5c-e08a-bd65-1b1e-daa8400d106c@oracle.com> Message-ID: Thanks. Looks good to me. -Brent On 5/21/19 11:33 AM, naoto.sato at oracle.com wrote: > Thanks, Brent. Modified the webrev accordingly: > > http://cr.openjdk.java.net/~naoto/8224105/webrev.01/ > > Naoto > > On 5/21/19 11:03 AM, Brent Christian wrote: >> Hi, Naoto.? I have a couple comments. >> >> src/java.base/share/classes/sun/util/locale/provider/CalendarNameProviderImpl.java >> >> >> >> String.isEmpty() could be used in place of equals(""). >> >> >> test/jdk/java/time/test/java/time/chrono/TestEraDisplayName.java >> >> >> Maybe give the new constants names in all-caps. >> >> >> -Brent >> >> On 5/20/19 5:20 PM, naoto.sato at oracle.com wrote: >>> Ping? >>> >>> Naoto >>> >>> On 5/17/19 3:43 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the fix to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8224105 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8224105/webrev.00/ >>>> >>>> CLDR does not provide entire localized Japanese era names in locales >>>> mentioned in the bug report. The parsing has been failing as they >>>> have duplicate names, despite the duplicates are empty strings. >>>> >>>> Naoto From naoto.sato at oracle.com Wed May 22 22:26:08 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2019 15:26:08 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 Message-ID: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> Hi, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221431 The proposed CSR and changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8222771 https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ This enhancement incorporates support for the recently released Unicode version 12.1. Besides the usual addition of new characters/scripts, this enhancement includes normalization of the Japanese Reiwa era character (U+32FF), and up-to-date extended grapheme cluster support in regex package. Naoto From naoto.sato at oracle.com Wed May 22 22:56:19 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2019 15:56:19 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> Message-ID: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> Adding build-dev, as the change adds a small build tool to parse emoji-data. Naoto On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: > Hi, > > Please review the changes to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8221431 > > The proposed CSR and changeset are located at: > > https://bugs.openjdk.java.net/browse/JDK-8222771 > https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ > > This enhancement incorporates support for the recently released Unicode > version 12.1. Besides the usual addition of new characters/scripts, this > enhancement includes normalization of the Japanese Reiwa era character > (U+32FF), and up-to-date extended grapheme cluster support in regex > package. > > Naoto From erik.joelsson at oracle.com Wed May 22 23:13:32 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 May 2019 16:13:32 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> Message-ID: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Hello Naoto, In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double $$. I would recommend calling the newer MakeTargetDir macro instead. It doesn't take an argument. Otherwise build changes look good. /Erik On 2019-05-22 15:56, naoto.sato at oracle.com wrote: > Adding build-dev, as the change adds a small build tool to parse > emoji-data. > > Naoto > > On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >> Hi, >> >> Please review the changes to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8221431 >> >> The proposed CSR and changeset are located at: >> >> https://bugs.openjdk.java.net/browse/JDK-8222771 >> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >> >> This enhancement incorporates support for the recently released >> Unicode version 12.1. Besides the usual addition of new >> characters/scripts, this enhancement includes normalization of the >> Japanese Reiwa era character (U+32FF), and up-to-date extended >> grapheme cluster support in regex package. >> >> Naoto From naoto.sato at oracle.com Thu May 23 01:36:40 2019 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Wed, 22 May 2019 18:36:40 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Message-ID: Hi Erik, Thank you for your comments. Updated the webrev accordingly: https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ Naoto On 5/22/19 4:13 PM, Erik Joelsson wrote: > Hello Naoto, > > In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double > $$. I would recommend calling the newer MakeTargetDir macro instead. It > doesn't take an argument. > > Otherwise build changes look good. > > /Erik > > On 2019-05-22 15:56, naoto.sato at oracle.com wrote: >> Adding build-dev, as the change adds a small build tool to parse >> emoji-data. >> >> Naoto >> >> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >>> Hi, >>> >>> Please review the changes to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8221431 >>> >>> The proposed CSR and changeset are located at: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8222771 >>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >>> >>> This enhancement incorporates support for the recently released >>> Unicode version 12.1. Besides the usual addition of new >>> characters/scripts, this enhancement includes normalization of the >>> Japanese Reiwa era character (U+32FF), and up-to-date extended >>> grapheme cluster support in regex package. >>> >>> Naoto From erik.joelsson at oracle.com Thu May 23 13:46:44 2019 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 May 2019 06:46:44 -0700 Subject: [13] RFR: 8221431: Support for Unicode 12.1 In-Reply-To: References: <33302faf-bbbd-eef2-0eee-66c73eb8183f@oracle.com> <39619b64-f39a-7186-137d-bab8ccff16d6@oracle.com> <5d8224bb-7d77-c433-5182-74fcdb351cf5@oracle.com> Message-ID: <36408f60-1669-1726-27be-b660267827c8@oracle.com> Build changes look good. /Erik On 2019-05-22 18:36, naoto.sato at oracle.com wrote: > Hi Erik, > > Thank you for your comments. Updated the webrev accordingly: > > https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ > > Naoto > > On 5/22/19 4:13 PM, Erik Joelsson wrote: >> Hello Naoto, >> >> In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the >> double $$. I would recommend calling the newer MakeTargetDir macro >> instead. It doesn't take an argument. >> >> Otherwise build changes look good. >> >> /Erik >> >> On 2019-05-22 15:56, naoto.sato at oracle.com wrote: >>> Adding build-dev, as the change adds a small build tool to parse >>> emoji-data. >>> >>> Naoto >>> >>> On 5/22/19 3:26 PM, naoto.sato at oracle.com wrote: >>>> Hi, >>>> >>>> Please review the changes to the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8221431 >>>> >>>> The proposed CSR and changeset are located at: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8222771 >>>> https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ >>>> >>>> This enhancement incorporates support for the recently released >>>> Unicode version 12.1. Besides the usual addition of new >>>> characters/scripts, this enhancement includes normalization of the >>>> Japanese Reiwa era character (U+32FF), and up-to-date extended >>>> grapheme cluster support in regex package. >>>> >>>> Naoto