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