[12] RFR: 8212941: Loosen the range of JapaneseEra
Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8212941 The proposed fix and CSR (not approved yet) are located at: http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942 This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases. Naoto
Hi Naoto, I'd like to see a bit some discussion up front about the expected evolution of this class. For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. " Once a formal name is added for the new era, will that value be serial equivalent to the current new era value being used in the class? Basically, is the name or the int value the basis of the serial identity of a JapaneseEra object? Thanks, -Joe On 10/26/2018 2:00 PM, naoto.sato@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8212941
The proposed fix and CSR (not approved yet) are located at:
http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942
This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases.
Naoto
Hi Joe, On 10/26/18 3:00 PM, joe darcy wrote:
Hi Naoto,
I'd like to see a bit some discussion up front about the expected evolution of this class.
For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. "
Thanks. Those will clarify the intention of the change more. Will incorporate them.
Once a formal name is added for the new era, will that value be serial equivalent to the current new era value being used in the class? Basically, is the name or the int value the basis of the serial identity of a JapaneseEra object?
Yes to the former question. The "NewEra" era should be equivalent to what's coming after the name is decided. Thus the int value should be the sole identity for the designated era. This will ensure the maintenance releases which cannot backport public singleton instances work without spec change. Naoto
Thanks,
-Joe
On 10/26/2018 2:00 PM, naoto.sato@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8212941
The proposed fix and CSR (not approved yet) are located at:
http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942
This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases.
Naoto
Updated the webrev. Please review. http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ Naoto On 10/26/18 3:47 PM, naoto.sato@oracle.com wrote:
Hi Joe,
On 10/26/18 3:00 PM, joe darcy wrote:
Hi Naoto,
I'd like to see a bit some discussion up front about the expected evolution of this class.
For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. "
Thanks. Those will clarify the intention of the change more. Will incorporate them.
Once a formal name is added for the new era, will that value be serial equivalent to the current new era value being used in the class? Basically, is the name or the int value the basis of the serial identity of a JapaneseEra object?
Yes to the former question. The "NewEra" era should be equivalent to what's coming after the name is decided. Thus the int value should be the sole identity for the designated era. This will ensure the maintenance releases which cannot backport public singleton instances work without spec change.
Naoto
Thanks,
-Joe
On 10/26/2018 2:00 PM, naoto.sato@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8212941
The proposed fix and CSR (not approved yet) are located at:
http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942
This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases.
Naoto
Hi Naoto, Looks fine. The wording should allow future Japanese era to be defined without the timing being tightly coupled to java specification updates. Thanks, Roger On 10/30/2018 12:29 PM, Naoto Sato wrote:
Updated the webrev. Please review.
http://cr.openjdk.java.net/~naoto/8212941/webrev.03/
Naoto
On 10/26/18 3:47 PM, naoto.sato@oracle.com wrote:
Hi Joe,
On 10/26/18 3:00 PM, joe darcy wrote:
Hi Naoto,
I'd like to see a bit some discussion up front about the expected evolution of this class.
For example, "once an era is defined, subsequent versions of the API will add a constant for it. etc. Eras are expected to have consecutive integers associated with them, etc. "
Thanks. Those will clarify the intention of the change more. Will incorporate them.
Once a formal name is added for the new era, will that value be serial equivalent to the current new era value being used in the class? Basically, is the name or the int value the basis of the serial identity of a JapaneseEra object?
Yes to the former question. The "NewEra" era should be equivalent to what's coming after the name is decided. Thus the int value should be the sole identity for the designated era. This will ensure the maintenance releases which cannot backport public singleton instances work without spec change.
Naoto
Thanks,
-Joe
On 10/26/2018 2:00 PM, naoto.sato@oracle.com wrote:
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8212941
The proposed fix and CSR (not approved yet) are located at:
http://cr.openjdk.java.net/~naoto/8212941/webrev.02/ https://bugs.openjdk.java.net/browse/JDK-8212942
This change is intended to loosen the spec of JapaneseEra so that later era additions won't require unnecessary spec changes. This is particularly important for the maintenance releases.
Naoto
On 30 Oct 2018, at 17:03, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Hi Naoto,
Looks fine. The wording should allow future Japanese era to be defined without the timing being tightly coupled to java specification updates.
+1 Suggest: "The defined ** era’s {@link #getValue} ** is expected to have a consecutive integer associated with it.” I suspect that the wording here has deliberately chosen, but I wonder if it could be tightened a little? `values()` should return an array of eras whose values are in a contiguous range, no? If so, can this be specified? -Chris.
Thanks, Roger
On 10/30/2018 12:29 PM, Naoto Sato wrote:
Updated the webrev. Please review.
Hi Chris, Thank you for the review. On 10/30/18 10:33 AM, Chris Hegarty wrote:
On 30 Oct 2018, at 17:03, Roger Riggs <Roger.Riggs@oracle.com> wrote:
Hi Naoto,
Looks fine. The wording should allow future Japanese era to be defined without the timing being tightly coupled to java specification updates.
+1
Suggest: "The defined ** era’s {@link #getValue} ** is expected to have a consecutive integer associated with it.”
I suspect that the wording here has deliberately chosen, but I wonder if it could be tightened a little?
`values()` should return an array of eras whose values are in a contiguous range, no? If so, can this be specified?
Yes, both of those are valid points. I have already pushed the change, as the CSR has been approved, I will consider modifying the wording according to your suggestion in the future. Naoto
-Chris.
Thanks, Roger
On 10/30/2018 12:29 PM, Naoto Sato wrote:
Updated the webrev. Please review.
On 30 Oct 2018, at 17:45, Naoto Sato <naoto.sato@oracle.com> wrote:
.. Suggest: "The defined ** era’s {@link #getValue} ** is expected to have a consecutive integer associated with it.” I suspect that the wording here has deliberately chosen, but I wonder if it could be tightened a little? `values()` should return an array of eras whose values are in a contiguous range, no? If so, can this be specified?
Yes, both of those are valid points. I have already pushed the change, as the CSR has been approved, I will consider modifying the wording according to your suggestion in the future.
No problem, just some minor points to consider. -Chris.
participants (5)
-
Chris Hegarty
-
joe darcy
-
Naoto Sato
-
naoto.sato＠oracle.com
-
Roger Riggs