<i18n dev> [9] RFR: 8048123: Replace calendars.properties with another mechanism to specify a new Japanese calendar era

[Masayoshi Okutsu]

I've renamed the test programs and added a test case for java.time. 
While I was adding the test case, I found JapaneseEra.getDisplayName 
doesn't work with an additional era (JDK-8054214). I've already fixed 
it, but the fix will be pushed separately later.

No other changes in this webrev.

http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.02/

Thanks,
Masayoshi

On 7/31/2014 11:16 PM, Masayoshi Okutsu wrote:
> I've decided to follow the current spec -- ignoring any invalid 
> property values. This way applications can still run without removing 
> the property even after installing a fixed update release.
>
> Thanks,
> Masayoshi
>
> On 7/24/2014 9:35 AM, Masayoshi Okutsu wrote:
>> The expected property usage, which hasn't changed from the properties 
>> file, is that we will provide the correct property value of any new 
>> era probably with a test program which will verify the given values. 
>> For JDK 6 to 8, the updated property file will need to be provided by 
>> us with a test program. I don't expect that users regularly and 
>> randomly define their own eras. The Japanese government defines eras 
>> by decrees [1][2].
>>
>> I could change the spec, which requires another CCC cycle, and add 
>> error logging. But I believe that's overkill for the functionality 
>> and its usage (basically only once every several ten years for the 
>> limited number of users). In addition, the syntax isn't complicated 
>> at all. And if any wrong values are given, such as a typo in the 
>> given name, there will be no way to detect it in the API anyway.
>>
>> BTW, I tend to avoid use of logging (and some other APIs) in the 
>> date-time API. It could create inter dependencies leading to an 
>> infinite loop to use some APIs from the date-time API. IIRC Sherman 
>> and I have worked on such bug reports. It's far more difficult to 
>> diagnose inter dependencies than syntax errors of the simple property 
>> value.
>>
>> If it's necessary to report any syntax errors, I think throwing an 
>> exception should be a solution. So, should I start over from the spec?
>>
>> Thanks,
>> Masayoshi
>>
>> [1] http://law.e-gov.go.jp/htmldata/S64/S64SE001.html
>> [2] 
>> http://www.mext.go.jp/b_menu/hakusho/nc/k19890107001/k19890107001.html
>>
>> On 7/24/2014 1:44 AM, Naoto Sato wrote:
>>> Although I believe the incorrect behavior would be very obvious 
>>> ("era" specified in the property would simply be not used), I would 
>>> agree the failed property be better logged.
>>>
>>> Naoto
>>>
>>> On 7/23/14, 6:23 AM, Alan Bateman wrote:
>>>> On 23/07/2014 09:46, Masayoshi Okutsu wrote:
>>>>> Revised the webrev:
>>>>> http://cr.openjdk.java.net/~okutsu/9/8048123/webrev.01
>>>>>
>>>>> The changes from the previous one are:
>>>>> - Changed <pre><code> (originally <pre><tt>) to <pre>{@code
>>>>> - Replaced StringTokenizer with String.split()
>>>>> - Eliminated RuntimeException
>>>> The use of {@code ..} and replacing the usage of StringTokenizer look
>>>> good me.
>>>>
>>>> I'm not so sure about silently ignoring errors in the property value,
>>>> mostly because it would lead to incorrect behavior that is likely 
>>>> to be
>>>> very difficult to track down. If there area used logging then there
>>>> might be some hope of finding it but this isn't the case.
>>>>
>>>> -Alan
>>
>