Summary

Remove legacy locale data, known as COMPAT / JRE, from the JDK.

Problem

Legacy locale data has been in the JDK since version 1.1. It is known as the JRE locale data. SInce JDK 9, it has also been known as the COMPAT locale data.

The default locale data was switched in JDK 9 to CLDR, the de-facto standard from the Unicode Consortium. The legacy locale data continued to be available in JDK 9 and later, in order to enable migration by applications that relied on the legacy locale data. Developers could start their applications with java -Djava.locale.providers=JRE,CLDR ... or java -Djava.locale.providers=COMPAT,CLDR ... to force use of the legacy locale data ahead of the Unicode CLDR locale data.

The legacy locale data has not been actively maintained and is not capable of using recent features, such as Additional Date-Time Formats or Locale-Dependent List Patterns. Maintaining two sets of locale data is costly. By removing the legacy locale data, the JDK image size will be reduced by about 10 megabytes / 400+ classes.

Solution

Remove the legacy locale data from the JDK.

If JRE or COMPAT is requested at startup, e.g., java -Djava.locale.providers=JRE,CLDR ... or java -Djava.locale.providers=COMPAT,CLDR ..., it is ignored and treated as if it did not exist in the user's preferred locale data order. The Java runtime will issue a Logger.Level.WARNING message, alerting users to the removal of the JRE/COMPAT option. (By contrast, JDK 21 and 22 issue the message "COMPAT locale provider will be removed in a future release.", see JDK-8305402.)

Applications that rely on COMPAT will be affected by this change. There are example JBS issues listed in the Compatibility Risk section of this CSR. One workaround to address these incompatibilities is to provide their own SPI implementations. For example, in order to address JDK-8256837 where the short month name for September differs between CLDR and COMPAT in the UK locale, they could supply the following SPI implementation:

package spi;

import java.text.DateFormatSymbols;
import java.text.spi.DateFormatSymbolsProvider;
import java.util.Locale;

public class ShortMonthModifier extends DateFormatSymbolsProvider {
    @Override
    public DateFormatSymbols getInstance(Locale locale) {
        assert locale.equals(Locale.UK);
        return new DateFormatSymbols() {
            @Override
            public String[] getShortMonths() {

                var ret = new DateFormatSymbols(Locale.UK).getShortMonths().clone();

                ret[Calendar.SEPTEMBER] = "Sep";
                return ret;
            }
        };
    }

    @Override
    public Locale[] getAvailableLocales() {

        return new Locale[]{Locale.UK};
    }
}

Package it and place it on the class path, then invoke the JVM with -Djava.locale.providers=SPI,CLDR will workaround CLDR's Sept localization.

Specification

Modify the class description of java.util.spi.LocaleServiceProvider as:

  * <li> "CLDR": A provider based on Unicode Consortium's
  * <a href="http://cldr.unicode.org/">CLDR Project</a>.
- * <li> "COMPAT": represents the locale sensitive services that is compatible
- * with the prior JDK releases up to JDK 8 (same as JDK 8's "JRE"). This
- * provider is deprecated and will be removed in the future release of JDK.
  * <li> "SPI": represents the locale sensitive services implementing the subclasses of
  * this {@code LocaleServiceProvider} class.
  * <li> "HOST": A provider that reflects the user's custom settings in the
  * underlying operating system. This provider may not be available, depending
  * on the JDK Reference Implementation.
- * <li> "JRE": represents a synonym to "COMPAT". This name
- * is deprecated and will be removed in the future release of JDK.
  * </ul>
  * <p>
  * For example, if the following is specified in the property:
  * <pre>
- * java.locale.providers=SPI,CLDR,COMPAT
+ * java.locale.providers=SPI,CLDR
  * </pre>
  * the locale sensitive services in the SPI providers are looked up first. If the
- * desired locale sensitive service is not available, then the runtime looks for CLDR,
- * COMPAT in that order.
+ * desired locale sensitive service is not available, then the runtime looks for CLDR.
  * <p>
- * The default order for looking up the preferred locale providers is "CLDR,COMPAT",
- * so specifying "CLDR,COMPAT" is identical to the default behavior. Applications which
+ * The default order for looking up the preferred locale providers is "CLDR",
+ * so specifying "CLDR" is identical to the default behavior. Applications which
  * require implementations of the locale sensitive services must explicitly specify