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
