Java Development Kit 1.1

JavaSoft's internationalization platform provides ease of use, Unicode support and a true multilingual solution.

by Vartan Piroumian

The complete article is available on MultiLingual Communications & Technology, Volume 9, Issue 2.

Java evolved out of a project whose primary goal was to provide a "better" programming language and development environment than has been previously available. The Java internationalization solution does just that. It was designed with two primary goals: to alleviate many of the shortcomings of internationalization support on traditional platforms like Unix and Windows and to fit nicely in the JDK's object-oriented framework. In the traditional internationalization model, a process starts up and loads information for one locale from a system locale databases. This locale data becomes global data in the process Only one locale can be active at any given time. In the traditional model used on Unix and Windows platforms, a newly created process, which needs information pertaining to its locale context, calls a system library routine to load information for a particular locale from a system locale database. (The target locale may be determined by examining some variable values in the user's environment.) Only one locale can be active at any given time while the program executes. This locale information is global to the process and is referenced by every internationally enabled system library routine. Based on this context information, library routines modify the way they format, parse and display data. This is a process-centered model. One significant drawback of this model is that it does not allow true multilingual computing, where an application can operate in multiple locale contexts simultaneously. For instance, it is extremely difficult for an application to display dates and monetary values in Chinese, and error messages in French. Another characteristic of mainstream internationalization solutions is the use of multibyte character encoding sets. The software developer must selectively convert multibyte strings to wide character strings if the string contains characters from various Far Eastern languages. First of all, this requires program logic to be aware of the content of text strings. Secondly, it necessitates special case processing.

Traditional internationalization solutions fail to provide adequate solutions for many common tasks. Language encoding transformation interfaces in system libraries are often cumbersome to use and incomplete; multilingual computing is difficult at best; APIs are non-uniform across platforms and portability is difficult. The internationalization model that the Java environment provides, on the other hand, is comprehensive, flexible, easy to sue and completely portable. JavaSoft's internationalization team wanted to provide a platform that offers ease of use, Unicode support, object-oriented design, true multilingual support, platform independence and true compatibility across platforms. Another goal was to encourage developers to do internationalization work as the developed their applications, instead of adding it afterwards, which always makes it more difficult and costly.

Unicode. The Java language definition specifies use of the Unicode 2.0 standard. Java interprets all text input as streams of Unicode characters. Java programs also store characters and strings as Unicode encoded data. This alleviates many of the language encoding conversion problems that exist on mainstream platforms.

Object-oriented design. the JDK internationalization solution, like the rest of the JDK, is very object-oriented. In contrast to the process-centered model of mainstream computing platforms, the Java environment has an object-centered model that complements the object-oriented Java programming language. Java programs have neither a single, global locale context nor global data structures. Instead, individual classes in the JDK have been internationalized and are now locale-sensitive. Each object instance of a locale-sensitive class is instantiated with - and references - a locale context object.

Multilingual support. Locale-sensitive objects may share locale contexts, or reference their very own locale context, giving each locale-sensitive object the ability to operate in a locale context independently of every other object in the application. For example, an application could display Gregorian calendar with text in German, dates in Japanese, error messages in French and monetary units in Chinese. This cornerstone of the technology that implements the capability is the JDK's locale object, which represents the locale context object mentioned above.

Platform independence. One of the hallmarks of the Java environment is that programs are "write once, run everywhere", or, without the hype, "platform independent." Java programs should be written generically, without reference to specific platform configurations, references to a specific API, etc. Of course, the Java environment uses platform specific services, but these are not exposed in the JDK APIs. The internationalization classes reflect this platform independence too. Programmers who discipline themselves to write truly "100% Pure Java" code (and this is actually easier than trying any other approach) will realize how much effort they save not trying to "second guess" the capabilities of the JDK.

Backward compatibility. The JDK provides support for all internationalization tasks. In particular, the JDK contains extensive support for character set conversion. This is essential because most of the world still does not use Unicode. Most of the world's most popular computing platforms still have not fully implemented Unicode libraries and support. Java applications must interoperate with existing software and systems. the JDK contains a rich set of character encoding set converters.

The JDK 1.1 supports the following functional internationalization categories: locale objects, calendar and time zone support, formatted output and parsing, localized resources, locale-sensitive string operations, character set conversion, character-and byte-oriented stream I/O, localized exception handling and Abstract Window Toolkit (AWT) additions. As stated above, Java programs do not have any global variables, and they do not have any global locale context. Locale context is determined on a per object basis. That is, object instances of locale-sensitive classes (classes which have been written to modify their behavior based on their locale context) form an association with a locale context when they are instantiated. This context determines the exact behavior of the object. Each locale-sensitive class can alter its behavior appropriately for each locale context in the set of locales it support. Each object instance of a locale-sensitive class can reference a different locale context. Therefore, an application can simultaneously instantiate multiple objects so that each operates in a  different locale context. The result is true multilingual processing.