RFR: 8212941: Loosen the range of JapaneseEra
naoto.sato at oracle.com
Tue Oct 30 16:29:03 UTC 2018
Updated the webrev. Please review.
On 10/26/18 3:47 PM, naoto.sato at 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.
>> On 10/26/2018 2:00 PM, naoto.sato at oracle.com wrote:
>>> Please review the fix to the following issue:
>>> The proposed fix and CSR (not approved yet) are located at:
>>> 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.
More information about the core-libs-dev