Speakers Norbert Lindenberg (Norbert) and Brian Beck (Brian)

Moderator Edward Ort (MDR-edO)

This is a moderated forum.

MDR-edO: Welcome to Java Live! Our session today is on internationalization support in the Java^TM 2 platform, Standard Edition. Our guests are Norbert Lindenberg and Brian Beck, key members of Sun's internationalization engineering team. So let's begin. Who has the first question on internationalization?

bizexchange: Was there any improvement made in i18n area for Java 2 platform? If so what is it?

Norbert: Hi, I assume you mean the upcoming version 1.3 of the Java 2 platform, since version 1.2 has been out for quite a while. We made major progress in two areas: in the input method framework and in support for bi-directional scripts, such as Arabic and Hebrew. I'll talk about the first, Brian about the second. For input methods, we introduced the input method engine SPI, which allows any of you to create an input method in the Java programming language. We have a sample input method on our web site that accepts airport codes and translates them into city names in five languages. It's a toy, but it gives you the idea. Other people have already gone ahead and developed more serious input methods for Chinese, Japanese, and some European languages.

Tarek: How can Java support "Left to Right" language on systems that do not support this language (Arabic, for example)

Brian: Do you mean how do we support "Right To Left" languages? All systems that I know about always support "Left To Right" languages as a subset of anything else they support.

Tarek: Yes, that is what I meant.. Sorry for the confusion. I am trying to take Arabic input from my applet. But I am facing major bugs when the applet runs on Windows 95 if it does not support Arabic. Some glyphs show as squares when they combine with other glyphs. and there is a problem with the leading space, such as I write in to the JtextField the string starts moving left!

Brian: Tarek, OK, I understand. We support Arabic with the Java 2 platform starting with release 1.2. If your applet is running on a browser that does not have a Java^TM 2 Virtual Machine¹ (JVM) then you will not be able to do Arabic. A second point is that we support Arabic using the Swing GUI toolkit. We do not support it in the AWT toolkit. So you will be experiencing problems if you are trying to use AWT. If you are having problems with a Swing applet under Java 2, let me know and we can try to look at your problem some more.

jlin: I have tried to install the IRE 1.2.2 for Linux on RedHat. It was processing Chinese data correctly, but not Japanese. Do you know why this is so? Are some Linux OSs more internationalized than others?

Norbert: Hi Jlin, I haven't followed our Linux project too closely, but I know that we've been struggling with the different versions of Linux and their different approaches to internationalization (and anything else). If I recall correctly, most of the testing for English was done with Red Hat, but with TurboLinux for Japanese, and I'm not sure about Chinese.

sphere: Norbert, where is that sample input method? I am also looking for more information beyond the Internationalization Specification on the JavaSoft Web site.

Brian: I'll try to finish Norbert's answer about our Arabic and Hebrew improvements in version 1.3. The first thing we did was to extend the Arabic and Hebrew support to all the Swing text components--not just the styled text ones as was the case in version 1.2. So now you can use JTextField and JTextArea as well as JEditPane and JTextPane to edit Hebrew and Arabic. Also, you no longer have to programmatically enable Arabic and Hebrew support in these components. The components will automatically recognize when right-to-left text is present and will do the right thing. Another big improvement was to our Component Orientation support. We have extended this support to cover almost all the Swing components. Finally there were lots of bugs that were fixed.

Tarek: I am using SWING, and until now I was testing using appletviewer (the applet does not work with the browser) I am using Windows '95, English, and with the help of JTextField components I am able to display the Arabic letters in them, but it only correctly displays glyphs when they are alone. This is not the case on Windows '95 with Arabic support (every thing works fine on it)!

Brian: What version of the Java platform are you using? Is it version 1.2, 1.2.2 or 1.3?

Tarek: I am using 1.2.2. Is there an easy way to make the Netscape browser compatible with the Java 2 platform?

fenderboy: has anyone here used the Java programming language to interface with a modbus client?

Brian: Fenderboy: I am unfamiliar with "modbus". Could you explain?

jlin: Are there any performance issues with separating translatable strings into resource bundles and loading it at runtime that we should be aware of?

Norbert: Hi Sphere, the sample input method is at java.sun.com/products/jdk/1.3/docs/guide/imf/spi-tutorial.html. There's a whole lot more information in the same directory (such as, use index.html instead of spi-tutorial.html).

Brian: JLIN: Performance is one of those things that you can never say much about without making real measurements of real programs. In theory, ListResourceBundles are faster to access than PropertyResourceBundles. In practice, I don't know that this makes much difference. Most programs will read all their resources out of a bundle at startup time and set them into their GUI components and then not use the bundles anymore. Because this is usually a one time operation, the performance is fast enough that it doesn't matter. Are you seeing a problem?

MDR-edO: Our chat server went down. We're back up.

jlin: Does Sun plan on supplying one font.properties file that supports all CJK fonts?

Norbert: Since you don't ask too many questions, I can ask one: Are you planning to come to the Unicode conference in Amsterdam next week? We're going to have a session there where we talk about our ideas for future internationalization work and hope to get feedback from our customers.

jlin: Yes, most definitely. Will be there on Sunday morning! Which session will you be talking the future plan?

Norbert: We have two sessions late Thursday afternoon.

sphere: I have a general question. I've been looking around and noticed the words globalization and localization. What exactly is the difference between these words?

Brian: JLIN: Well, yes and no. As you have no doubt noticed, Sun's font properties files are all single locale. This is because single language programs are by far the most common and there is a performance penalty to putting too many fonts into a font properties file. So we don't intend on making font properties files with "fat" fonts. On the other hand, we are distributing a large Unicode font with Java 2 that can be used directly (not through font properties files) in your Java applications. This font does not contain any CJK glyphs yet but we are working on obtaining those glyphs right now. Of course, there is also the problem of making a single font that satisfies Chinese, Japanese and Korean users. Because of the Unicode standards policy of Han Unification, this is difficult to do. We may end up supplying separate C, J and K pieces of the font that comes with Java 2.

Tarek: I will download the 1.3 version and experiment. But you make it sound too easy :) is there somewhere where I can see sample code for making the JTextField work with Arabic? As for the Java 2 plugin (6MB) I think it's too much to ask from our clients once our site is up. I have seen a site that uses Java to enable Arabic input without sking the user to download any plug ins. Is there a way to include a few required files into a jar that will be used by the applet? (Hope I am making sense.)

Norbert: Hi Sphere, I think when people say "globalization," they usually mean the same as we do by "internationalization.". It's easier to start with the definition of "localization"--that's the adaptation of a product for a particular locale (language/country), making it handle text in that locales language, format dates and numbers correctly, display messages in the local language, etc. Internationalization is all the work that makes localization easy--separating out all the functionality, text, and data from the core code of a product, so it's easily accessible for localization. Recently it's also become a goal of internationalization to support multiple locales concurrently, like the functionality in our java.text package or in the input method framework does.

Tarek: It's not that we don't have many questions. If you give me your email address, I promise to pester you with questions! The main reason, I guess, is that i18n is closely related to Swing issues, too...

Brian: Well, we try to make it easy. Hopefully we succeed. I am working on some sample code this week that I hope to publish soon. Until then, you should really just try to instantiate a JTextField (under 1.3) and use it in the same way you would for english. You will need to use a font that has Arabic glyphs but you can always use the Lucida Sans Regular font that comes with Java 3. You will also need a way to type Arabic. This is easy if you are on an Arabic system like Arabic Windows '95. You can also install Arabic keyboards on non-Arabic systems (I've done this with Windows NT). You can even write a simple Java Input Method that remaps an English keyboard to Arabic. I have also written one of these and may make it public when I publish the example I mentioned. You can also get these kind of remappers from a company called SlangSoft.

jlin: Has anyone integrated the installation/configuration of font.properties file into the InstallShield or whatever installation program so that you choose the locale, and then it will allow you to choose the font.properties file correctly? Maybe a bit of programming needed on the install shield program?

Norbert: Tarek, it's better if you send your questions to our feedback addresses: java-intl@java.sun.com for the core internationalization functionality, swing-feedback@java.sun.com for Swing. These mailing lists get read by many people here, so you have a better chance of getting replies.

jlin: localization is the integration of locale-sensitive data into the application. Everything the user sees will be in their native language. The application should load up resource bundles that pertain to that specific locale at runtime.

Brian: JLin: I don't know if anyone has integrated font.props and InstallShield. This would be a good thing to do. We have also talked about intelligent font.properties file editors in past that might be able to scan your system for fonts and build a custom font.props file for you. This would also be a great project but we might not get around to it for a long time. Any of you want to try?

jlin: Where can I read more about this Unicode font and when does Sun plan on having it ready for displaying the CJK glyphs? Any projected timelines?

jlin: Is it even possible to name a Java program with Chinese name even if I am using the localized version of NT? Does Sun supply a localized JRE/JDK^TM for this support?

MDR-edO: We were scheduled to end at noon pacific time. But because we were down for a while, we'll go until 5 minutes after the hour.

Brian: Jlin: I'm not sure we've published much in particular about our Lucida fonts. You can try looking at the Java 2D^TM documentation on Java Sun. As far as timelines goes I've got three lawyers standing over my shoulder here ready to beat me senseless if I promise any dates :-) I can say that we are actively working with several font vendors right now to do this and I would personally like to see it available for the feature release after 1.3

sphere: jlin, I've found some good info about Unicode at these places Java in Depth and Converter Classes They are kind of dated, but they are some of the best I could find. Anyone have other suggestions?

Tarek: Do any of the i18n team reply to the i18n forum questions? it's a pitty it's nto as fast growing as the Swing Project forum, but on the other hadn this gives a better opportuinity to answer more questions!

Norbert: Jlin, re: Chinese program names: If you mean class names, they were kinda supported by the Java programming language specification since the beginning, but in recent versions (certainly 1.3) the entire runtime supports them. So, yes, you can now have a Chinese class name, name the .class file correspondingly in the host's file encoding, and use the java command to run that class's main method.

Tarek: Once I have a compiled class that handles my Arabic input, would publishing the HTML file that includes the applet suffice for it to run on any one's PC?

MDR-edO: Tarek, as far as the I18N forum, the intent behind all of the forums on the JDC is to have the JDC community participate in questions and answers. It's not really intended for Sun engineers specifically to answer the questions, although they are certaininly invited to respond.

jlin: Sphere, you can also try Czyborra.com and Unicode.org

kconant: I'd love to go to Amsterdam next week, but I can't. I'm involved in a startup and looking at Arabic, Greek, Chinese, Japanese, French, German, English, Spanish, Italian, and Portuguese. I'm just in the design and prototype phases. I missed the answer to the question about resouce bundles and performance.

Brian: With version 1.3, it is possible for your applet to include its own fonts and input method (keyboard mapper) in its jar file. This means you can write an Arabic program that has no dependencies on the host platform. We are finally getting close to that "Write Once, Run Anywhere" thing.

sphere: Also, how would you suggest using databases in different languages. I am currently trying to switch between English and Japanese. The JDBC^TM connections work fine in English, but in Japanese I get some sun.io.ByteToCharConverter error messages.

Norbert: Hi kconant, too bad you can't come. As for the missed question, EdO is planning to make the transcripts of both chat parts available on the JDC web site.

jlin: Norbert, just to clarify your answer on Java class names in localized text. Do I need any special JDK for that support or do all JDKs support that functionality as long as the i18n.jar is included. And before 1.3, can I run Java classes with foreign names?

Brian: Sphere, it's hard to tell what your problem is without seeing more of your program. One thing about using JDBC is that the quality of your JDBC driver makes a big difference in how well encodings are handled. The JDBC spec, like all Java programming, expects only Unicode characters so its up to your JDBC driver to do the conversions. In general, your driver comes from your database vendor like Oracle.

Norbert: Hi Jlin, the tricky part of using non-ASCII class names is getting the name from the command line and then finding the .class file. In both cases, the Java runtime uses the default encoding for the current host and locale, and so unfortunately a Chinese class name can only be used where the default encoding supports Chinese.

MDR-edO: Well our time is drawing to a close. I want to thank our participants for joining us. And of course I'd like to especially thank our guests Norbert and Brian.

Brian: Thanks for the questions folks. Hope this has been helpful. As a side note, we are always interested in seeing what people have done with international Java. If anyone has product demos they'd like to send our way, please do. You can use java-intal@java.sun.com Brian.

Norbert: Bye all, and don't forget to write!

MDR-edO: Last moderator (me) signing off. The forum is now unmoderated

_______
¹ As used on this web site, the terms "Java Virtual Machine" or "JVM" mean a virtual machine for the Java platform.

Reader Feedback