<i18n dev> [12] RFR: 8212941: Loosen the range of JapaneseEra

[Naoto Sato]

Updated the webrev. Please review.

http://cr.openjdk.java.net/~naoto/8212941/webrev.03/

Naoto

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.
> 
> Naoto
> 
>>
>> Thanks,
>>
>> -Joe
>>
>>
>> On 10/26/2018 2:00 PM, naoto.sato at 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
>>