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

Severin Gehwolf sgehwolf at redhat.com
Fri Jul 5 16:52:06 UTC 2019


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.

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.

> 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?

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?

Thanks,
Severin

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



More information about the jdk8u-dev mailing list