Java Workshop: A Visual Java Solution for Japanese
|
Steve has had a lot of experience with Visual Java recently while working on the LINC Media Dai-Job website. This month, he shares some pointers on incorporating Japanese into a Java applet.
by Steve Myers
Considering that the market for Visual Basic (VB) and Delphi components topped $400 million in 1997, it should come as no surprise that all the big tool vendors have been pouring enormous amounts of resources into developing similar components and visual builder tools for Java. Integrated development environments -- such as SunSoft's Java WorkShop, Symantec's Visual Cafe, Borland's JBuilder, and IBM'sVisualAge -- are being embraced by scores of Java developers hungry for the type of graphic user interface (GUI) building power that made VB so successful.
The component model of software development is a simple concept. Instead of rolling a whole new version of each little piece of a software project from scratch, developers should be able to obtain prepackaged, ready-to-use components that can be plugged directly into a new system.
The idea is not new, of course; it has long been the norm in the hardware industry. It would be unheard for PC vendors to have to assemble a new hard drive or keyboard from scratch every time they wanted to introduce a new model. Vendors have become adept at mixing and matching parts, thereby allowing their own engineers to focus on building new features into an existing framework.
In much the same manner, software companies are moving away from the practice of developing everything in-house. They are relying increasingly on generic, reusable components, such as JavaBeans and VB/ActiveX "controls."
At the heart of Java "bean" development lies the visual builder tool. This allows the programmer to drop components, such as text fields and choice lists, onto a form, and then easily move them about and resize them as needed.
The wonderful thing about using a visual Java tool -- as opposed to, say, Visual Basic, which often grinds to a halt on tasks that require even a modicum of heavy calculation -- is that not only can a programmer lay out a GUI quickly, but the programmer can write code that actually does something. This offers the best of both worlds: a flexible, cross-platform, object-oriented language coupled with a powerful GUI-creation mechanism.
Java WorkShop and Japanese
Java WorkShop 2.0 (JWS) is the current release of SunSoft's visual builder tool. JWS 2.0 features an extremely intuitive, easy-to-use environment for software project management, source editing/debugging, and visual GUI development. As figure 1 shows, the main window provides all the standard project management, building, and debugging tools necessary for source code development.
Using Japanese in a Java application or applet created with JWS is not much different from using any other language. JWS is fully internationalized and able to handle input in most local encoding schemes. The Japanese shown in the figure was cut from Japanese WordPad (SJIS-encoded) and pasted directly into the JWS editing window.
Release 1.1 of Sun's JDK (Java Developer's Kit) adds several new classes and tools for software internationalization. Internally, Java has always represented strings in Unicode; prior to JDK 1.1, however, there was no convenient method by which to convert between Unicode and local encodings, such as Shift-JIS and EUC. The new native2ascii tool improves matters significantly by allowing the user to create a locally-encoded text file, and then convert the characters to ASCII representations of their Unicode values.
For example, the kanji "ԁh(hana) would be converted to ASCII string "\u82b1", which can then be used "as is" in any Java program. The Java Compiler interprets this string as "the Unicode character represented by the two byte values 82 (130 decimal) and b1 (177 decimal)."
A simple example
Let's examine how these techniques can be used to create a simple choice list for use in a Japanese-language applet. Suppose that we are building a database front end, one in which the user needs to be able to search for job openings in a particular industry. The Japanese text for the individual choice items might be as shown in figure 2.
Since we already have our list items, the next task is to create the java.awt.Choice component and populate it with our industries. One way of doing this would be to simply hardcode the individual choices directly in the applet code, in the following manner:
Choice c = new Choice();
c.addItem(\u30b3\u30f3\u30d4\u30e5\u30fc\u30bf\u5468\u8fba\u6a5f\u5668)
c.addItem(\u30b3\u30f3\u30d4\u30e5\u30fc\u30bf \u30bd \u30d5\u30c8)
...
If you have more than one Choice component, however, the code quickly becomes cluttered with lines that do nothing but fill components with initial values. It would make much more sense to store the items in a file on a remote server, then simply load them into a Properties object that the applet can access. This technique not only removes non-essential code from the applet, but it also makes it easier to modify the components when choice items need to be added or deleted.
In order to save the text remotely, we need to first perform the SJIS-ASCII conversion. This can be done from the JDK command prompt:
c:\java> native2ascii -encoding "SJIS" choiceItems.sjis >
choiceItems.asc
The -encoding option lets the user specify the encoding scheme for characters in the input file. If the original file contains the SJIS strings for each item, the output of this command is a new file called choiceItems.asc. It looks something like the file shown in figure 3.
The next step is to put this file in the same remote directory that will contain the applet .class file. If the applet is at "http://www.computingjapan.com/example/", then we can create the entire applet with the code shown in figure 4.
The Properties object is simply an extension of Hashtable that allows key/value pairs to be read from and written to a stream. By listing only the keys one per line in a file, and then opening an InputStream on the file from the applet, the individual choice items are loaded into the Properties object by calling its load() method. An Enumeration object then allows us to iterate through the list of names, adding them to the Choice component as we go.
Hidden pitfalls
The preceding example should give you the general idea of how JWS can be used to create AWT components, load them with Japanese text, and display them in an applet or application. Although this example is fairly simple to implement, there are still a few pitfalls you should be aware of.
For starters, the Japanese input method editor (IME) does not appear to work properly on JWS. It is easy to cut and paste Japanese text into the code, but if you try to enter SJIS-encoded characters into the source editor from the keyboard, a small editing window pops up that allows you to select the proper kanji, but then the window (along with the text) disappears once you've found the right characters and hit the "enter" key. It is also highly difficult to edit multi-byte characters that are pasted into the window from another application. This situation is not a problem if you load the strings from a remote file, of course.
Also, the JWS GUI builder uses the Java 1.1 Event model. This means that your applets will not be supported by any of the commercial browsers currently on the market (the lone exception being Sun's HotJava). If you stick to the 1.0 model, however, the applets should work on both Netscape Navigator 4.0 and Internet Explorer 4.0. They will also work fine in the JDK appletviewer.
JWS and JavaBeans represent the future of reusable components and true object-oriented software development. By combining the most powerful object-oriented language with an equally powerful visual GUI builder tool, SunSoft is taking all forms of software development to new heights.
SunSoft should also be applauded for having developed JWS (as well as its other products) entirely in Java. It's generally a good sign when developers at a software company making both languages and applications actually use the language they developed to build the applications. "Eat your own dog food, but don't believe your own press releases," says ex-Microsoft group manager Julie Bick (author of All I Really Need to Know in Business I Learned at Microsoft). Too bad there aren't more giant software companies out there who actually follow this practice.
|
