Tangled Webs

   Java has Left the Browser
Issue 3.07
Aug 17, 1998



Covert Operations


The battle for Java's survival was fought behind the press releases and was thus largely ignored by the press. When the dust began to settle, however, it became clear that the unthinkable had occurred. Microsoft had lost. Java had not been crushed. It was actually gaining increasingly widespread industry acceptance.

Unfortunately, when most people think of Java, they still think of Java applets, those small, usually trivial applications that run inside (and occasionally crash) web browsers. In the early days, applets were about the only useful thing you could write with Java, but with Java 1.2 in beta as of this writing, Java is growing up fast. It has already outgrown the web browser.

Vanguard (my own company) has developed and is developing several Java applications that look and behave just like other applications. A user starts a Java application by double-clicking its icon. No browser required. Because of Java's unique features, such applications are particularly useful to companies which must operate in multiple languages or that use several different computer platforms.

Speed is generally considered to be Java's Achilles Heel, and benchmarking tests demonstrate that Java programs do indeed run more slowly than their native-code counterparts. However, we've found that under real-world conditions, the speed difference is often imperceptible.



Promises Promises


There are still problems, but in my opinion, Java's current shortcomings are largely an outgrowth of Java's inability to live up to Sun's rather ambitions promises. Things are improving almost daily, but there is still quite a way to go before the following promises are fulfilled.

Promise: Write Once. Run Anywhere
The same Java application will run on any machine and perform identically on all of them. A Java application will run unmodified under Windows, UNIX, OS/2, AS/400, Macintosh, and many other operating systems.

Reality: Write Once. Test Everywhere
A Java application can be made to run on multiple platforms. However, it requires testing on all target platforms and lengthy "test and tweak" cycles. The situation is getting better as Java matures, but at the moment, one simply cannot assume that an application will behave identically on all platforms.


Promise: No Localization Headaches
Java supports internationalization and multilingual computing at a far more fundamental level than other development environments. In fact, a Java application can be written in such a way that the program will automatically reconfigure its interface to match the language of OS that's running it.

For example, a Java application can be placed on the server, and when someone running Japanese MacOS double clicks it, the interface will be a Japanese one. When the program is run from a workstation running English Windows NT, the interface will be in English. A single copy of the application supports all languages.

Reality: New Development Headaches
While Java's support for multilingual computing is fantastic, the existing tools for building and maintaining such functionality leave much to be desired. Vanguard has had to create our own (non-Java) tools to manage multilingual application development in Java.


Promise: Transparent Database Access
Java's JDBC provides seamless database access. Applications can access data stored in virtually any human-language in any almost database system running under almost any operating system. The programmer never has to worry about the specifics of the database.

Reality: Nice Try Sun
Actually, as long as the Java application is running under the same operating system and in the same human-language as the database, JDBC is a dream to work with. Unfortunately, in the real world we often need to store Japanese data on a machine running an English OS, and the operating systems of the database server and the client are often completely different.

Most of Java's data-access problems stem from the fact that rather than allowing the programmer to specify how data is to be written to a database, Java delegates this critical task to the JDBC drivers. These drivers are developed by third-party vendors, and the way they handle character encoding is inconsistent.

Almost all of these problems can be solved by careful evaluation and selection of JDBC drivers. However, writing Java code that will work correctly with any database on any platform is like passing a camel through the eye of a needle. It can be done, but the process is unpleasant (particularly for the camel), and you end up with a revolting, unrecognizable mess.



Warts and All


So with all of Java's apparent shortcomings why are so many companies using it to develop production applications? Frankly, for data-based, networked applications that must run in multiple languages and multiple platforms, no other development environment even comes close to providing Java's functionality.

Things are improving rapidly, but at the moment, a great deal of additional care needs to be taken during Java development. Furthermore, Java applications require far more testing than those written in other languages, and I don't see that changing in the near future. Despite its slowly fading warts, however, Java has proven itself to be a viable development platform.

To be sure, Microsoft has not given up the fight. But their tactics are becoming increasingly desperate and transparent. For example, Microsoft's Java development tool J++ no longer supports the Java specification, and can only be used to generate the most trivial of Java applications. In another move, Redmond recently announced that Internet Explorer 5 browser will not include Java support. It will only be available as a separate download.

Such actions will have little effect at this stage, however. With both industry acceptance and the ranks of Java programmers swelling daily, it looks like Java is here to stay.


[ Home Page] [ Back to Index ] [ Previous Issue ] [ Next Issue ]

© Copyright 1998, Tim Romero, t3@vanguardjp.com
This article fist appeared in the August edition of Computing Japan.
Tangled Webs may be distributed freely provided this copyright notice is included.
The Tangled Webs Archive is located at http://www.dotco.com/t3/tangledwebs/index.shtml