Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
> On 30 Oct 2018, at 17:45, Naoto Sato 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.
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
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 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.
http://cr.openjdk.java.net/~naoto/8212941/webrev.03/
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
> On 30 Oct 2018, at 17:03, Roger Riggs 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.
>>
>> http://cr.openjdk.java.net/~naoto/8212941/webrev.03/
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
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.s...@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.s...@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
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
Updated the webrev. Please review. http://cr.openjdk.java.net/~naoto/8212941/webrev.03/ Naoto On 10/26/18 3:47 PM, naoto.s...@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.s...@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
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
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.s...@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
Re: [12] RFR: 8212941: Loosen the range of JapaneseEra
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.s...@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
[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
