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

[Masayoshi Okutsu]

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