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

[Naoto Sato]

Looks good to me.

Naoto

On 8/6/14, 1:03 AM, Masayoshi Okutsu wrote:
> 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
>>>
>>
>