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

[naoto.sato at oracle.com]

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
>