[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