https://issues.apache.org/jira/browse/SOLR-17379
: Date: Wed, 24 Jul 2024 11:50:55 -0700 (MST) : From: Chris Hostetter <hossman_luc...@fucit.org> : To: dev@solr.apache.org : Subject: Re: [JENKINS-EA] Solr-main-Linux (64bit/hotspot/jdk-23-ea+33) - Build : # 19448 - Unstable! : : : : 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/ : -Hoss http://www.lucidworks.com/ --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org
