: Yes, JDK 9 changed the default provider to be the compat one, but Java 21 : should already default to the CLDR. But maybe theres a difference in parsing.
Mmmm, I think you're mistaken somewhere ... jdk9, jdk11, jdk17, and jdk21 all say the default behavior is the same... >> The default order for looking up the preferred locale providers is >> "CLDR,COMPAT" https://docs.oracle.com/javase/9/docs/api/java/util/spi/LocaleServiceProvider.html https://docs.oracle.com/en%2Fjava%2Fjavase%2F11%2Fdocs%2Fapi%2F%2F/java.base/java/util/spi/LocaleServiceProvider.html https://docs.oracle.com/en%2Fjava%2Fjavase%2F17%2Fdocs%2Fapi%2F%2F/java.base/java/util/spi/LocaleServiceProvider.html https://docs.oracle.com/en%2Fjava%2Fjavase%2F21%2Fdocs%2Fapi%2F%2F/java.base/java/util/spi/LocaleServiceProvider.html ...and yet, as I noted in SOLR-17379, the French test works fine using "java.locale.providers=CLDR" (no COMPAT at all) with jdk11 & jdk17 -- but fails using jdk21 : Maybe in JDK21 based on this system property it accepts both locales during : parsing, but formats to string using the primary one (CLDR). This would : explain why the test works in earlier versions: Parsing is more lenient. Round : trips would also have worked (it formats to new format, but parsing accepts : both). I think it works (by default) in older versions because of the COMPAT locale, but prior to jdk21 the CLDR Locale can also work. Suggesting it's impact by some change in the CLDR data between jdk17 and jdk21 : Not sure what's wrong with the French one, it does not fail on parsing, it : asserts later that the epoch millis fit the expected one and there seems to be : something wrong. No, the French problem is definitely failing in the parsing -- See the patch in SOLR-17379 -- I beefed up the logging and acording to the DateTimeParseException from DateTimeFormatter (Unless i'm horribly missunderstanding something) it doesn't want to recognize "vendredi" as a "Text(DayOfWeek)" which is weird because AFAICT it's in DateFormatSymbols.getInstance(new Locale("fr")).getWeekdays() even when restricting to only java.locale.providers=CLDR. : should work in all supported JDKs >=11. The test still asserts some JDK8 : behaviour, which cxannot be tested anymore. So it looks like the Alaska test : is broken from beginning. Yeah, i ripped that cruft out in my patch (based on the linked bug it looks like the claims about failing on jdk>8 were only true for some early 9-ea builds, not even the released buidls) : Am 24.07.2024 um 20:50 schrieb Chris Hostetter: : > : the reason for this looks like it is because of the legacy timezone : > database : > : was removed and only CLDR was left over. It looks like this test uses a : > : > Right, ok -- yes thank you for the links. Most of that info is over my : > head, but my main take aways are... : > : > 0) jdk8 (and earlier) had a single 'JRE' java.locale.providers : > 1) jdk9 added 'CLDR' as a provider & aliased COMPAT=JRE : > 2) jdk9 changed default == java.locale.providers=CLDR,COMPAT : > 3) jdk23 removed the COMPAT provider : > 4) jdk23 changed default == java.locale.providers=CLDR : > : > : Do we do anything like that (setting the COMPAT java.locale.providers : > system : > : property? I grepped through the reposity and have seen nothing to set the : > : legacy sysprop. : > : > We do not, and I don't think it would make sense for us to do that. : > : > : If this still proves to be a bug we can open an issue - I will look into : > this : > : later (we need a testcase to show the issue that works with JDK 22 and the : > : default JRE provider and fails with JDK-23). There could be 2 outcomes: : > : > I've confirmed that both tests fail using JDK21 if you specify : > '-Djava.locale.providers=CLDR' in our 'tests.jvmargs' They pass with both : > 'COMPAT,CLDR' or 'CLDR,COMPAT' : > : > So the problem is not "new" in jdk23-ea -- it's a situation where our : > tests expect behavior that is only available from the COMPAT local : > provider. : > : > In the case of testAKSTZone I can kind of understand why/how this might : > happen if that CLDR version of Locale.ROOT doesn't support parsing the : > "AKST" String as a TZ. : > : > I'm a little perplexed by the testParseFrenchDate failure ... I guess the : > parsing rules for french are just a little different in CLDR (but it's : > also hard to tell what exactly is going wrong based on where/how it fails : > the test) : > : > : > In either case -- it seems like the "correct" test fix is to introspect : > the JVM, and assume/skip the test if COMPAT is not in use. Ideally we : > should do this by checking behavior, and not explicitly inspecting the : > LocaleServiceProvider. In the case of testAKSTZone this hsould be easy to : > do if/when these exception is thrown (the place it's thrown is already : > introspecting teh JVM behavior w/o actually testing any solr code). Not : > sure what to do about testParseFrenchDate but I'll poke around and see if : > i can figure it out. : > : > : > : > -Hoss : > http://www.lucidworks.com/ : > : > --------------------------------------------------------------------- : > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org : > For additional commands, e-mail: dev-h...@solr.apache.org : > : -- : Uwe Schindler : Achterdiek 19, D-28357 Bremen : https://www.thetaphi.de : eMail: u...@thetaphi.de : : : --------------------------------------------------------------------- : To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org : For additional commands, e-mail: dev-h...@solr.apache.org : : -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
