Why we care about Java

Forces are at work to divide Java. The original and true purpose of the technology will carry Java through the current maelstrom of confusion and clutter

Arift has opened in the Java community because of arguments concerning Java's portability, efficiency, business politics, and even whether Java is a language or a platform. In this article, I address these concerns and remind you why we care about Java. Further, I illustrate how attempts to resist the "will of the Internet" have failed.

What is Java? A language? A platform?

Java is a programming language that comes with a well-defined set of APIs or class libraries; together the language and API form a consistent view of any platform. You can call Java a meta-platform or a view of an existing platform, but the effect remains the same -- Java supports the execution of a single program without modification on any machine with a Java-compatible VM and API. That is, Java gives you a homogeneous view of an inherently heterogeneous network.

Java became important primarily because it provides for the seamless and invisible distribution of software across the Net. Prior to Java, there was no Internet programming language. If another language had surfaced before Java with the key ingredient of portability, Java might not have been so successful. Consider Visual Basic, an extremely successful predecessor to Java. Visual Basic does not have the huge groundswell that the Java revolution has because it is neither portable, secure, nor designed with the Net in mind. Visual Basic is an example of the same old limited PC paradigm. Visual Basic runs on 80 percent or so of the World's computers, but apparently the community thinks that 80 percent is not sufficient for a revolution. Just as telephones are vastly more interesting and useful when everybody has access to one, being able to run a program anywhere is dramatically more significant than running it on only 80 percent of the machines.

Portable? It depends...

What about recent statistics showing that about half the Java programs do not run on all machines? These studies do not show that Java is not portable. They do, however, point out that programmers are not taking advantage of the mechanisms available in Java to write portable code. Just because you write in Java does not mean that your program is automatically perfectly acceptable to every platform. For example, the following Java code is not portable (in that it will not execute as the author intended) nor is the equivalent code in any language portable.

File f = new File("/usr/dict/words");

Obviously, file /usr/dict/words will not exist across all platforms and, further, the use of the backslash as a file separator is nonportable; consequently its presence renders the surrounding application nonportable. There are many analogous examples when building GUIs such as expecting specific font or screen sizes. Clearly, if you ask for an 800x600 window on a 640x480 screen, your program will fail. The 100% Pure Java Initiative is an attempt to get programmers to pay attention to portability (see the 100% Pure Java Cookbook). Java gives you the tools you need to make things portable, like GUI layout managers, Unicode, locales, and so on -- you do not have to rely on ad hoc solutions like C++ (e.g., di-glyphs and tri-glyphs for multi-byte character sets, system calls for locales).

One final element can cause portability problems: bugs and inconsistencies that exist in the various Java implementations. As with any complex piece of software, the number of problems will asymptotically approach zero over time. JavaSoft and its partners have created The Java Porting and Tuning Center to increase platform consistency and decrease the time lag between release of the JDK and its implementation by the various vendors.

But Windows can be my whole World, right?

Why should you care about portability instead of focusing on the huge Windows market, 80 percent of the world's computers? This question is like asking in the early 1980s, "Why should I use a PC when I have a mainframe?" Like the early PC, Java supports a new computing paradigm with advantages over previous systems. Most importantly, if you base your product on Windows technology, you will be programming to a moving target, as Microsoft is jostled around by the Net like everybody else (I cite the disappearance of ActiveX as a prime example). The Internet has forced most companies to rethink their strategies. Even Microsoft performed an impressive about-face when it realized the Internet's dominance. Microsoft would not have licensed Java (a threat to their business) had the Internet not forced them to. The Net ignored VBScript/BlackBird and if Microsoft wanted to be in the game, they had to go where the developers were. Ignore the Net at your peril.

What about performance?

Even if you pay attention to the Net and 100 percent portability, isn't Java a lot slower than C++? The simple answer is no; neither language has a significant inherent speed advantage over the other. Java is slower at the moment because it is interpreted, partially interpreted, or less well compiled than C++. Doing a priori (static) compilation on Java programs will yield execution times similar to that of C++ programs, but it kills portability and security. A just-in-time (JIT) compiler, on the other hand, preserves Java's portability and security by compiling a program right before it is executed (dynamic compilation). Unfortunately, a JIT has the constraint that compilation time plus reduced program execution time must be less than simply interpreting the program; JITs do not make sense for programs that run for only a very short time.

For long-running programs, dynamic compilation has serious advantages over static compilation. Static compilation can optimize for only a single CPU (usually the lowest common denominator, such as the Intel 386). Dynamic compilation, in contrast, can generate code tailored to each particular run of a program. More specifically, variables at static compilation time are effectively constants at dynamic compilation time. Consider the following piece of object-oriented code where an instance method is referenced for some variable of type Object.

int h = obj.hashCode();

Looking at the program statically, a compiler does not know what the actual type of object obj will be at run time and hence it cannot know which version of method hashCode will be called -- no method inlining is possible. In contrast, at run time, obj is of known type and a compiler can inline hashCode. For example, if obj were known to be of type Integer, the compiler would generate the equivalent of:

int h = ((Integer)obj).value; // hashCode inlined

In C++, you must do a virtual table lookup to find the address of a function and then call that function:

int h = (*(obj.vtable[hashCode-vtable-offset]))();

The int assignment generated by the dynamic compiler is dramatically cheaper than calling a virtual method, particularly since the inlined version will sit entirely in the cache. The C++ version, on the other hand, will generate expensive cache and possibly page misses due to the virtual table reference.

So why don't current JITs do this fancy optimization? Well, for one, it's hard. Secondly, just as object-oriented programming took 20 years to make the transition from research to industry, sophisticated "on-the-fly" compilation has been in the research literature for many years. Sun has a nontrivial percentage of the leading scientists that developed these techniques working for them now. The first mainstream implementation of their optimization techniques, HotSpot, is currently rocking the house behind closed doors at JavaSoft, and will be included in a future version of the JDK.

Swing Set

OK, so you believe Java is portable, you care about portability, and you know Java will soon be fast enough. You might ask yourself, "Isn't the window library, AWT, insufficient to create professional-looking applications?" Many programmers have answered yes to this question and have built their own window library using lightweight components, which they send along with their application. The Swing components in JavaSoft's Java Foundation Classes (JFC) comprise exactly such a library, except that the JFC will be core (present in any JDK implementation). Swing is a superb, professional set of widgets and controls for form-based programs. But don't take my word for it, download the latest release from JavaSoft and run the Swing Set demo, which speaks for itself.

Sun vs. Microsoft?

If Java is so great, why are Sun and Microsoft arguing? Simply put, Microsoft's duty is rightfully to make money for its stockholders, and it is in Microsoft's best interest to have everyone writing applications that work only under Windows. That is, it understandably hates operating system-neutral applications. Microsoft embraced Java hoping to convince developers that it loves Java and that Microsoft is the de facto leader. Then Microsoft might be able to divert developers to view Java as just another way to use Microsoft's established technology such as ActiveX (which apparently is being euthanized, and superseded by DNA), AFC (Application Foundation Classes), and J/Direct.

Microsoft's removal of all Java applets from its Web site hardly bolsters the company's status as a Java enthusiast. Microsoft's strategy is to label Java as merely another programming language. Pardon me, but Java as just another language is hardly interesting enough to grab so much attention. (Even my mother knows about Java. She doesn't know about Visual Basic or C++, however.) Java represents a new computing model and supports platform independence for your applications. It is also important to note that Java (the language component) is not a particularly good way to access (via J/Direct) a pointer-based, non-garbage-collected API such as Win32 written with C and C++ in mind.

The Internet is the world's largest and most successful anarchy. No one is in control, and the most successful Internet players to date are those that have gone with the flow rather than trying to control it. Java enables distributed computing and secure code motion on the Internet, creating a revolution far outstripping the PC revolution in significance.

In summary, I remind you that Java's portability is a key ingredient of this revolution, but that you must program with portability in mind. (The 100% Pure Java Program/Initiative supplies tools and resources to do so.) JDK 1.1 has addressed many of the shortcomings of the initial 1.0 language release, and the new APIs to be included in the core JDK 1.2 libraries allow the rapid development of sophisticated programs. Coupled with execution speed that will soon rival -- and in some cases surpass -- that of statically-compiled C++, Java will far exceed developers' expectations.

Terence Parr is the president and co-founder of the MageLang Institute -- founded to promote the growth of Java by providing excellent Java education and by acting as an independent resource. He received a Ph.D. in computer engineering from Purdue University, Lafayette, IN (1993) and completed a postdoctoral fellowship with the Army High Performance Computing Research Center at the University of Minnesota. Parr is the primary author of the public-domain PCCTS language tool kit, which is used extensively throughout the research and industrial community to develop compilers, translators, and interpreters. He has published a book on PCCTS and a variety of technical papers on the application of language theory. By day, Terence is a wild-eyed highly-caffeinated Java evangelist. By night, Terence plays blues piano and works on the 2.xx version of ANTLR, a complete rewrite of PCCTS in Java to generate Java.

Learn more about this topic

This story, "Why we care about Java" was originally published by JavaWorld.


Copyright © 1997 IDG Communications, Inc.