[Resend from the correct address…] Hi all,
For what it’s worth, CLDR itself doesn’t usually ‘backport’ data. (So there’s no CLDR source for such a backport.) I don’t know if CLDR has ever released a dot release for a release past the last released major version. FYI, For ICU, what we did (for a large number of releases) is a very specific spot fix of the locale data. - icu4j changes for 56.2 including binary data locale blob change: https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32 <https://github.com/unicode-org/icu/commit/b5999f7e7fa54c4f0fb9e9cd5e80095bb27eea32> - icu4c changes for 56.2 including textual changes to the intermediate format: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43> Example: https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384 <https://github.com/unicode-org/icu/commit/71763fa0419ab0205b50f3c0327f17d3d9a8cf43#diff-2990754f360524737be2791c1ab20e94R2384> ( change for Japanese ) -- Steven R. Loomis | @srl295 | git.io/srl295 > El jul. 5, 2019, a las 10:49 a. m., Andrew John Hughes > <gnu.and...@redhat.com> escribió: > > > > 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 >
