Farewell

July 30, 2005

As of today, I’m no longer at Sun. After eight years of working on Java internationalization I feel it’s time to take a break and look at the world from a different angle.

Working here has been a long and interesting ride. When I joined Sun, the Java programming language already based all text handling on Unicode (back then thought of as a 16-bit character encoding), and JDK 1.1 had shipped with new internationalization APIs that promised to make it easier than on any other platform to develop multilingual applications. However, not everything worked as advertised, so it was a time of frantic bug fixing. At the same time, we had to find a solution for the famous RFE 4040458 and provide input method support for lightweight components such as those of the emerging Swing toolkit – not easy because for the 1.1.x line we had to provide a solution without adding any API. The full-fledged input method client API showed up in J2SE 1.2, and the input method engine SPI finally in J2SE 1.3.

This SPI started the process of opening up the Java internationalization architecture so that third parties can extend the locale support that Sun provides. The charset SPI followed in J2SE 1.4, and the locale sensitive services SPI and the ResourceBundle.Control class in Java SE 6. As I wrote earlier, the missing pieces are font rendering and user interface localization.

The set of supported writing systems expanded from European and East Asian writing systems in JDK 1.1 via Arabic and Hebrew in J2SE 1.3 to Thai and Devanagari in J2SE 1.4. The Currency class, which would have been really useful for the earlier transition to the euro, was added in J2SE 1.4. In J2SE 5.0, we had to implement supplementary character support because Unicode had really moved beyond the limits of a 16-bit character encoding. In the same release, multilingual font rendering enabled multilingual applications on the client side.

Localization made a big jump forward in J2SE 1.3.1: Before that, different sets of languages were localized for the different platforms, and for some platforms separate localized versions were produced months after the English release. Sometimes we couldn’t ship the localized versions of release n at all because they were finished only after the English version of release n+1 had shipped. I thought that’s nuts, so starting with J2SE 1.3.1 there’s been a single download bundle for each platform that includes all available localizations, which also means they all ship simultaneously.

Outside of Java SE, I worked with the Java EE web tier team to correct problems in the servlet and JSP APIs, which, like so many new technologies, had initially been developed without consideration for internationalization and then retrofitted over several releases. In the Servlet 2.4 and JSP 2.0 specifications we finally made it possible to reliably specify character encodings for all text input and output, as is necessary for multilingual web applications. I also worked with a few other internationalization experts at Sun on generic internationalization requirements.

What still hurts after all these years are mistakes that we can’t correct because of compatibility risks or where the fix would mean complete replacement. Counting months from 0 was a silly idea; merging two different representations of a point in time and the algorithms to map between them into a single Calendar class a serious design mistake. The use of apostrophes to quote uninterpreted sections of a MessageFormat pattern string still complicates localization processes, especially for French and Italian. And using ISO 8859-1 as the only supported encoding of properties files and as the default encoding in servlets and JSP pages needlessly complicates application development – UTF-8 would have been the right choice. At least these specifications have the excuse that they were written when UTF-8 was not widely supported yet. There’s no such excuse for Sun’s new bug tracking system, released in 2004.

Over the years, my team has had ten engineers and seven managers. The number of managers is comparatively high because they don’t last as long as engineers and because for a while HR rules required us to have separate managers for our sites in the US and in Japan. Two engineers also served as managers, and two engineers moved from Japan to the US. John joined the team twice and recently rejoined Sun as a technical writer. Masayoshi started before me and stays after me.

But Java internationalization has always been a collaborative effort: The original internationalization APIs in java.text and java.util were largely designed by the internationalization team at Taligent, and that team (now part of IBM) has contributed code to every major release since then; the input method framework was designed in collaboration with Omron, Justsystem, and Apple before there was a Java Community Process; the support for supplementary characters was designed by the JSR 204 expert group; the charset API was part of JSR 51 and implemented by the Libraries team; many other Java SE and Java EE engineering teams do the necessary work on their components; the quality assurance teams help find the bugs; and Sun’s central Globalization team helped with early implementation efforts. Geographically, we’ve had contributors in Silicon Valley, San Francisco, Tokyo, Yokohama, Kyoto, Tokushima, Beijing, Bangkok, Bangalore, Jerusalem, Cairo, Prague, Dublin, New York City, Ventura, and some whose physical location I never found out. Thank you to all of you.