Documentation Contents

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 Sun's Java SE Development Kit 6 (JDK) and Java SE Runtime Environment 6 (JRE) in the following areas:

1. Enabled Locales for java.util and java.text Functionality
2. Enabled Writing Systems for Java Foundation Classes
   1. Overview
   2. Text Input
   3. Text Rendering
   4. Drag and Drop
3. User Interface Translation

Sun's Java SE Runtime Environment 6 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.

1. 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.

Sun's Java SE Development Kit 6 and the international versions of the Java SE Runtime Environment 6 support all locales shown below. The European languages version of the Java SE Runtime Environment 6 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.

Supported Locales

(*) Data for these locales are derived from the Unicode Consortium's Common Locale Data Repository release 1.4 on an "AS-IS" basis.

2. Enabled Writing Systems for Java Foundation Classes

2.1 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 98, when running on a Windows system localized for a language using that writing system.
• On Windows 2000, XP, and 2003, 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.

Sun's Java SE Development Kit 6 and the international version of the Java SE Runtime Environment 6 support all writing systems shown below. The European languages version of the Java SE Runtime Environment 6 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.

Supported Writing Systems

2.2 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 98, the JRE supports use of any keyboard layout or IMM-based input method that can be installed into a particular localized version of the host operating system.

On Windows 2000, XP, and 2003, the JRE supports use of any keyboard layout or IMM-based input method.

Global IME is not supported.

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).

2.3 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.

2.4 Drag and Drop

On Windows 98, text in the writing system of the host operating system's localization can be transferred between applications.

On Windows 2000, XP, and 2003, 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.

3. User Interface Translation

Java SE Runtime Environment

The user interface elements provided by the Java SE Runtime Environment 6, 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:

Java SE Development Kit

The user interface elements provided by the Java SE Development Kit 6, 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:

Copyright © 1993, 2010, Oracle and/or its affiliates. All rights reserved. Please send comments using this Feedback page.

Java Technology