Java Has Left the BrowserThe battle for Java's survival was fought behind the press releases, and so was largely ignored by the press. When the dust began to settle, however, it became clear that the unthinkable had occurred: Java had not been crushed, but was actually gaining increasingly widespread industry acceptance.by Tim Romero 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 version 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 any other application. That is, the user starts the Java application by double-clicking its icon - no browser required. Because of Java's unique features, such applications are particularly useful to companies that must operate in multiple languages or use several different computer platforms. Speed is generally considered to be Java's Achilles Heel. Benchmarking tests demonstrate that Java programs do indeed run slower than their native-code counterparts. However, I have found that under real-world conditions, the speed difference is often imperceptible. There are still problems, but in my opinion Java's current shortcomings are due to its inability to live up to Sun's overly ambitious promises. Things are improving almost daily, but there is still quite a way to go before the following promises are fulfilled. Promises and reality 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 (OSes). Reality: write once, test everywhere. Yes, a Java application can be made to run on multiple platforms. However, this requires testing on all target platforms, with lengthy Òtest and tweakÓ cycles. The situation is improving as Java matures, but at the moment a developer 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, Java applications can be written in such a way that a program will automatically reconfigure its interface to match the language of the OS that's running it. For example, a Java application could be placed on a server, and when someone running Japanese MacOS opens it, the interface would be a Japanese one. When the program is accessed from a workstation running English Windows NT, the interface would be in English. In other words, 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. At Vanguard, we have 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. As long as a 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 users often need to store Japanese data on a machine running an English OS, or the operating systems of the database server and the client may be completely different. Most of Java's data-access problems stem from the fact that, instead of 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 with the database. 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 the proverbial needle. It can be done, but the process is unpleasant (particularly for the camel), and you end up with a revolting, and 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 on 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 exercised 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.
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.?
Tim Romero, president of Vanguard Consulting, often writes and lectures on Internet and software development issues. He can be reached at t3@vanguardjp.com.
|
