: 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
