From ramanand.patil at oracle.com Thu Mar 2 12:45:26 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 2 Mar 2017 04:45:26 -0800 (PST) Subject: RFR: 8176044: (tz) Support tzdata2017a Message-ID: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> Hi all, Please review the latest TZDATA integration (tzdata2017a) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From naoto.sato at oracle.com Thu Mar 2 18:51:04 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 2 Mar 2017 10:51:04 -0800 Subject: RFR: 8176044: (tz) Support tzdata2017a In-Reply-To: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> References: <5906baa2-ce3c-41e1-aad7-db9583988a6e@default> Message-ID: Looks fine. Thanks, Ramanand. Naoto On 3/2/17 4:45 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2017a) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8176044 > Webrev: http://cr.openjdk.java.net/~rpatil/8176044/webrev.00/ > > All the TimeZone related tests are passed after integration. > > Regards, > Ramanand. > From naoto.sato at oracle.com Fri Mar 3 21:19:38 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 3 Mar 2017 13:19:38 -0800 Subject: [9] RFR: 8174736: [JCP] [Mac]Cannot launch JCP on Mac os with language set to "Chinese, Simplified" while region is not China Message-ID: <551c1dea-da72-920d-f2fb-557657923734@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8174736 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8174736/webrev.00/ This is a follow-on fix to 8174779 [1]. The previous fix addresses the issue for the default locale, and this one is to address the default format locale in order to handle locales with script codes on macOS. Naoto [1] https://bugs.openjdk.java.net/browse/JDK-8174779 From amy.lu at oracle.com Mon Mar 6 03:06:54 2017 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 6 Mar 2017 11:06:54 +0800 Subject: JDK 9 RFR of JDK-8176185: java/util/TimeZone/UTCAliasTest.java is not run Message-ID: java/util/TimeZone/UTCAliasTest.java This is not a compile-only test, but due to the missed @run tag, test is not run. Please review the patch to add @run tag to the test. bug: https://bugs.openjdk.java.net/browse/JDK-8176185 Thanks, Amy --- old/test/java/util/TimeZone/UTCAliasTest.java 2017-03-06 11:01:33.000000000 +0800 +++ new/test/java/util/TimeZone/UTCAliasTest.java 2017-03-06 11:01:33.000000000 +0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2005, 2016, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2005, 2017, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -27,6 +27,7 @@ * @summary Make sure that "UTC" is an alias of "Etc/UTC" as defined in the tzdata backward. * @modules java.base/sun.util.calendar * @compile -XDignore.symbol.file UTCAliasTest.java + * @run main UTCAliasTest */ import java.util.*; From Alan.Bateman at oracle.com Mon Mar 6 07:47:49 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 6 Mar 2017 07:47:49 +0000 Subject: JDK 9 RFR of JDK-8176185: java/util/TimeZone/UTCAliasTest.java is not run In-Reply-To: References: Message-ID: <3a39cb42-4125-649e-c3f6-96bc4bd9080f@oracle.com> On 06/03/2017 03:06, Amy Lu wrote: > java/util/TimeZone/UTCAliasTest.java > > This is not a compile-only test, but due to the missed @run tag, test > is not run. > > Please review the patch to add @run tag to the test. Looks okay, alternatively then I assume dropping the @compile tag will work too. -Alan From brent.christian at oracle.com Mon Mar 6 23:21:46 2017 From: brent.christian at oracle.com (Brent Christian) Date: Mon, 6 Mar 2017 15:21:46 -0800 Subject: [9] RFR: 8174736: [JCP] [Mac]Cannot launch JCP on Mac os with language set to "Chinese, Simplified" while region is not China In-Reply-To: <551c1dea-da72-920d-f2fb-557657923734@oracle.com> References: <551c1dea-da72-920d-f2fb-557657923734@oracle.com> Message-ID: <9eeec93e-23f9-6042-af00-d1a18fe3ac97@oracle.com> Hi, Naoto That fix looks fine. The "Portuguese (Brazil)" fix now happens before the Language ID fix, but that shouldn't matter, as the "pt_BR" ID won't trigger that code anyway (doesn't contain '-'). One very mall nit I noticed: one more space on line 97 will realign it with line 96, which now has an additional '!' character. That's my small-'r'-review. -Brent On 03/03/17 13:19, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8174736 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8174736/webrev.00/ > > This is a follow-on fix to 8174779 [1]. The previous fix addresses the > issue for the default locale, and this one is to address the default > format locale in order to handle locales with script codes on macOS. > > Naoto > [1] https://bugs.openjdk.java.net/browse/JDK-8174779 From naoto.sato at oracle.com Mon Mar 6 23:33:39 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 6 Mar 2017 15:33:39 -0800 Subject: [9] RFR: 8174736: [JCP] [Mac]Cannot launch JCP on Mac os with language set to "Chinese, Simplified" while region is not China In-Reply-To: <9eeec93e-23f9-6042-af00-d1a18fe3ac97@oracle.com> References: <551c1dea-da72-920d-f2fb-557657923734@oracle.com> <9eeec93e-23f9-6042-af00-d1a18fe3ac97@oracle.com> Message-ID: <3f3d9c49-e30b-833f-bcf6-3354d897ee4c@oracle.com> Hi Brent, thanks for the review! On 3/6/17 3:21 PM, Brent Christian wrote: > Hi, Naoto > > That fix looks fine. > > The "Portuguese (Brazil)" fix now happens before the Language ID fix, > but that shouldn't matter, as the "pt_BR" ID won't trigger that code > anyway (doesn't contain '-'). Yes. > One very mall nit I noticed: one more space on line 97 will realign it > with line 96, which now has an additional '!' character. Ah, good eye! Will fix it before the push. > > That's my small-'r'-review. :-) Naoto > > -Brent > > On 03/03/17 13:19, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8174736 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8174736/webrev.00/ >> >> This is a follow-on fix to 8174779 [1]. The previous fix addresses the >> issue for the default locale, and this one is to address the default >> format locale in order to handle locales with script codes on macOS. >> >> Naoto >> [1] https://bugs.openjdk.java.net/browse/JDK-8174779 From jl-thiry at efluid.fr Thu Mar 16 14:07:43 2017 From: jl-thiry at efluid.fr (THIRY, Jean-Luc) Date: Thu, 16 Mar 2017 14:07:43 +0000 Subject: localization of a java application Message-ID: Hi, I am a new subscriber to the i18n-dev list. Currently I have to organize the localization of a big java application that has been developed for 15 years using 2 types of java resources to manage localization : - .properties files used with resource bundles for common tags in forms, messages and java enums - data collected in SQL tables for dynamic enums As the application is big (property files with more than a 1700 entries) and a big number of enums (over 500), I have to find tools to automate the localization process knowing that the application has numerous new features added each year, features that we need to keep localized as we deliver new versions of the application. Theses resources are located in different jar's in the project which makes the data retrieval of all the .properties tedious. The process I have in mind has to detect new entries in the property files or in the database, extract these new labels in files so that I can transmit the information to a localization provider which in return can send me back the files with the labels localized. I have been looking for information on standards and I found XLIFF 1.0 and 2.0 interesting to manage the exchange process with the localization provider and I found java APIs to translate a .properties in a XLIFF file. The trouble is I have many things to code to have a full process operating so I have been looking also for other solutions. I found GNU getText well designed to manage localization of Linux projects. I would be interested in having more information on how to manage this knowing that you have exactly the same problem when you manage Localization of projects such as JDK or JRE. So how do you do this ? Thank's in advance, Cheers, Jean-Luc From martinrb at google.com Thu Mar 16 17:13:08 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 16 Mar 2017 10:13:08 -0700 Subject: RFR: Remove stray @deprecated in Date#getDate Message-ID: I say we make this extraordinarily safe fix in jdk9: https://bugs.openjdk.java.net/browse/JDK-8176886 --- a/src/java.base/share/classes/java/util/Date.java +++ b/src/java.base/share/classes/java/util/Date.java @@ -728,7 +728,6 @@ * @see java.util.Calendar * @deprecated As of JDK version 1.1, * replaced by {@code Calendar.get(Calendar.DAY_OF_MONTH)}. - * @deprecated */ @Deprecated public int getDate() { From naoto.sato at oracle.com Thu Mar 16 17:45:38 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 16 Mar 2017 10:45:38 -0700 Subject: RFR: Remove stray @deprecated in Date#getDate In-Reply-To: References: Message-ID: <53e22857-b9b3-7681-253d-262894a3aa8a@oracle.com> Looks good. Naoto On 3/16/17 10:13 AM, Martin Buchholz wrote: > I say we make this extraordinarily safe fix in jdk9: > > https://bugs.openjdk.java.net/browse/JDK-8176886 > --- a/src/java.base/share/classes/java/util/Date.java > +++ b/src/java.base/share/classes/java/util/Date.java > @@ -728,7 +728,6 @@ > * @see java.util.Calendar > * @deprecated As of JDK version 1.1, > * replaced by {@code Calendar.get(Calendar.DAY_OF_MONTH)}. > - * @deprecated > */ > @Deprecated > public int getDate() { > From li.jiang at oracle.com Wed Mar 22 08:37:32 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Wed, 22 Mar 2017 16:37:32 +0800 Subject: localization of a java application In-Reply-To: References: Message-ID: Hi, Jean-Luc, Yes, the problem we are facing is common, we have Oracle-specific tools and process to handle the data exchange with translation vendors. You need to build up yours. Thanks, Leo On 03/16/2017 10:07 PM, THIRY, Jean-Luc wrote: > Hi, > > I am a new subscriber to the i18n-dev list. > Currently I have to organize the localization of a big java application that has been developed for 15 years using 2 types of java resources to manage localization : > > - .properties files used with resource bundles for common tags in forms, messages and java enums > > - data collected in SQL tables for dynamic enums > > As the application is big (property files with more than a 1700 entries) and a big number of enums (over 500), I have to find tools to automate the localization process knowing that the application has numerous new features added each year, features that we need to keep localized as we deliver new versions of the application. Theses resources are located in different jar's in the project which makes the data retrieval of all the .properties tedious. > > The process I have in mind has to detect new entries in the property files or in the database, extract these new labels in files so that I can transmit the information to a localization provider which in return can send me back the files with the labels localized. > > I have been looking for information on standards and I found XLIFF 1.0 and 2.0 interesting to manage the exchange process with the localization provider and I found java APIs to translate a .properties in a XLIFF file. > The trouble is I have many things to code to have a full process operating so I have been looking also for other solutions. > > I found GNU getText well designed to manage localization of Linux projects. > > I would be interested in having more information on how to manage this knowing that you have exactly the same problem when you manage Localization of projects such as JDK or JRE. So how do you do this ? > > Thank's in advance, > > Cheers, > Jean-Luc > From jl-thiry at efluid.fr Wed Mar 22 13:09:54 2017 From: jl-thiry at efluid.fr (THIRY, Jean-Luc) Date: Wed, 22 Mar 2017 13:09:54 +0000 Subject: localization of a java application In-Reply-To: References:

Message-ID: Hi Leo, Thanks for your responses. Can you please tell me what your tools do ? If you manage exchanges with an agency in charge of the translation ? How often you send and receive translation requests ? How do you validate the quality of the translation and who is in charge of it in your team ? Best regards, Jean-Luc -----Message d'origine----- De?: Leo Jiang [mailto:li.jiang at oracle.com] Envoy??: mercredi 22 mars 2017 09:40 ??: i18n-dev at openjdk.java.net; THIRY, Jean-Luc Objet?: Re: localization of a java application Hi, Jean-Luc, Yes, the problem we are facing is common, we have Oracle-specific tools and process to handle the data exchange with translation vendors. You need to build up yours. Thanks, Leo On 03/16/2017 10:07 PM, THIRY, Jean-Luc wrote: > Hi, > > I am a new subscriber to the i18n-dev list. > Currently I have to organize the localization of a big java application that has been developed for 15 years using 2 types of java resources to manage localization : > > - .properties files used with resource bundles for common tags in forms, messages and java enums > > - data collected in SQL tables for dynamic enums > > As the application is big (property files with more than a 1700 entries) and a big number of enums (over 500), I have to find tools to automate the localization process knowing that the application has numerous new features added each year, features that we need to keep localized as we deliver new versions of the application. Theses resources are located in different jar's in the project which makes the data retrieval of all the .properties tedious. > > The process I have in mind has to detect new entries in the property files or in the database, extract these new labels in files so that I can transmit the information to a localization provider which in return can send me back the files with the labels localized. > > I have been looking for information on standards and I found XLIFF 1.0 and 2.0 interesting to manage the exchange process with the localization provider and I found java APIs to translate a .properties in a XLIFF file. > The trouble is I have many things to code to have a full process operating so I have been looking also for other solutions. > > I found GNU getText well designed to manage localization of Linux projects. > > I would be interested in having more information on how to manage this knowing that you have exactly the same problem when you manage Localization of projects such as JDK or JRE. So how do you do this ? > > Thank's in advance, > > Cheers, > Jean-Luc > From li.jiang at oracle.com Thu Mar 23 16:00:40 2017 From: li.jiang at oracle.com (Leo Jiang) Date: Fri, 24 Mar 2017 00:00:40 +0800 Subject: localization of a java application In-Reply-To: References:

Message-ID: <2759bd46-d09e-805f-4793-7c35b5c413a0@oracle.com> Hi Jean-Luc, Any big company would manage the translation memory to help l10n work for their products. So the concrete workflow and tools have to be designed to match your own requirements. In OpenJDK, we did it per several months to update the translation. About the translation quality, it's impossible for product team to verify the qualify, so you need to rely on your translation team and management. Thanks, Leo On 03/22/2017 09:09 PM, THIRY, Jean-Luc wrote: > Hi Leo, > > Thanks for your responses. > Can you please tell me what your tools do ? If you manage exchanges with an agency in charge of the translation ? How often you send and receive translation requests ? How do you validate the quality of the translation and who is in charge of it in your team ? > > Best regards, > > Jean-Luc > > -----Message d'origine----- > De : Leo Jiang [mailto:li.jiang at oracle.com] > Envoy? : mercredi 22 mars 2017 09:40 > ? : i18n-dev at openjdk.java.net; THIRY, Jean-Luc > Objet : Re: localization of a java application > > Hi, Jean-Luc, > > Yes, the problem we are facing is common, we have Oracle-specific tools and process to handle the data exchange with translation vendors. You need to build up yours. > > Thanks, > Leo > > > On 03/16/2017 10:07 PM, THIRY, Jean-Luc wrote: >> Hi, >> >> I am a new subscriber to the i18n-dev list. >> Currently I have to organize the localization of a big java application that has been developed for 15 years using 2 types of java resources to manage localization : >> >> - .properties files used with resource bundles for common tags in forms, messages and java enums >> >> - data collected in SQL tables for dynamic enums >> >> As the application is big (property files with more than a 1700 entries) and a big number of enums (over 500), I have to find tools to automate the localization process knowing that the application has numerous new features added each year, features that we need to keep localized as we deliver new versions of the application. Theses resources are located in different jar's in the project which makes the data retrieval of all the .properties tedious. >> >> The process I have in mind has to detect new entries in the property files or in the database, extract these new labels in files so that I can transmit the information to a localization provider which in return can send me back the files with the labels localized. >> >> I have been looking for information on standards and I found XLIFF 1.0 and 2.0 interesting to manage the exchange process with the localization provider and I found java APIs to translate a .properties in a XLIFF file. >> The trouble is I have many things to code to have a full process operating so I have been looking also for other solutions. >> >> I found GNU getText well designed to manage localization of Linux projects. >> >> I would be interested in having more information on how to manage this knowing that you have exactly the same problem when you manage Localization of projects such as JDK or JRE. So how do you do this ? >> >> Thank's in advance, >> >> Cheers, >> Jean-Luc >> From dalibor.topic at oracle.com Mon Mar 27 11:01:31 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 27 Mar 2017 13:01:31 +0200 Subject: localization of a java application In-Reply-To: References:

Message-ID: Salut Jean-Luc, as your question concerns Oracle-internal tools and processes, I don't think you will (or should ;) get replies on this list. Instead, I'd suggest asking in the Oracle Community on OTN (community.oracle.com), and, if you are interested in Oracle-specific i18n information, look into presentations given around that topic at Oracle Open World, Java One or similar events in the past. cheers, dalibor topic On 22.03.2017 14:09, THIRY, Jean-Luc wrote: > Hi Leo, > > Thanks for your responses. > Can you please tell me what your tools do ? If you manage exchanges with an agency in charge of the translation ? How often you send and receive translation requests ? How do you validate the quality of the translation and who is in charge of it in your team ? > > Best regards, > > Jean-Luc > > -----Message d'origine----- > De : Leo Jiang [mailto:li.jiang at oracle.com] > Envoy? : mercredi 22 mars 2017 09:40 > ? : i18n-dev at openjdk.java.net; THIRY, Jean-Luc > Objet : Re: localization of a java application > > Hi, Jean-Luc, > > Yes, the problem we are facing is common, we have Oracle-specific tools and process to handle the data exchange with translation vendors. You need to build up yours. > > Thanks, > Leo > > > On 03/16/2017 10:07 PM, THIRY, Jean-Luc wrote: >> Hi, >> >> I am a new subscriber to the i18n-dev list. >> Currently I have to organize the localization of a big java application that has been developed for 15 years using 2 types of java resources to manage localization : >> >> - .properties files used with resource bundles for common tags in forms, messages and java enums >> >> - data collected in SQL tables for dynamic enums >> >> As the application is big (property files with more than a 1700 entries) and a big number of enums (over 500), I have to find tools to automate the localization process knowing that the application has numerous new features added each year, features that we need to keep localized as we deliver new versions of the application. Theses resources are located in different jar's in the project which makes the data retrieval of all the .properties tedious. >> >> The process I have in mind has to detect new entries in the property files or in the database, extract these new labels in files so that I can transmit the information to a localization provider which in return can send me back the files with the labels localized. >> >> I have been looking for information on standards and I found XLIFF 1.0 and 2.0 interesting to manage the exchange process with the localization provider and I found java APIs to translate a .properties in a XLIFF file. >> The trouble is I have many things to code to have a full process operating so I have been looking also for other solutions. >> >> I found GNU getText well designed to manage localization of Linux projects. >> >> I would be interested in having more information on how to manage this knowing that you have exactly the same problem when you manage Localization of projects such as JDK or JRE. So how do you do this ? >> >> Thank's in advance, >> >> Cheers, >> Jean-Luc >> -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ramanand.patil at oracle.com Wed Mar 29 18:31:46 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 29 Mar 2017 11:31:46 -0700 (PDT) Subject: RFR: 8177449: (tz) Support tzdata2017b Message-ID: <26ddd555-b4ae-4afd-b0c8-34d2e2a31d0c@default> Hi all, Please review the latest TZDATA integration (tzdata2017b) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. From martinrb at google.com Wed Mar 29 18:34:46 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 Mar 2017 11:34:46 -0700 Subject: RFR: 8177449: (tz) Support tzdata2017b In-Reply-To: <26ddd555-b4ae-4afd-b0c8-34d2e2a31d0c@default> References: <26ddd555-b4ae-4afd-b0c8-34d2e2a31d0c@default> Message-ID: Looks good to me! On Wed, Mar 29, 2017 at 11:31 AM, Ramanand Patil wrote: > Hi all, > Please review the latest TZDATA integration (tzdata2017b) to JDK9. > Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 > Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ > > All the TimeZone related tests are passed after integration. > > Regards, > Ramanand. > From naoto.sato at oracle.com Wed Mar 29 20:00:47 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 29 Mar 2017 13:00:47 -0700 Subject: RFR: 8177449: (tz) Support tzdata2017b In-Reply-To: References: <26ddd555-b4ae-4afd-b0c8-34d2e2a31d0c@default> Message-ID: +1 Naoto On 3/29/17 11:34 AM, Martin Buchholz wrote: > Looks good to me! > > On Wed, Mar 29, 2017 at 11:31 AM, Ramanand Patil > wrote: > >> Hi all, >> Please review the latest TZDATA integration (tzdata2017b) to JDK9. >> Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 >> Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ >> >> All the TimeZone related tests are passed after integration. >> >> Regards, >> Ramanand. >> From ramanand.patil at oracle.com Thu Mar 30 06:53:49 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Wed, 29 Mar 2017 23:53:49 -0700 (PDT) Subject: RFR: 8177449: (tz) Support tzdata2017b In-Reply-To: References: <26ddd555-b4ae-4afd-b0c8-34d2e2a31d0c@default> Message-ID: <1ecc7508-dcd4-43a9-a1a1-62297c839ac3@default> Thank you Martin for the quick review. ? Regards, Ramanand. ? From: Martin Buchholz [mailto:martinrb at google.com] Sent: Thursday, March 30, 2017 12:05 AM To: Ramanand Patil Cc: i18n-dev at openjdk.java.net; core-libs-dev Subject: Re: RFR: 8177449: (tz) Support tzdata2017b ? Looks good to me! ? On Wed, Mar 29, 2017 at 11:31 AM, Ramanand Patil wrote: Hi all, Please review the latest TZDATA integration (tzdata2017b) to JDK9. Bug: https://bugs.openjdk.java.net/browse/JDK-8177449 Webrev: http://cr.openjdk.java.net/~rpatil/8177449/webrev.00/ All the TimeZone related tests are passed after integration. Regards, Ramanand. ? From naoto.sato at oracle.com Thu Mar 30 21:10:31 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 30 Mar 2017 14:10:31 -0700 Subject: [8u] RFR: 8177776: Create an equivalent test case for JDK9's SupplementalJapaneseEraTest Message-ID: <69774039-1980-882f-2f89-fac194fd7fa7@oracle.com> Hello, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8177776 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8177776/webrev.00/ This is for backporting fixes for JapaneseEra related issues (8054214, 8173423). The original fixes in JDK9 included a test case, SupplementalJapaneseEraTest which is intended for the system property testing. The above proposed fix intends to adapt that test case into JDK8, where calendars.properties file is used instead of the system property. The test is pretty much identical to JDK9's. The difference is to deal with the calendars.properties file and removed some non-applicable cases in JDK8. Naoto