Hi Naoto,
The fix looks fine.
The direction for new tests is to give them functional names, not bugids.
Is there a suitable name?
CalendarDataUtility.java: 260; the assert is just documentation right?
Its rare to see asserts enabled except in test contexts.
Thanks, Roger
On 2/20/19 5:54 PM,
Thanks, Nishit.
I'd still like to ask for a review from a Reviewer.
Naoto
On 2/20/19 12:33 AM, Nishit Jain wrote:
Hi Naoto,
Thanks for the explanation. Change looks fine to me.
Regards,
Nishit Jain
On 19-02-2019 22:51, Naoto Sato wrote:
Hi Nishit,
The reason is that "US" is the only requir
Hi Naoto,
Thanks for the explanation. Change looks fine to me.
Regards,
Nishit Jain
On 19-02-2019 22:51, Naoto Sato wrote:
Hi Nishit,
The reason is that "US" is the only required locale in the JDK (cf.
Locale.getAvailableLocales(). In fact, initially I supplied "001" with
it, as it means the
Hi Nishit,
The reason is that "US" is the only required locale in the JDK (cf.
Locale.getAvailableLocales(). In fact, initially I supplied "001" with
it, as it means the "world" in CLDR, but it broke some existing tests.
"001" returns "MONDAY" as the first day of week, whereas "SUNDAY" in US.
Hi Naoto,
Why is the default region set to "US" if there is no region specified in
the locale? is this the default behavior of "first day of week" and
"minimal days in first week" when a region is missing or the default
behavior is that it returns "1"? Can't we just return "1" instead of
sett
Hello,
Please review the fix to the following issue:
https://bugs.openjdk.java.net/browse/JDK-8218960
The proposed changeset is located at:
http://cr.openjdk.java.net/~naoto/8218960/webrev.00/
The CONFIG message was generated because CLDRCalendarDataProviderImpl
was returning null for locale