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