I am not sure if this is 100% true,
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. 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 we should fix the test to use CLDR for its input strings (maybe
format the date once using the new rules and copypaste it into the
test). Those 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.
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.
Uwe
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
