Source: http://spec-zone.ru/Java/Docs/1.3.1/guide/intl/locale.doc.html
Timestamp: 2019-04-23 20:55:24+00:00

Document:
The set of supported locales varies between different implementations of the Java 2 platform as well as between different areas of functionality.
Sun's Java 2 Software Development Kit, Standard Edition, v. 1.3.1 and the international version of the Java 2 Runtime Environment, Standard Edition, v. 1.3.1 support all locales shown below. The US-only version of the Java 2 Runtime Environment, Standard Edition, v. 1.3.1 supports only the English/United States locale.
Locales whose IDs end with "_EURO" are variant locales that use the Euro currency symbol.
On Windows 95, 98, ME, and NT 4.0, when running on a Windows system localized for a language using that writing system.
On Windows 2000, when running on a Windows system with both the user locale and the system locale set to a language using that writing system.
Sun's Java 2 Software Development Kit, Standard Edition, v. 1.3.1 and the international version of the Java 2 Runtime Environment, Standard Edition, v. 1.3.1 support all writing systems shown below. The US-only version of the Java 2 Runtime Environment, Standard Edition, v. 1.3.1 supports only the Western European subset of the Latin writing system. Peered AWT components are only supported for a subset of the writing systems - see the last column.
(1) eucJP on Solaris supports the JIS character sets X 0201, X 0208, and X 0212; eucJP on Linux only X 0201 and X 0208.
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 2 platform relies entirely on the host operating system. For text composition using input methods, Java 2 platform supports native input methods using the host operating system's input method manager as well as input methods developed in the Java programming language.
On Windows 95, 98, ME, and NT, the J2RE 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, the J2RE supports use of any keyboard layout using a non-Unicode code page and of any IMM-based input method.
Global IME is not supported.
The J2RE supports use of any keyboard layout or input method that can be used with a particular Solaris locale.
Using the virtual font names Serif, SansSerif, Dialog, DialogInput, Monospaced.
Using the name of a real font.
When using virtual 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 real font names, 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 for 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).
When using virtual font names, text in the writing system of the host operating system's locale is supported.
When using real font names, text in the writing system of the host operating system's locale is supported to the extent that the font provides glyphs for this writing system.
Text rendering using the 2D printing API works to the same extent as text rendering on the screen. Text rendering using the AWT printing API on Windows works to the same extent as text rendering on the screen. Text rendering using the AWT printing API on Solaris and Linux works only for the Western European subset of the Latin writing system and for Japanese.
On Windows 95, 98, and ME, text in the writing system of the host operating system's localization can be transferred between applications.
On Windows NT and 2000, arbitrary Unicode text can be transferred between applications.
Applications that need to transfer arbitrary Unicode 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.

References: v. 
 v. 
 v. 
 v. 
 v. 
 v.