The set of supported locales varies between different
implementations of the Java Platform Standard Edition (Java SE) as
well as between different areas of functionality.
This page documents locale support in Oracle's Java SE
Development Kit 7 (JDK) and Java SE Runtime Environment 7
(JRE).
Oracle's Java SE Runtime Environment 7 for Windows may be
installed as a complete international version or as a European
languages version. The JRE installer by default installs a European
languages version if it recognizes that the host operating system
only supports European languages. If the installer recognizes that
any other language is needed, or if the user requests support for
non-European languages in a customized installation, a complete
international version is installed. The JRE for Solaris and Linux
and the JDK for any platform are always installed as complete
international versions.
Enabled Locales for
java.util and java.text Functionality
The support for locale-sensitive behavior in the java.util and
java.text packages is almost entirely platform independent, so all
locales are supported in the same way and simultaneously,
independent of the host operating system and its localization. The
only platform dependent functionality is the setting of the initial
default locale and the initial default time zone based on the host
operating system's locale and time zone.
Oracle's Java SE Development Kit 7 and the international
versions of the Java SE Runtime Environment 7 support all locales
shown below. The European languages version of the Java SE Runtime
Environment 7 supports all locales for the following languages:
Albanian, Belarusian, Bulgarian, Catalan, Croatian, Czech, Danish,
Dutch, English, Estonian, Finnish, French, German, Greek,
Hungarian, Icelandic, Indonesian, Italian, Latvian, Lithuanian,
Macedonian, Malay, Maltese, Norwegian, Polish, Portuguese,
Romanian, Russian, Serbian (Cyrillic), Slovak, Slovenian, Spanish,
Swedish, Turkish, Ukrainian.
(*) Data for these
locales are derived from the Unicode Consortium's Common Locale Data Repository
release 1.4.1 on an "AS-IS" basis.
Enabled Writing Systems for Java
Foundation Classes
Overview
For the Java Foundation Classes (AWT, Swing, 2D, input method
framework, drag and drop), locales can generally be characterized
by just the writing system; there are no country or language
specific distinctions. Writing system support in the JFC depends to
some extent on the host operating system, and full support for
simultaneous use of multiple languages is not always possible.
We consider a writing system supported by JFC if all
functionality provided by JFC works adequately for this writing
system in the following situations:
On Windows XP, 2003, Vista, and 7 when running on a Windows
system with both the user locale and the system locale set to a
language using that writing system.
On Solaris and Linux, when running on a host operating system
with the locale set to one using that writing system and one of the
encodings shown for that writing system in the table below.
Oracle's Java SE Development Kit 7 and the international version
of the Java SE Runtime Environment 7 support all writing systems
shown below. The European languages version of the Java SE Runtime
Environment 7 supports only the Cyrillic, Greek, and Latin writing
systems. Peered AWT components are only supported for a subset of
the writing systems - see the last column.
Details on various areas of functionality are provided in the
sections below.
English, French, German, Italian, Spanish, Swedish, etc.
1252
8859-1,
8859-15,
UTF-8
ISO-8859-1,
UTF-8
supported
Thai
Thai
874
TIS620.2533,
UTF-8
unsupported
unsupported
(1) eucJP on Solaris supports the
JIS character sets X 0201, X 0208, and X 0212.
Text Input
Support for text input consists of two parts: interpretation of
keyboard layouts, and text composition using input methods. For
interpretation of keyboard layouts, the Java SE relies entirely on
the host operating system. For text composition using input
methods, Java SE supports native input methods using the host
operating system's input method manager as well as input methods
developed in the Java programming language.
Locale support in input methods implemented in the Java
programming language depends solely on the set of installed input
methods, not on the host operating system and its localization.
However, support for the use of input methods implemented in the
Java programming language with peered components is implementation
dependent - see below.
Support for keyboard layouts and and native input methods varies
between platforms.
Windows
On Windows XP, 2003, Vista, and 7, the JRE supports use of any
keyboard layout or IMM-based input method.
Input methods implemented in the Java programming language are
supported in all components on all versions of Windows.
Solaris and Linux
The JRE supports use of any keyboard layout or input method that
can be used with a particular Solaris or Linux locale.
Input methods implemented in the Java programming language are
supported in lightweight components (such as Swing text
components), but not in peered components (such as AWT text
components).
Text Rendering
Applications have two options for selecting fonts:
Using the logical font names Serif, SansSerif, Dialog,
DialogInput, Monospaced.
Using a physical font, either requesting it by name or
instantiating it using the
Font.createFont method.
Text Rendering in Lightweight Components
When using logical font names, text in at least the writing
system of the host locale and the Western European subset of the
Latin writing system is supported.
When using physical fonts, we need to distinguish between simple
and complex writing systems. Simple writing systems have a
one-to-one mapping from characters to glyphs, and glyphs are placed
on the baseline continuously from left to right. Complex writing
systems may use different glyphs for the same character based on
context, may form ligatures, may be written from right to left, and
may reorder glyphs during line layout, or may have other rules for
placing glyphs (in particular for combining marks).
The 2D text rendering system supports any combination of simple
writing systems and the complex writing systems listed in the
table above. Within these limitations, the
range of supported writing systems is determined by the font. A
single TrueType font might provide glyphs covering the entire
Unicode character set and a Unicode based character-to-glyph
mapping. Given such a font, 2D can support all simple writing
systems as well as the complex writing systems shown in the table
above. Other complex writing systems are not supported.
Text Rendering in Peered Components
When using logical font names, text in at least the writing
system of the host operating system's locale is supported.
Physical fonts are not supported in peered components.
Text Rendering in Printing
There are three printing APIs:
The 2D printing API, using the
java.awt.print.PrinterJob.getPrinterJob method.
The AWT printing API, using the java.awt.Toolkit.getPrintJob
method.
The pluggable services printing API, using the javax.print
package.
Text rendering using the AWT and 2D printing API works to the
same extent as text rendering on the screen. Text rendering using
the pluggable services printing API depends on the printing service
used; the services provided by the JRE work to the same extent as
text rendering on the screen.
Drag and Drop
On Windows XP, 2003, Vista, and 7, text using the entire Unicode
character set can be transferred between applications.
On Solaris and Linux, text in the character encoding of the host
operating system's locale can be transferred between
applications.
Applications that need to transfer arbitrary text independent of
the host operating system, can do so using serialization: Create a
Transferable which supports only one flavor:
DataFlavor.stringFlavor. This flavor represents the serialized
representation of a String. Make sure that the target supports
stringFlavor as well. When the transfer occurs, the AWT will
serialize out the String on one end and deserialize on the other.
This is much slower than a native platform text transfer, but it
will succeed where native transfers may not.
User Interface
Translation
Java SE Runtime Environment
The user interface elements provided by the Java SE Runtime
Environment 7, include Swing dialogs, messages written by the
runtime environment to the standard output and standard error
streams, as well as messages produced by the tools provided with
the JRE. These user interface elements are localized into the
following languages:
Language
Locale ID
Chinese (Simplified)
zh_CN
Chinese (Traditional)
zh_TW
English
en
French
fr
German
de
Italian
it
Japanese
ja
Korean
ko
Portuguese (Brazilian)
pt_BR
Spanish
es
Swedish
sv
Java SE Development Kit
The user interface elements provided by the Java SE Development
Kit 7, include messages produced by the tools that are only part of
the JDK in addition to the elements provided by the JRE. The
additional user interface elements are localized into the following
languages: