COMPAT locale provider will be removed in a future release

[dbwiddis]

From https://bugs.openjdk.org/browse/JDK-8305402

COMPAT locale provider has remained to keep the backward compatibility of JDK 8's locale data, since CLDR-based locale data became the default in JDK 9. The intention was to encourage applications to migrate to CLDR, so for future removal of the COMPAT locale provider, acknowledging the user of future removal is recommended.

To Reproduce
Steps to reproduce the behavior:

1. Run tests on a plugin using JDK 21
2. Observe multiple warnings:

> Task :test
Dec 09, 2023 12:30:31 PM sun.util.locale.provider.LocaleProviderAdapter <clinit>
WARNING: COMPAT locale provider will be removed in a future release

Expected behavior
No warnings.

Plugins

Error occurs when testing any plugin which inherits from OpenSearchTestBasePlugin

Host/Environment (please complete the following information):

• OS: macOS 14.1.2 (aarch64)
• JDK Version 21.0.1

Additional context

The locale is set here:

OpenSearch/buildSrc/src/main/java/org/opensearch/gradle/OpenSearchTestBasePlugin.java

Line 113 in 3c14cc1

test.systemProperty("java.locale.providers", "SPI,COMPAT");

The fix is to simply replace COMPAT with CLDR. Some tests will break and will need to be fixed.

Note that the "breaking change" here was the JDK default behavior, so this only breaks our tests which explicitly set COMPAT, overriding the default JDK. SO this should be safe to backport.

CLDR is supported since JDK11: https://www.oracle.com/java/technologies/javase/jdk11-suported-locales.html

[peternied]

[Triage - attendees 1 2 3 4]
@dbwiddis Thanks for filing this issue.

Before backporting this to 2.x please be sure that isn't a breaking change, as it looks like it could be.

[dbwiddis]

@peternied Good call-out. I did research and this is a breaking change in terms of output format, so should be 3.x only.

@hurutoriya I see you got started on a PR for this. Will you be updating that?

[dbwiddis]

@peternied Looked at this again, I don't think it's a breaking change.

The actual breaking change was in upgrading JDK8 to any later JDK. We explicitly set the locale in our tests to enforce the older behavior. So this only breaks tests, and anyone already using a later JDK than 8 either has updated to the new code, or is explicitly setting COMPAT themselves.

[akolarkunnu]

@peternied Can you please assign this bug to me, I identified fix for this.

[peternied]

@peternied Can you please assign this bug to me, I identified fix for this.

@akolarkunnu Done, thanks for taking it on!

[akolarkunnu]

@dbwiddis You mentioned in this bug description that, configuration of COMPAT locale provider only in the file OpenSearch/buildSrc/src/main/java/org/opensearch/gradle/OpenSearchTestBasePlugin.java. But COMPAT configurations exists in the other files too, listed below:
./distribution/tools/launchers/src/main/java/org/opensearch/tools/launchers/SystemJvmOptions.java
./gradle/ide.gradle
./server/src/internalClusterTest/java/org/opensearch/search/query/SearchQueryIT.java

I feel we have to remove COMPAT locale provider from these files also for java versions > JavaVersion.VERSION_1_8.

Shall we address all these places together in this bug or handle each one separately?

Your opinion please.

[andrross]

@akolarkunnu Yeah I think we should handle it in all places. Seems reasonable to take care of all of them at the same time, assuming the fix doesn't grow too large.

[reta]

Reopening the issue, the change introduced new flaky tests and was reverted: #14039

[akolarkunnu]

Reopening the issue, the change introduced new flaky tests and was reverted: #14039

Is it a random failure or consistent in CI ? If it happened multiple times, can I get that multiple error traces ?

I ran it locally and it passes consistently.

From error log, "UTC" is replaced with "م ع و" . It looks like some synchronization or threading issue from test side.

[reta]

Is it a random failure or consistent in CI ? If it happened multiple times, can I get that multiple error traces ?

It is all provided in the description of #14039:

./gradlew ':server:test' --tests "org.opensearch.common.joda.JavaJodaTimeDuellingTests.testIncompatiblePatterns" -Dtests.seed=D64AD5330C8A32D4

./gradlew ':server:test' --tests "org.opensearch.common.joda.JavaJodaTimeDuellingTests.testIncompatiblePatterns" -Dtests.seed=5593D79ECB158B24

[akolarkunnu]

A simple reproducer of this issue:

import java.util.Locale;
import org.joda.time.DateTime;
import org.joda.time.format.DateTimeFormat;

public class TestClass {
public static void main(String[] args) {
System.setProperty("java.locale.providers", "SPI,CLDR");
DateTime dateTime = DateTimeFormat.forPattern("YYYY-MM-dd'T'HH:mm:ss.SSSZ")
.withOffsetParsed()
.parseDateTime("2019-01-01T01:01:01.001+0000");
String jodaZoneId = DateTimeFormat.forPattern("YYYY-MM-dd'T'HH:mm:ss.SSSz")
.withLocale(Locale.forLanguageTag("sd-Arab")).print(dateTime);
System.out.println("jodaZoneId: " + jodaZoneId);
}
}

[reta]

@akolarkunnu I would like to point out this is not a single case - there are other failing combinations.

[akolarkunnu]

@reta Can you please share the details.

[reta]

@reta Can you please share the details.

2 are above, for others - run ./gradlew ':server:test' --tests "org.opensearch.common.joda.JavaJodaTimeDuellingTests.testIncompatiblePatterns" repeatably to have more seeds tested

[akolarkunnu]

@reta Can you please share the details.

2 are above, for others - run ./gradlew ':server:test' --tests "org.opensearch.common.joda.JavaJodaTimeDuellingTests.testIncompatiblePatterns" repeatably to have more seeds tested

ok, that means the same test case fails for different time zones, that's expected. Any other test cases or use cases are affected?

[reta]

Any other test cases or use cases are affected?

I don't know at this moment

[akolarkunnu]

I reported a bug against OpenJDK about this behavioral change(https://bugs.openjdk.org/browse/JDK-8334225) and their explanation is:
"CLDR v45 has the following translation of "Etc/UTC" (an alias to "UTC") zone in Sindhi language:
https://unicode.org/cldr/charts/45/summary/sd.html#4c4fea4c1e106866
Thus the behavior is the expected one."

So I will adjust the test case assertion accordingly.