[11] RFR: 8202088: Japanese new era implementation
Hi, Please review the changes to the subject issue: https://bugs.openjdk.java.net/browse/JDK-8202088 The proposed change is located at: http://cr.openjdk.java.net/~naoto/8202088/webrev.01/ This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review: https://bugs.openjdk.java.net/browse/JDK-8202336 Naoto
The java.time change seems OK to me Stephen On 17 May 2018 at 21:31, Naoto Sato <naoto.sato@oracle.com> wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Hi Naoto, Is there a reference to the official description or anticipation of the new Era? JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.) Syntax style: - TCKJapaneseChronology:692: align the columns of decimal values. - TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes. Regards, Roger On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Hi Roger, thank you for the comments. On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era?
AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.)
I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes.
Fixed as suggested. The updated webrev is here: http://cr.openjdk.java.net/~naoto/8202088/webrev.02/ Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Found an issue on retrieving the localized era name for java.util.Calendar. The reason is that even we provide the l10n in our own resource bundles, the current CLDR does not provide the name (duh!). Added a fallback to COMPAT provider in such a case. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8202088/webrev.03/ Naoto On 5/18/18 3:26 PM, naoto.sato@oracle.com wrote:
Hi Roger, thank you for the comments.
On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era?
AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.)
I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes.
Fixed as suggested. The updated webrev is here:
http://cr.openjdk.java.net/~naoto/8202088/webrev.02/
Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Hi Naoto, Looks good, editorial comments: src/jdk.localedata/share/classes/sun/text/resources/ext/FormatData_ja.java - update copyright test/jdk/java/time/tck/java/time/chrono/TCKJapaneseChronology.java: 374 - missing space in "4+ YDIFF_HEISEI"... Thanks, Roger On 5/24/2018 11:45 AM, Naoto Sato wrote:
Found an issue on retrieving the localized era name for java.util.Calendar. The reason is that even we provide the l10n in our own resource bundles, the current CLDR does not provide the name (duh!). Added a fallback to COMPAT provider in such a case.
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8202088/webrev.03/
Naoto
On 5/18/18 3:26 PM, naoto.sato@oracle.com wrote:
Hi Roger, thank you for the comments.
On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era?
AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.)
I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes.
Fixed as suggested. The updated webrev is here:
http://cr.openjdk.java.net/~naoto/8202088/webrev.02/
Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
src/java.base/share/classes/sun/text/resources/FormatData.java @@ -106,6 +106,7 @@ "T", "S", "H", + "N", // New Era }; How about changing the comment to NewEra? When the name is available you can use grep to locate all places that need updates. BTW, why must 8202088 be pushed before Apr 2019? If someone try to show the Japanese calendar date of a day in 2020 now, do you really expect them to see "NewEra year 2"? (or something like it, I am not sure). Thanks Max
On May 24, 2018, at 11:45 PM, Naoto Sato <naoto.sato@oracle.com> wrote:
Found an issue on retrieving the localized era name for java.util.Calendar. The reason is that even we provide the l10n in our own resource bundles, the current CLDR does not provide the name (duh!). Added a fallback to COMPAT provider in such a case.
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8202088/webrev.03/
Naoto
On 5/18/18 3:26 PM, naoto.sato@oracle.com wrote:
Hi Roger, thank you for the comments. On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era? AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.) I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes. Fixed as suggested. The updated webrev is here: http://cr.openjdk.java.net/~naoto/8202088/webrev.02/ Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Thanks for the review, Roger and Max. I modified the webrev according to your suggestions. Also, from an internal comment, I added a test case (Bug8202088.java) for the modification below. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8202088/webrev.04/ Max, --- BTW, why must 8202088 be pushed before Apr 2019? If someone try to show the Japanese calendar date of a day in 2020 now, do you really expect them to see "NewEra year 2"? (or something like it, I am not sure). --- I think so, given that they understand "NewEra" is a placeholder. Actually it was requested by customers that we implement the era way before the actual transition so that their applications should have been tested accordingly with the new era ahead of time (let alone we need to backport it to jdk8u/etc. lines) Naoto On 5/24/18 8:45 AM, Naoto Sato wrote:
Found an issue on retrieving the localized era name for java.util.Calendar. The reason is that even we provide the l10n in our own resource bundles, the current CLDR does not provide the name (duh!). Added a fallback to COMPAT provider in such a case.
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8202088/webrev.03/
Naoto
On 5/18/18 3:26 PM, naoto.sato@oracle.com wrote:
Hi Roger, thank you for the comments.
On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era?
AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.)
I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes.
Fixed as suggested. The updated webrev is here:
http://cr.openjdk.java.net/~naoto/8202088/webrev.02/
Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
Hi Naoto, test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java: 125 missing spaces around "+". Please rename the test to have functional name. (test/jdk/java/util/Calendar/Bug8202088.java) We're trying to get away for uninformative bug numbers for tests. No further review from me needed with those changes. Thanks, Roger On 5/25/18 4:13 PM, naoto.sato@oracle.com wrote:
Thanks for the review, Roger and Max. I modified the webrev according to your suggestions. Also, from an internal comment, I added a test case (Bug8202088.java) for the modification below. Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8202088/webrev.04/
Max,
--- BTW, why must 8202088 be pushed before Apr 2019? If someone try to show the Japanese calendar date of a day in 2020 now, do you really expect them to see "NewEra year 2"? (or something like it, I am not sure). ---
I think so, given that they understand "NewEra" is a placeholder. Actually it was requested by customers that we implement the era way before the actual transition so that their applications should have been tested accordingly with the new era ahead of time (let alone we need to backport it to jdk8u/etc. lines)
Naoto
On 5/24/18 8:45 AM, Naoto Sato wrote:
Found an issue on retrieving the localized era name for java.util.Calendar. The reason is that even we provide the l10n in our own resource bundles, the current CLDR does not provide the name (duh!). Added a fallback to COMPAT provider in such a case.
Here is the updated webrev:
http://cr.openjdk.java.net/~naoto/8202088/webrev.03/
Naoto
On 5/18/18 3:26 PM, naoto.sato@oracle.com wrote:
Hi Roger, thank you for the comments.
On 5/18/18 11:11 AM, Roger Riggs wrote:
Hi Naoto,
Is there a reference to the official description or anticipation of the new Era?
AFAIK, the most recent information was for Japanese Govt. to announce the new era name one month prior to the ascension. This is indeed the reason I decided to introduce the placeholder.
JapaneseImperialCalendar: 134 NEWERA = 5; (The real name can also be defined later; but still might be more unique as ERA_MAY_1_2019.)
I wanted to keep the name "NEWERA" for the convenience when they are to be replaced with the real name. I changed the access modifier to "private", though.
Syntax style:
- TCKJapaneseChronology:692: align the columns of decimal values.
- TestJapaneseChronology:61-62: space before the '}' brackets :89: extra space before '}' // inconsistent within the file but local consistency is good
TestUmmAlQuraChronology: there might be test dates that would not require more changes later when the era name changes.
Fixed as suggested. The updated webrev is here:
http://cr.openjdk.java.net/~naoto/8202088/webrev.02/
Naoto
Regards, Roger
On 5/17/18 4:31 PM, Naoto Sato wrote:
Hi,
Please review the changes to the subject issue:
https://bugs.openjdk.java.net/browse/JDK-8202088
The proposed change is located at:
http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
This is the implementation part of the upcoming Japanese new era, starting from May 1st, 2019. Current anticipation is that the new name won't be known till one month prior to the beginning of the era. So it's not possible to make changes to the JDK with the proper name. Instead, here we are going to implement the new era with a place holder name which will be immediately replaced with the proper name once it's known. The CSR is currently under review:
https://bugs.openjdk.java.net/browse/JDK-8202336
Naoto
participants (5)
-
Naoto Sato
-
naoto.sato＠oracle.com
-
Roger Riggs
-
Stephen Colebourne
-
Weijun Wang