[11] RFR: 8202088: Japanese new era implementation

Roger Riggs roger.riggs at oracle.com
Fri Jun 8 14:04:26 UTC 2018


Hi Naoto,

test/jdk/java/util/Calendar/SupplementalJapaneseEraTest.java: 125 
missing spaces around "+".

Please rename the test to have functional name. 
(test/jdk/java/util/Calendar/Bug8202088.java)
We're trying to get away for uninformative bug numbers for tests.

No further review from me needed with those changes.

Thanks, Roger


On 5/25/18 4:13 PM, naoto.sato at oracle.com wrote:
> Thanks for the review, Roger and Max. I modified the webrev according 
> to your suggestions. Also, from an internal comment, I added a test 
> case (Bug8202088.java) for the modification below. Here is the updated 
> webrev:
>
> http://cr.openjdk.java.net/~naoto/8202088/webrev.04/
>
> Max,
>
> ---
> BTW, why must 8202088 be pushed before Apr 2019? If someone try to 
> show the Japanese calendar date of a day in 2020 now, do you really 
> expect them to see "NewEra year 2"? (or something like it, I am not 
> sure).
> ---
>
> I think so, given that they understand "NewEra" is a placeholder. 
> Actually it was requested by customers that we implement the era way 
> before the actual transition so that their applications should have 
> been tested accordingly with the new era ahead of time (let alone we 
> need to backport it to jdk8u/etc. lines)
>
> Naoto
>
> On 5/24/18 8:45 AM, Naoto Sato wrote:
>> Found an issue on retrieving the localized era name for 
>> java.util.Calendar. The reason is that even we provide the l10n in 
>> our own resource bundles, the current CLDR does not provide the name 
>> (duh!). Added a fallback to COMPAT provider in such a case.
>>
>> Here is the updated webrev:
>>
>> http://cr.openjdk.java.net/~naoto/8202088/webrev.03/
>>
>> Naoto
>>
>> On 5/18/18 3:26 PM, naoto.sato at oracle.com wrote:
>>> Hi Roger, thank you for the comments.
>>>
>>> On 5/18/18 11:11 AM, Roger Riggs wrote:
>>>> Hi Naoto,
>>>>
>>>> Is there a reference to the official description or anticipation of 
>>>> the new Era?
>>>
>>> AFAIK, the most recent information was for Japanese Govt. to 
>>> announce the new era name one month prior to the ascension. This is 
>>> indeed the reason I decided to introduce the placeholder.
>>>
>>>>
>>>> JapaneseImperialCalendar: 134 NEWERA = 5;   (The real name can also 
>>>> be defined later; but still might be more unique as ERA_MAY_1_2019.)
>>>
>>> I wanted to keep the name "NEWERA" for the convenience when they are 
>>> to be replaced with the real name. I changed the access modifier to 
>>> "private", though.
>>>
>>>>
>>>> Syntax style:
>>>>
>>>>   - TCKJapaneseChronology:692: align the  columns of decimal values.
>>>>
>>>>   - TestJapaneseChronology:61-62: space before the '}' brackets
>>>>      :89: extra space before '}'  //  inconsistent within the file 
>>>> but local consistency is good
>>>>
>>>> TestUmmAlQuraChronology: there might be test dates that would not 
>>>> require more changes later when the era name changes.
>>>
>>> Fixed as suggested. The updated webrev is here:
>>>
>>> http://cr.openjdk.java.net/~naoto/8202088/webrev.02/
>>>
>>> Naoto
>>>
>>>>
>>>> Regards, Roger
>>>>
>>>>
>>>> On 5/17/18 4:31 PM, Naoto Sato wrote:
>>>>> Hi,
>>>>>
>>>>> Please review the changes to the subject issue:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202088
>>>>>
>>>>> The proposed change is located at:
>>>>>
>>>>> http://cr.openjdk.java.net/~naoto/8202088/webrev.01/
>>>>>
>>>>> This is the implementation part of the upcoming Japanese new era, 
>>>>> starting from May 1st, 2019. Current anticipation is that the new 
>>>>> name won't be known till one month prior to the beginning of the 
>>>>> era. So it's not possible to make changes to the JDK with the 
>>>>> proper name. Instead, here we are going to implement the new era 
>>>>> with a place holder name which will be immediately replaced with 
>>>>> the proper name once it's known. The CSR is currently under review:
>>>>>
>>>>> https://bugs.openjdk.java.net/browse/JDK-8202336
>>>>>
>>>>> Naoto
>>>>



More information about the core-libs-dev mailing list