RFR: [8u] JDK-8218781: Localized names for Japanese Era Reiwa in COMPAT provider

[Andrew John Hughes]

On 05/07/2019 17:52, Severin Gehwolf wrote:
> Hi Andrew,
> 
> On Fri, 2019-06-21 at 16:46 +0100, Andrew John Hughes wrote:
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8218781
>> Webrev: https://cr.openjdk.java.net/~andrew/openjdk8/8218781/webrev.01/
>>
>> OpenJDK 8u uses an older version of the CLDR data to 9, and is thus
>> missing a number of locale data files updated by the original version of
>> 8218781. Thus, some chunks are absent from the 8u backport.
> 
> Ugh, the JDK 13 fix got pushed via 8219781 :( No wonder I wasn't
> finding anything.
> 

Ah, so it wasn't a typo on my part in 8u.

> Hmm, there is no COMPAT provider in JDK 8u. That's JDK 9 onwards. See:
> https://bugs.openjdk.java.net/browse/JDK-8062006
> 
> In JDK 8u -Djava.locale.providers=COMPAT (as used in the test[1]) will
> result in the default list, which is JRE,SPI as far as I can see.
> 

Yes, it's effectively redundant. I guess we could remove it but it then
creates divergence.

>> In most cases, this actually makes no difference in testing, because the
>> locale data files for hr, in, lt, nl and sv simply duplicate the English
>> values. Thus, the only ones that fail the test are no (uses a short era
>> of "R") and sr_Latn ("Reiva").
> 
> Right, but why intentionally introduce test failures? I'm worried about
> signal vs. noise here.
> 
>> I propose that we apply 8218781 for the locales we have now, and look at
>> backporting updated CLDR data for 8u232 or 8u242. The updates -
>> primarily JDK-8008577 - are tied up with configuration changes which we
>> don't want to import to 8, so a backport will require some work and
>> significant testing.
>>
>> In short, please review this patch, taking into consideration that some
>> locales will be absent and that data is duplicated for others
>> (JDK-8159943, not in 8u, makes the short and long eras use a shared
>> variable where they are identical)
> 
> Have you considered something like this patch so as to avoid the test
> failures and then re-enable them once a fix comes in?
> 

That seems like a good way to make sure it doesn't get fixed.

> diff --git a/test/java/util/Calendar/JapanEraNameCompatTest.java b/test/java/util/Calendar/JapanEraNameCompatTest.java
> --- a/test/java/util/Calendar/JapanEraNameCompatTest.java
> +++ b/test/java/util/Calendar/JapanEraNameCompatTest.java
> @@ -96,12 +96,12 @@
>              { new Locale("hi", "IN"), HindiName, HindiName },
>              { new Locale("ru"), RussianName, RussianName },
>              { new Locale("sr"), SerbianName, SerbianName },
> -            { Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
> +            //{ Locale.forLanguageTag("sr-Latn"), SerbLatinName, SerbLatinName },
>              { new Locale("hr"), EngName, EngName },
>              { new Locale("in"), EngName, EngName },
>              { new Locale("lt"), EngName, EngName },
>              { new Locale("nl"), EngName, EngName },
> -            { new Locale("no"), EngName, "R" },
> +            //{ new Locale("no"), EngName, "R" },
>              { new Locale("sv"), EngName, EngName },
>              // el fallback to root
>              { new Locale("el"), EngName, EngName }
> 
> This would make it more apparent that it's intentional. Perhaps filing
> a bug that it's not a complete fix would be even better. Thoughts?
> 

As I said, the intention is to look at the viability of backporting the
updated CLDR data. There are already bugs for that.

> Thanks,
> Severin
> 
> [1] http://hg.openjdk.java.net/jdk8u/jdk8u/jdk/file/35818757a9c6/test/java/util/Calendar/JapanEraNameCompatTest.java#l29
> 

-- 
Andrew :)

Senior Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: ed25519/0xCFDA0F9B35964222 (hkp://keys.gnupg.net)
Fingerprint = 5132 579D D154 0ED2 3E04  C5A0 CFDA 0F9B 3596 4222
https://keybase.io/gnu_andrew