1 Internationalization Enhancements in JDK 9

Internationalization enhancements for Oracle Java Development Kit 9 include:

Unicode 8.0

Support has been added for Unicode 8.0. Java Platform, Standard Edition (Java SE) 8 supported Unicode 6.2.

The Unicode 6.3, 7.0, and 8.0 standards introduced 10,555 characters, 29 scripts, and 42 blocks, all of which are supported in Java SE 9.

CLDR Locale Data Enabled by Default

The XML-based locale data of the Unicode Common Locale Data Repository (CLDR), first added in JDK 8, is the default locale data in JDK 9. In previous releases, the default was JRE.

There are four distinct sources for locale data, identified by the following keywords:

  • CLDR represents the locale data provided by the Unicode CLDR project.

  • HOST represents the current user's customization of the underlying operating system's settings. It works only with the user's default locale, and the customizable settings may vary depending on the operating system. However, primarily date, time, number, and currency formats are supported.

  • SPI represents the locale-sensitive services implemented by the installed Service Provider Interface (SPI) providers.

  • COMPAT (formerly called JRE) represents the locale data that is compatible with releases prior to JDK 9. JRE can still be used as the value, but COMPAT is preferred.

To select a locale data source, use the java.locale.providers system property, listing the data sources in the preferred order. If a provider cannot offer the requested locale data, the search proceeds to the next provider in order. For example:


If you do not set this property, the default behavior is equivalent to the following setting:


To enable behavior that is compatible with JDK 8, set the java.locale.providers system property to a value with COMPAT to the left of CLDR.

See the JDK 9 and JRE 9 Supported Locales page for supported locales. See java.util.spi.LocaleServiceProvider API specification for the related API.

UTF-8 Properties Files

In Java SE 9, properties files are loaded in UTF-8 encoding. In previous releases, ISO-8859-1 encoding was used for loading property resource bundles. UTF-8 is a much more convenient way to represent non-Latin characters.

Most existing properties files should not be affected: UTF-8 and ISO-8859-1 have the same encoding for ASCII characters, and human-readable non-ASCII ISO-8859-1 encoding is not valid UTF-8. If an invalid UTF-8 byte sequence is detected, the Java runtime automatically rereads the file in ISO-8859-1.

If there is an issue, consider the following options:
  • Convert the properties file into UTF-8 encoding.

  • Specify the runtime system property for the properties file's encoding, as in this example:

See java.util.PropertyResourceBundle.