Recent releases of the JDK include enhancements to the internationalization process to support updated standards.
Internationalization Enhancements in JDK 11
Internationalization enhancements for JDK 11 include:
Internationalization Enhancements in JDK 10
Internationalization enhancements for JDK 10 include:
Additional Unicode Language-Tag Extensions
The IETF BCP (best current practice) 47 language tags standard, which has been supported in the Locale class since Java SE 7, includes a Unicode extension subtag. As of Java SE 9, only the
-ca (calendar) and
-nu (number) extensions are supported.
Java SE 10 added support for the following additional extensions in the relevant JDK classes:
-fw(first day of week)
Since JDK 10, if an application specifies a locale of
en-US-u-cu-EUR, which means US English with Euro currency, java.util.Currency.getInstance(locale) instantiates a Euro
Currency. If the locale is
en-US-u-cu-JPY, a Japanese Yen
Currency is instantiated.
Internationalization Enhancements in JDK 9
Internationalization enhancements for Oracle Java Development Kit 9 include:
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 since JDK 9.
There are four distinct sources for locale data, identified by the following keywords:
CLDRrepresents the locale data provided by the Unicode CLDR project.
HOSTrepresents 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.
SPIrepresents the locale-sensitive services implemented by the installed Service Provider Interface (SPI) providers.
COMPATrepresents the locale data that is compatible with releases prior to JDK 9.
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
For supported locales, use the search field on the Technical Resources from Oracle page and search for "Supported Locales" See java.util.spi.LocaleServiceProvider API specification for the related API.
UTF-8 Properties Files
Since 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.
Convert the properties file into UTF-8 encoding.
Specify the runtime system property for the properties file's encoding, as in this example: