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

[Masayoshi Okutsu]

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
>