From martinrb at google.com Thu Jun 1 18:20:46 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 1 Jun 2017 11:20:46 -0700 Subject: [10] RFR: 8176160, 8176847, 8176853 In-Reply-To: <8f961c43-6def-2bbb-9d73-da287a59e01a@oracle.com> References: <63d6a52e-2666-6fd4-9188-207224c5ed79@oracle.com> <8f961c43-6def-2bbb-9d73-da287a59e01a@oracle.com> Message-ID: Looks even better! On Wed, May 31, 2017 at 2:20 PM, Naoto Sato wrote: > Thanks, Martin. Updated the webrev for each: > > http://cr.openjdk.java.net/~naoto/8176160/webrev.01/ > http://cr.openjdk.java.net/~naoto/8176847/webrev.01/ > > Naoto > > On 5/31/17 1:00 PM, Martin Buchholz wrote: > >> Thanks - looks good. >> >> --- >> >> + private final static List cals = >> + List.of("gregorian", "japanese", "julian"); >> >> If you inline this into main, your beautiful stream pipeline will be even >> more beautiful! >> >> --- >> >> +import static java.util.Calendar.Builder; >> >> My colleagues would frown upon static importing a builder - just use >> "Calendar.Builder" ! >> >> >> >> On Wed, May 31, 2017 at 12:41 PM, Naoto Sato > > wrote: >> >> Hi Martin, >> >> These are the issues you filed with proposed fixes. I supplemented >> the tests to them. Can you please review these changes: >> >> https://bugs.openjdk.java.net/browse/JDK-8176160 >> >> http://cr.openjdk.java.net/~naoto/8176160/webrev.00/ >> >> >> https://bugs.openjdk.java.net/browse/JDK-8176847 >> >> http://cr.openjdk.java.net/~naoto/8176847/webrev.00/ >> >> >> https://bugs.openjdk.java.net/browse/JDK-8176853 >> >> http://cr.openjdk.java.net/~naoto/8176853/webrev.00/ >> >> >> Naoto >> >> >> From rachna.goel at oracle.com Tue Jun 6 06:10:34 2017 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 6 Jun 2017 11:40:34 +0530 Subject: JDK10 Review Request for JDK-8178872: Decimal form is inconsistent between CLDR and Java in some special locales Message-ID: Hi, Kindly review fix for JDK-8178872. https://bugs.openjdk.java.net/browse/JDK-8178872 patch : http://cr.openjdk.java.net/~rgoel/JDK-8178872/webrev.06/ fix : Inside CLDRconverter , LDML Parser should check name of container before retrieving decimal separator and grouping separator symbols for NumberElements, as those symbols can be present for Currency also in some locales. -- Thanks, Rachna From naoto.sato at oracle.com Tue Jun 6 16:15:40 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 6 Jun 2017 09:15:40 -0700 Subject: JDK10 Review Request for JDK-8178872: Decimal form is inconsistent between CLDR and Java in some special locales In-Reply-To: References: Message-ID: <49438ecd-186b-76f8-dd29-05dcdb5eb982@oracle.com> Looks good to me. Naoto On 6/5/17 11:10 PM, Rachna Goel wrote: > Hi, > > Kindly review fix for JDK-8178872. > > https://bugs.openjdk.java.net/browse/JDK-8178872 > > patch : http://cr.openjdk.java.net/~rgoel/JDK-8178872/webrev.06/ > > fix : Inside CLDRconverter , LDML Parser should check name of container > before retrieving decimal separator and grouping separator symbols for > NumberElements, as those symbols can be present for Currency also in > some locales. > From nishit.jain at oracle.com Fri Jun 9 06:59:57 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 9 Jun 2017 12:29:57 +0530 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib Message-ID: Hi, Please review the fix for JDK-8176583 Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ Fix: Relocated currency.data from java.base module (/java.base/java/util/currency.data) to /lib directory Regards, Nishit Jain From naoto.sato at oracle.com Fri Jun 9 17:50:54 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Jun 2017 10:50:54 -0700 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib In-Reply-To: References: Message-ID: <7774f33d-d5d0-90c4-9a64-1d42c9cda74a@oracle.com> Hi Nishit, In Currency.java, there seems to be a redundant try block (line 206). Is it possible to merge it with the try block at line 205? Otherwise it looks good to me. Naoto On 6/8/17 11:59 PM, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8176583 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 > Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ > > Fix: Relocated currency.data from java.base module > (/java.base/java/util/currency.data) to /lib directory > > Regards, > Nishit Jain From nishit.jain at oracle.com Mon Jun 12 09:01:08 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Mon, 12 Jun 2017 14:31:08 +0530 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib In-Reply-To: <7774f33d-d5d0-90c4-9a64-1d42c9cda74a@oracle.com> References: <7774f33d-d5d0-90c4-9a64-1d42c9cda74a@oracle.com> Message-ID: Thanks Naoto, Please check the updated webrev http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/ Changes: - merged the try blocks in Currency.java - replaced the try block in CheckDataVersion.java with try-with-resource and a small indentation change at line 82. Regards, Nishit Jain On 09-06-2017 23:20, Naoto Sato wrote: > Hi Nishit, > > In Currency.java, there seems to be a redundant try block (line 206). > Is it possible to merge it with the try block at line 205? > > Otherwise it looks good to me. > > Naoto > > On 6/8/17 11:59 PM, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8176583 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 >> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ >> >> Fix: Relocated currency.data from java.base module >> (/java.base/java/util/currency.data) to /lib directory >> >> Regards, >> Nishit Jain From naoto.sato at oracle.com Mon Jun 12 16:51:05 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 12 Jun 2017 09:51:05 -0700 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib In-Reply-To: References: <7774f33d-d5d0-90c4-9a64-1d42c9cda74a@oracle.com> Message-ID: <35a5a08c-35b6-4e68-10fe-d777c507caa1@oracle.com> Looks good. Naoto On 6/12/17 2:01 AM, Nishit Jain wrote: > Thanks Naoto, > > Please check the updated webrev > http://cr.openjdk.java.net/~nishjain/8176583/webrev.02/ > > Changes: > - merged the try blocks in Currency.java > - replaced the try block in CheckDataVersion.java with try-with-resource > and a small indentation change at line 82. > > Regards, > Nishit Jain > On 09-06-2017 23:20, Naoto Sato wrote: >> Hi Nishit, >> >> In Currency.java, there seems to be a redundant try block (line 206). >> Is it possible to merge it with the try block at line 205? >> >> Otherwise it looks good to me. >> >> Naoto >> >> On 6/8/17 11:59 PM, Nishit Jain wrote: >>> Hi, >>> >>> Please review the fix for JDK-8176583 >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 >>> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ >>> >>> Fix: Relocated currency.data from java.base module >>> (/java.base/java/util/currency.data) to /lib directory >>> >>> Regards, >>> Nishit Jain > From Alan.Bateman at oracle.com Wed Jun 14 07:23:31 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jun 2017 08:23:31 +0100 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib In-Reply-To: References: Message-ID: <6ad0bfd3-c1d6-e647-6f17-8632f0dcd215@oracle.com> On 09/06/2017 07:59, Nishit Jain wrote: > Hi, > > Please review the fix for JDK-8176583 > > Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 > Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ > > Fix: Relocated currency.data from java.base module > (/java.base/java/util/currency.data) to /lib directory Can you explain why this is needed? What is planning to upgrade the currency data in generated run-time images? -Alan From nishit.jain at oracle.com Wed Jun 14 08:31:57 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Wed, 14 Jun 2017 14:01:57 +0530 Subject: JDK 10 Review Request for JDK-8176583: Move currency data to /lib In-Reply-To: <6ad0bfd3-c1d6-e647-6f17-8632f0dcd215@oracle.com> References: <6ad0bfd3-c1d6-e647-6f17-8632f0dcd215@oracle.com> Message-ID: Hi Alan, The change is not for upgrading the currency data in generated run-time images, rather we see no reason of keeping it inside java.base. The currency data updation process is separate task and each time an ISO-4217 amendment version is released, the updation process should not modify the java.base module. This is my understanding about the change. Regards, Nishit Jain On 14-06-2017 12:53, Alan Bateman wrote: > > > On 09/06/2017 07:59, Nishit Jain wrote: >> Hi, >> >> Please review the fix for JDK-8176583 >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8176583 >> Webrev: http://cr.openjdk.java.net/~nishjain/8176583/webrev.01/ >> >> Fix: Relocated currency.data from java.base module >> (/java.base/java/util/currency.data) to /lib directory > Can you explain why this is needed? What is planning to upgrade the > currency data in generated run-time images? > > -Alan From m-matsushima at bk.jp.nec.com Wed Jun 21 12:40:04 2017 From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima) Date: Wed, 21 Jun 2017 12:40:04 +0000 Subject: Additional infomation for JDK-8048123 Message-ID: Hi. I reported JDK-8048123 before. But I notice this issue is more complex. It's unable to attach files at the web form, so I post to ml. At first, I thought it's a issue of the fix for JDK-8173423. However, I think it's a issue of CalendarNameProviders now. I tested attatched AupplementalEraTest2.java with 3 providers (COMPAT, CLDR and HOST). And I compared the result as dateFormatComparison.png. I think SHORT and NARROW should be same form. Thus, I think the values of follows are wrong. -At SimpleDateFormat: SHORT form of CLDR -At DateTimeFormatter: NARROW form of COMPAT and CLDR Narrow form of HOST TEST ENVIRONMENT: JDK: 9-ea+174 OS: Microsoft Windows [Version 6.1.7601] Japanese Mitsuru From m-matsushima at bk.jp.nec.com Thu Jun 22 08:06:51 2017 From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima) Date: Thu, 22 Jun 2017 08:06:51 +0000 Subject: Additional infomation for JDK-8048123 In-Reply-To: References: Message-ID: Sorry, I did not know the mailing list strips out attachments. (Thanks for telling me, Martin.) I try to write down the test code and comparison table image below. At the Comparison table, I added the "Supplemental Era" behavior and "Expected?" behavior. Japanese usually use '?' or 'H' for abbreviated name of "??". Thus, I think it's useful that the both of them are usable. So I added the "Expected?" behavior. (Ah, however it seems difficult that different behavior for short form...) (I don't know why CLDR don't describe wide name for Japanese era and why describe wide name as abbreviated name.) Comparison table: ======================================= | SimpleDateFormat| DateTimeFormatter |--------|--------|--------|--------|-------- | Full | Short | Full | Short | Narrow ------------------|--------|--------|--------|--------|-------- COMPAT | ?? | H | ?? | H | H CLDR | ?? | ?? | ?? | ?? | H HOST | ?? | ? | ?? | ? | ?? ------------------|--------|--------|--------|--------|-------- Supplemental Era | NewEra | N.E | NewEra | N.E | N.E ------------------|--------|--------|--------|--------|-------- Expected? | ?? | H | ?? | ? | H ======================================= Test code: Execute with java.locale.provider system property. ======================================= public class SupplementalEraTest2 { public static void main(String... args) { System.out.println("java.locale.providers=" + System.getProperty("java.locale.providers")); // set supplemental era System.setProperty( "jdk.calendar.japanese.supplemental.era", "name=NewEra,abbr=N.E,since=1546300800000"); final int[][] dateSrcs = { //{1989, 1, 7}, {1989, 1, 8}, // Heisei before and after {2018, 12, 31}, {2019, 1, 1}, // NewEra before and after }; System.out.println(">>>>> SimpleDateFormat"); printWithSimpleDateFormat(dateSrcs); System.out.println(">>>>> DateTimeFormatter"); printWithDateTimeFormatter(dateSrcs); } private static void printWithSimpleDateFormat(int[][] dateSrcs) { final Locale jpLocale = new Locale("ja", "JP", "JP"); final Calendar cal = Calendar.getInstance(); final Date[] dates = Arrays.stream(dateSrcs) .map((int[] d) -> { // first month is 0 cal.set(d[0], d[1] - 1, d[2], 0, 0, 0); return cal.getTime(); }).toArray(Date[]::new); System.out.println("---Full format"); SimpleDateFormat fmtLong = new SimpleDateFormat( "GGGG", jpLocale); Arrays.stream(dates).map(fmtLong::format).forEach(System.out::println); System.out.println("---Short format"); SimpleDateFormat fmtShort = new SimpleDateFormat( "G", jpLocale); Arrays.stream(dates).map(fmtShort::format).forEach(System.out::println); } private static void printWithDateTimeFormatter(int[][] dateSrcs) { final Locale jpLocale = new Locale("ja", "JP", "JP"); final LocalDate[] lDates = Arrays.stream(dateSrcs) .map((int[] d) -> LocalDate.of(d[0], d[1], d[2])) .toArray(LocalDate[]::new); System.out.println("---Full format"); final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGG") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrFull::format).forEach(System.out::println); System.out.println("---Short format"); DateTimeFormatter fmtrShort = DateTimeFormatter.ofPattern("G") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrShort::format).forEach(System.out::println); System.out.println("---Narrow format"); DateTimeFormatter fmtrNarrow = DateTimeFormatter.ofPattern("GGGGG") .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); Arrays.stream(lDates).map(fmtrNarrow::format).forEach(System.out::println); } } ======================================= Mitsuru > -----Original Message----- > From: Matsushima Mitsuru(?? ?) > Sent: Wednesday, June 21, 2017 9:40 PM > To: i18n-dev at openjdk.java.net > Cc: Matsushima Mitsuru(?? ?) > Subject: Additional infomation for JDK-8048123 > > Hi. > > I reported JDK-8048123 before. > But I notice this issue is more complex. > > It's unable to attach files at the web form, so I post to ml. > > At first, I thought it's a issue of the fix for JDK-8173423. > However, I think it's a issue of CalendarNameProviders now. > > I tested attatched AupplementalEraTest2.java with 3 providers (COMPAT, CLDR and HOST). > And I compared the result as dateFormatComparison.png. > > I think SHORT and NARROW should be same form. > Thus, I think the values of follows are wrong. > > -At SimpleDateFormat: > SHORT form of CLDR > -At DateTimeFormatter: > NARROW form of COMPAT and CLDR > Narrow form of HOST > > > TEST ENVIRONMENT: > JDK: 9-ea+174 > OS: Microsoft Windows [Version 6.1.7601] Japanese > > > Mitsuru From naoto.sato at oracle.com Thu Jun 22 10:16:57 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 22 Jun 2017 15:46:57 +0530 Subject: Additional infomation for JDK-8048123 In-Reply-To: References: Message-ID: <0de0c62e-1f71-5f8f-d33f-98d205bd1608@oracle.com> Hi Matsushima-san, Thank you for the further information on the issue. I attached your observation in the bug report. I will fix it along with the supplemental era's short name inconsistency. Naoto On 6/22/17 1:36 PM, Mitsuru Matsushima wrote: > At the Comparison table, I added the "Supplemental Era" behavior and "Expected?" behavior. > Japanese usually use '?' or 'H' for abbreviated name of "??". > Thus, I think it's useful that the both of them are usable. > So I added the "Expected?" behavior. > (Ah, however it seems difficult that different behavior for short form...) > (I don't know why CLDR don't describe wide name for Japanese era and why describe wide name as abbreviated name.) > > Comparison table: > ======================================= > | SimpleDateFormat| DateTimeFormatter > |--------|--------|--------|--------|-------- > | Full | Short | Full | Short | Narrow > ------------------|--------|--------|--------|--------|-------- > COMPAT | ?? | H | ?? | H | H > CLDR | ?? | ?? | ?? | ?? | H > HOST | ?? | ? | ?? | ? | ?? > ------------------|--------|--------|--------|--------|-------- > Supplemental Era | NewEra | N.E | NewEra | N.E | N.E > ------------------|--------|--------|--------|--------|-------- > Expected? | ?? | H | ?? | ? | H > ======================================= > > > Test code: > Execute with java.locale.provider system property. > ======================================= > public class SupplementalEraTest2 { > > public static void main(String... args) { > System.out.println("java.locale.providers=" > + System.getProperty("java.locale.providers")); > // set supplemental era > System.setProperty( > "jdk.calendar.japanese.supplemental.era", > "name=NewEra,abbr=N.E,since=1546300800000"); > > final int[][] dateSrcs = { > //{1989, 1, 7}, {1989, 1, 8}, // Heisei before and after > {2018, 12, 31}, {2019, 1, 1}, // NewEra before and after > }; > > System.out.println(">>>>> SimpleDateFormat"); > printWithSimpleDateFormat(dateSrcs); > > System.out.println(">>>>> DateTimeFormatter"); > printWithDateTimeFormatter(dateSrcs); > } > > private static void printWithSimpleDateFormat(int[][] dateSrcs) { > final Locale jpLocale = new Locale("ja", "JP", "JP"); > final Calendar cal = Calendar.getInstance(); > final Date[] dates = Arrays.stream(dateSrcs) > .map((int[] d) -> { // first month is 0 > cal.set(d[0], d[1] - 1, d[2], 0, 0, 0); > return cal.getTime(); > }).toArray(Date[]::new); > System.out.println("---Full format"); > SimpleDateFormat fmtLong = new SimpleDateFormat( > "GGGG", jpLocale); > Arrays.stream(dates).map(fmtLong::format).forEach(System.out::println); > System.out.println("---Short format"); > SimpleDateFormat fmtShort = new SimpleDateFormat( > "G", jpLocale); > Arrays.stream(dates).map(fmtShort::format).forEach(System.out::println); > } > > private static void printWithDateTimeFormatter(int[][] dateSrcs) { > final Locale jpLocale = new Locale("ja", "JP", "JP"); > final LocalDate[] lDates = Arrays.stream(dateSrcs) > .map((int[] d) -> LocalDate.of(d[0], d[1], d[2])) > .toArray(LocalDate[]::new); > System.out.println("---Full format"); > final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGG") > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > Arrays.stream(lDates).map(fmtrFull::format).forEach(System.out::println); > > System.out.println("---Short format"); > DateTimeFormatter fmtrShort = DateTimeFormatter.ofPattern("G") > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > Arrays.stream(lDates).map(fmtrShort::format).forEach(System.out::println); > > System.out.println("---Narrow format"); > DateTimeFormatter fmtrNarrow = DateTimeFormatter.ofPattern("GGGGG") > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > Arrays.stream(lDates).map(fmtrNarrow::format).forEach(System.out::println); > } > } > ======================================= From m-matsushima at bk.jp.nec.com Thu Jun 22 10:38:52 2017 From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima) Date: Thu, 22 Jun 2017 10:38:52 +0000 Subject: Additional infomation for JDK-8048123 In-Reply-To: <0de0c62e-1f71-5f8f-d33f-98d205bd1608@oracle.com> References: <0de0c62e-1f71-5f8f-d33f-98d205bd1608@oracle.com> Message-ID: Hi Sato-san, Thank you for your response. Sorry for teaching you the wrong issue number. (However, it seems you handled fine...) wrong: JDK-8048123 correct: JDK-8180469 Mitsuru > -----Original Message----- > From: Naoto Sato [mailto:naoto.sato at oracle.com] > Sent: Thursday, June 22, 2017 7:17 PM > To: Matsushima Mitsuru(?? ?) ; i18n-dev at openjdk.java.net > Subject: Re: Additional infomation for JDK-8048123 > > Hi Matsushima-san, > > Thank you for the further information on the issue. I attached your observation in the bug report. I will fix it along > with the supplemental era's short name inconsistency. > > Naoto > > On 6/22/17 1:36 PM, Mitsuru Matsushima wrote: > > At the Comparison table, I added the "Supplemental Era" behavior and "Expected?" behavior. > > Japanese usually use '?' or 'H' for abbreviated name of "??". > > Thus, I think it's useful that the both of them are usable. > > So I added the "Expected?" behavior. > > (Ah, however it seems difficult that different behavior for short > > form...) (I don't know why CLDR don't describe wide name for Japanese > > era and why describe wide name as abbreviated name.) > > > > Comparison table: > > ======================================= > > | SimpleDateFormat| DateTimeFormatter > > |--------|--------|--------|--------|-------- > > | Full | Short | Full | Short | Narrow > > ------------------|--------|--------|--------|--------|-------- > > COMPAT | ?? | H | ?? | H | H > > CLDR | ?? | ?? | ?? | ?? | H > > HOST | ?? | ? | ?? | ? | ?? > > ------------------|--------|--------|--------|--------|-------- > > Supplemental Era | NewEra | N.E | NewEra | N.E | N.E > > ------------------|--------|--------|--------|--------|-------- > > Expected? | ?? | H | ?? | ? | H > > ======================================= > > > > > > Test code: > > Execute with java.locale.provider system property. > > ======================================= > > public class SupplementalEraTest2 { > > > > public static void main(String... args) { > > System.out.println("java.locale.providers=" > > + System.getProperty("java.locale.providers")); > > // set supplemental era > > System.setProperty( > > "jdk.calendar.japanese.supplemental.era", > > "name=NewEra,abbr=N.E,since=1546300800000"); > > > > final int[][] dateSrcs = { > > //{1989, 1, 7}, {1989, 1, 8}, // Heisei before and after > > {2018, 12, 31}, {2019, 1, 1}, // NewEra before and after > > }; > > > > System.out.println(">>>>> SimpleDateFormat"); > > printWithSimpleDateFormat(dateSrcs); > > > > System.out.println(">>>>> DateTimeFormatter"); > > printWithDateTimeFormatter(dateSrcs); > > } > > > > private static void printWithSimpleDateFormat(int[][] dateSrcs) { > > final Locale jpLocale = new Locale("ja", "JP", "JP"); > > final Calendar cal = Calendar.getInstance(); > > final Date[] dates = Arrays.stream(dateSrcs) > > .map((int[] d) -> { // first month is 0 > > cal.set(d[0], d[1] - 1, d[2], 0, 0, 0); > > return cal.getTime(); > > }).toArray(Date[]::new); > > System.out.println("---Full format"); > > SimpleDateFormat fmtLong = new SimpleDateFormat( > > "GGGG", jpLocale); > > Arrays.stream(dates).map(fmtLong::format).forEach(System.out::println); > > System.out.println("---Short format"); > > SimpleDateFormat fmtShort = new SimpleDateFormat( > > "G", jpLocale); > > Arrays.stream(dates).map(fmtShort::format).forEach(System.out::println); > > } > > > > private static void printWithDateTimeFormatter(int[][] dateSrcs) { > > final Locale jpLocale = new Locale("ja", "JP", "JP"); > > final LocalDate[] lDates = Arrays.stream(dateSrcs) > > .map((int[] d) -> LocalDate.of(d[0], d[1], d[2])) > > .toArray(LocalDate[]::new); > > System.out.println("---Full format"); > > final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGG") > > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > > > > Arrays.stream(lDates).map(fmtrFull::format).forEach(System.out::printl > > n); > > > > System.out.println("---Short format"); > > DateTimeFormatter fmtrShort = DateTimeFormatter.ofPattern("G") > > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > > > > Arrays.stream(lDates).map(fmtrShort::format).forEach(System.out::print > > ln); > > > > System.out.println("---Narrow format"); > > DateTimeFormatter fmtrNarrow = DateTimeFormatter.ofPattern("GGGGG") > > .withChronology(JapaneseChronology.INSTANCE).withLocale(jpLocale); > > Arrays.stream(lDates).map(fmtrNarrow::format).forEach(System.out::println); > > } > > } > > ======================================= From m-matsushima at bk.jp.nec.com Thu Jun 22 12:50:53 2017 From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima) Date: Thu, 22 Jun 2017 12:50:53 +0000 Subject: The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property Message-ID: Hi, I found an issue about "jdk.calendar.sypplemental.era" system property. According toJavadoc of JapaneseImperialCalendar, the system property can specify "since" parameter as UTC time. However, on using UTC time, the first year of new era is skipped. The new era start with a second year as follow: NewEra2?1?1? 12:0:0.0 ??30?12?31? 11:59:59.999999999 TEST CODE: ======================================= public static void main(String... args) { // set supplemental era final long since = ZonedDateTime .of(2019, 1, 1, 0, 0, 0, 0, ZoneId.of("Asia/Tokyo")) .toInstant().toEpochMilli(); System.setProperty( "jdk.calendar.japanese.supplemental.era", "name=NewEra,abbr=N.E,since=" + since + "u"); final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGGy?M?d? h:m:s.n") .withChronology(JapaneseChronology.INSTANCE) .withLocale(new Locale("ja", "JP", "JP")); IntStream.rangeClosed(0, 1) .mapToObj(h -> LocalDateTime.of(2019, 1, 1, 0, 0).minusNanos(h)) .map(fmtrFull::format) .forEach(System.out::println); } ======================================= TEST ENVIRONMENT: java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+174) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+174, mixed mode) --- Mitsuru From naoto.sato at oracle.com Thu Jun 22 23:38:43 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 23 Jun 2017 05:08:43 +0530 Subject: The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property In-Reply-To: References: Message-ID: <43c92c5d-16e7-a37c-f4c7-da54d6a9af63@oracle.com> Hi Matsushita-san, I will look into it. Could you please file an issue about this? Naoto On 6/22/17 6:20 PM, Mitsuru Matsushima wrote: > Hi, > > I found an issue about "jdk.calendar.sypplemental.era" system property. > > According toJavadoc of JapaneseImperialCalendar, the system property can specify "since" parameter as UTC time. > > However, on using UTC time, the first year of new era is skipped. > The new era start with a second year as follow: > > NewEra2?1?1? 12:0:0.0 > ??30?12?31? 11:59:59.999999999 > > TEST CODE: > ======================================= > public static void main(String... args) { > // set supplemental era > final long since = ZonedDateTime > .of(2019, 1, 1, 0, 0, 0, 0, ZoneId.of("Asia/Tokyo")) > .toInstant().toEpochMilli(); > System.setProperty( > "jdk.calendar.japanese.supplemental.era", > "name=NewEra,abbr=N.E,since=" + since + "u"); > final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGGy?M?d? h:m:s.n") > .withChronology(JapaneseChronology.INSTANCE) > .withLocale(new Locale("ja", "JP", "JP")); > IntStream.rangeClosed(0, 1) > .mapToObj(h -> LocalDateTime.of(2019, 1, 1, 0, 0).minusNanos(h)) > .map(fmtrFull::format) > .forEach(System.out::println); > } > ======================================= > > TEST ENVIRONMENT: > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+174) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+174, mixed mode) > > --- > Mitsuru > From m-matsushima at bk.jp.nec.com Fri Jun 23 02:10:40 2017 From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima) Date: Fri, 23 Jun 2017 02:10:40 +0000 Subject: The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property In-Reply-To: <43c92c5d-16e7-a37c-f4c7-da54d6a9af63@oracle.com> References: <43c92c5d-16e7-a37c-f4c7-da54d6a9af63@oracle.com> Message-ID: Hi Naoto-san, Thank you for your response. I reported this issue to bugreport.java.com now. --- Mitsuru > -----Original Message----- > From: Naoto Sato [mailto:naoto.sato at oracle.com] > Sent: Friday, June 23, 2017 8:39 AM > To: Matsushima Mitsuru(?? ?) ; i18n-dev at openjdk.java.net > Subject: Re: The first year skipped when using UTC time for "jdk.calendar.sypplemental.era" system property > > Hi Matsushita-san, > > I will look into it. Could you please file an issue about this? > > Naoto > > On 6/22/17 6:20 PM, Mitsuru Matsushima wrote: > > Hi, > > > > I found an issue about "jdk.calendar.sypplemental.era" system property. > > > > According toJavadoc of JapaneseImperialCalendar, the system property can specify "since" parameter as UTC time. > > > > However, on using UTC time, the first year of new era is skipped. > > The new era start with a second year as follow: > > > > NewEra2?1?1? 12:0:0.0 > > ??30?12?31? 11:59:59.999999999 > > > > TEST CODE: > > ======================================= > > public static void main(String... args) { > > // set supplemental era > > final long since = ZonedDateTime > > .of(2019, 1, 1, 0, 0, 0, 0, ZoneId.of("Asia/Tokyo")) > > .toInstant().toEpochMilli(); > > System.setProperty( > > "jdk.calendar.japanese.supplemental.era", > > "name=NewEra,abbr=N.E,since=" + since + "u"); > > final DateTimeFormatter fmtrFull = DateTimeFormatter.ofPattern("GGGGy?M?d? h:m:s.n") > > .withChronology(JapaneseChronology.INSTANCE) > > .withLocale(new Locale("ja", "JP", "JP")); > > IntStream.rangeClosed(0, 1) > > .mapToObj(h -> LocalDateTime.of(2019, 1, 1, 0, 0).minusNanos(h)) > > .map(fmtrFull::format) > > .forEach(System.out::println); > > } > > ======================================= > > > > TEST ENVIRONMENT: > > java version "9-ea" > > Java(TM) SE Runtime Environment (build 9-ea+174) Java HotSpot(TM) > > 64-Bit Server VM (build 9-ea+174, mixed mode) > > > > --- > > Mitsuru > > From naoto.sato at oracle.com Wed Jun 28 17:51:59 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 28 Jun 2017 10:51:59 -0700 Subject: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X Message-ID: Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8160199 The fix is located at: http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ The gist of the issue was that the script code has not been properly treated in macOS specific code. Since it shares the same code with other Unix, the locale format should follow POSIX, such as az-Cyrl-AZ needing to be az_AZ at Cyrl. Naoto From brent.christian at oracle.com Wed Jun 28 21:16:06 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 28 Jun 2017 14:16:06 -0700 Subject: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X In-Reply-To: References: Message-ID: Hi, Naoto This looks quite good. I will test a bit with some of the trickier locales. BTW, the script will now also be reflected in Locale.getScript() and Locale.getDisplayScript(). Just a few comments: --- src/java.base/macosx/native/libjava/java_props_macosx.h Update copyright year --- src/java.base/unix/native/libjava/locale_str.h Update copyright year 214 "Hans", "Hans", 215 "Hant", "Hant", 216 "Latn", "Latn", 217 "Cyrl", "Cyrl", 218 "Arab", "Arab", MacOS 10.12 ("Sierra") has a number of new languages not present in 10.11, including a few new scripts. I believe these should also be added here: Deva Ethi Sund Syrc Tfng --- src/java.base/macosx/native/libjava/java_props_macosx.c Similar to the previous code, the call to: 79 CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), 80 localeString, LOCALEIDLENGTH, CFStringGetSystemEncoding()); can be moved inside the if(): 84 if (hyphenPos == NULL || // languageString contains ISO639 only, e.g., "en" 85 languageString + langStrLen - hyphenPos == 5) { FWIW, I believe this code path will only be taken for MacOS 10.11 and earlier. Per TN2418[1] (and my testing thus far), 10.12 will always provide a region to 'languageString'. 10.11 and prior often return just a two-character language code. 134 * lang{_region}{@script}. e.g., 135 * for "zh-Hans-US" into "zh_US at Hans" This comment could fit on one line. 152 char tmp[4]; Maybe a more descriptive name ("tmpScript" ?) 173 assert((length == 3 || length == 8) && ... Idea: adding another set of ()s grouping: length 3 or 8 case length 4 or 9 case length == 5 case would cause each case to highlight nicely in an IDE. Just a thought. A JDK 10 Reviewer will also need to take a look. Thanks, -Brent 1. https://developer.apple.com/library/content/technotes/tn2418/_index.html On 6/28/17 10:51 AM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8160199 > > The fix is located at: > > http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ > > The gist of the issue was that the script code has not been properly > treated in macOS specific code. Since it shares the same code with other > Unix, the locale format should follow POSIX, such as az-Cyrl-AZ needing > to be az_AZ at Cyrl. > > Naoto From naoto.sato at oracle.com Wed Jun 28 22:13:50 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 28 Jun 2017 15:13:50 -0700 Subject: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X In-Reply-To: References: Message-ID: <573ae747-69cd-d4e1-e524-feab5e228242@oracle.com> Thanks, Brent! Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8160199/webrev.04/ And my comments embedded below: On 6/28/17 2:16 PM, Brent Christian wrote: > Hi, Naoto > > This looks quite good. > > I will test a bit with some of the trickier locales. BTW, the script > will now also be reflected in Locale.getScript() and > Locale.getDisplayScript(). > > Just a few comments: > > --- > src/java.base/macosx/native/libjava/java_props_macosx.h > > Update copyright year > > --- > src/java.base/unix/native/libjava/locale_str.h > > Update copyright year Done. > > 214 "Hans", "Hans", > 215 "Hant", "Hant", > 216 "Latn", "Latn", > 217 "Cyrl", "Cyrl", > 218 "Arab", "Arab", > > MacOS 10.12 ("Sierra") has a number of new languages not present in > 10.11, including a few new scripts. I believe these should also be > added here: > > Deva > Ethi > Sund > Syrc > Tfng Good catch! Added those and tested, except "Syrc" script (could not find on my machine). > > --- > src/java.base/macosx/native/libjava/java_props_macosx.c > > Similar to the previous code, the call to: > > 79 CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), > 80 localeString, LOCALEIDLENGTH, > CFStringGetSystemEncoding()); > > can be moved inside the if(): > > 84 if (hyphenPos == NULL || // languageString contains > ISO639 only, e.g., "en" > 85 languageString + langStrLen - hyphenPos == 5) { Done. > > > FWIW, I believe this code path will only be taken for MacOS 10.11 and > earlier. Per TN2418[1] (and my testing thus far), 10.12 will always > provide a region to 'languageString'. 10.11 and prior often return just > a two-character language code. Yes. > > > 134 * lang{_region}{@script}. e.g., > 135 * for "zh-Hans-US" into "zh_US at Hans" > > This comment could fit on one line. > > > 152 char tmp[4]; > > Maybe a more descriptive name ("tmpScript" ?) Done. > > > 173 assert((length == 3 || length == 8) && > ... > > Idea: adding another set of ()s grouping: > > length 3 or 8 case > length 4 or 9 case > length == 5 case > > would cause each case to highlight nicely in an IDE. Just a thought. I grouped those, but haven't confirmed on an IDE :-) > > > A JDK 10 Reviewer will also need to take a look. Sure, wait for another review then. Naoto > > Thanks, > -Brent > > 1. https://developer.apple.com/library/content/technotes/tn2418/_index.html > > > On 6/28/17 10:51 AM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8160199 >> >> The fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ >> >> The gist of the issue was that the script code has not been properly >> treated in macOS specific code. Since it shares the same code with >> other Unix, the locale format should follow POSIX, such as az-Cyrl-AZ >> needing to be az_AZ at Cyrl. >> >> Naoto From brent.christian at oracle.com Thu Jun 29 20:25:51 2017 From: brent.christian at oracle.com (Brent Christian) Date: Thu, 29 Jun 2017 13:25:51 -0700 Subject: [10] RFR: 8160199: Language's script should be reflected in user.script on Mac OS X In-Reply-To: <573ae747-69cd-d4e1-e524-feab5e228242@oracle.com> References: <573ae747-69cd-d4e1-e524-feab5e228242@oracle.com> Message-ID: <8e375b48-42d3-ac4b-cf45-c930dab99097@oracle.com> Thanks, Naoto. The updated changes look good. -Brent On 06/28/2017 03:13 PM, Naoto Sato wrote: > Thanks, Brent! Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8160199/webrev.04/ > > And my comments embedded below: > > On 6/28/17 2:16 PM, Brent Christian wrote: >> Hi, Naoto >> >> This looks quite good. >> >> I will test a bit with some of the trickier locales. BTW, the script >> will now also be reflected in Locale.getScript() and >> Locale.getDisplayScript(). >> >> Just a few comments: >> >> --- >> src/java.base/macosx/native/libjava/java_props_macosx.h >> >> Update copyright year >> >> --- >> src/java.base/unix/native/libjava/locale_str.h >> >> Update copyright year > > Done. > >> >> 214 "Hans", "Hans", >> 215 "Hant", "Hant", >> 216 "Latn", "Latn", >> 217 "Cyrl", "Cyrl", >> 218 "Arab", "Arab", >> >> MacOS 10.12 ("Sierra") has a number of new languages not present in >> 10.11, including a few new scripts. I believe these should also be >> added here: >> >> Deva >> Ethi >> Sund >> Syrc >> Tfng > > Good catch! Added those and tested, except "Syrc" script (could not find > on my machine). > >> >> --- >> src/java.base/macosx/native/libjava/java_props_macosx.c >> >> Similar to the previous code, the call to: >> >> 79 CFStringGetCString(CFLocaleGetIdentifier(CFLocaleCopyCurrent()), >> 80 localeString, LOCALEIDLENGTH, >> CFStringGetSystemEncoding()); >> >> can be moved inside the if(): >> >> 84 if (hyphenPos == NULL || // languageString contains >> ISO639 only, e.g., "en" >> 85 languageString + langStrLen - hyphenPos == 5) { > > Done. > >> >> >> FWIW, I believe this code path will only be taken for MacOS 10.11 and >> earlier. Per TN2418[1] (and my testing thus far), 10.12 will always >> provide a region to 'languageString'. 10.11 and prior often return >> just a two-character language code. > > Yes. > >> >> >> 134 * lang{_region}{@script}. e.g., >> 135 * for "zh-Hans-US" into "zh_US at Hans" >> >> This comment could fit on one line. >> >> >> 152 char tmp[4]; >> >> Maybe a more descriptive name ("tmpScript" ?) > > Done. > >> >> >> 173 assert((length == 3 || length == 8) && >> ... >> >> Idea: adding another set of ()s grouping: >> >> length 3 or 8 case >> length 4 or 9 case >> length == 5 case >> >> would cause each case to highlight nicely in an IDE. Just a thought. > > I grouped those, but haven't confirmed on an IDE :-) >> >> >> A JDK 10 Reviewer will also need to take a look. > > Sure, wait for another review then. > > Naoto > >> >> Thanks, >> -Brent >> >> 1. >> https://developer.apple.com/library/content/technotes/tn2418/_index.html >> >> >> On 6/28/17 10:51 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the fix to the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8160199 >>> >>> The fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8160199/webrev.03/ >>> >>> The gist of the issue was that the script code has not been properly >>> treated in macOS specific code. Since it shares the same code with >>> other Unix, the locale format should follow POSIX, such as az-Cyrl-AZ >>> needing to be az_AZ at Cyrl. >>> >>> Naoto