Java

This article appears in slightly different form in the May/June 1996 issue of IEEE Micro © 1996 IEEE.

Java has received a lot of attention lately -- not just in publications like this one, but in the mainstream press as well. Technologists and investors alike are trying to cut through the hype, trying to find reliable, unbiased information to base their product planning and financial decisions on.

I remember sitting at Compcon in San Francisco, quite a number of years ago, listening to a presentation about the newly announced Intel 432 microprocessor. A man sitting behind me tapped me on the shoulder and asked if this was going to be an important product. He was a financial analyst for a big brokerage firm. He had no idea how to evaluate the lavish claims he was hearing. I don't remember what I told him, but if he's still in the business, he's probably got the same problem with Java.

C Is a Hard Act to Follow

Many years ago systems programmers used assembly languages for all of their serious work. We have had high-level languages since Bachus implemented Fortran in 1956. Computer scientists have developed many high-level languages since then, but only one, the C programming language, has caught on for general programming use.

It was not superiority over the others that made C catch on. In fact, C has many drawbacks. Before it became popular its main claim to anyone's attention was the fact that it was the underlying language of Unix and a beneficiary of the continuing research efforts of Bell Labs.

Unix gained great popularity in universities in the 1970s. In the early 1980s, because C made it portable, Unix became the operating system of choice for implementation on the dozens of 16-bit and 32-bit microprocessors that appeared. C became firmly entrenched, even for applications programming.

Unfortunately, C embodies old technology. Many people realized that the then current methods of software development were on a collision course with disaster. Structured programming, classes, modularity, and object-oriented programming -- ideas that were all well developed by the mid-1970s -- needed to find their way into mainstream programming practice. The principal attempt at making C evolve in that direction was Bjarne Stroustrup's C++.

In an article in the October 1984 AT&T Bell Laboratories Technical Journal, Stroustrup announced that his three-year-old "C with classes," drawing heavily on the ideas of Simula 67, was already known as C in his in-group, while what we know as C was now called "old C." This usage never caught on among the general programming public, but it shows Stroustrup's intention to develop an essentially backward-compatible replacement for C.

The Java Approach

By contrast with Stroustrup's exuberance, Ritchie, Johnson, Lesk, and Kernighan, writing in the July-August 1978 issue of the Bell System Technical Journal, had already realized:

Realistically, the very acceptance of C has compelled changes

to be made only most cautiously and compatibly. Should the

pressure for improvements become too strong for the language

to accommodate, C would probably have to be left as is, and

a totally new language developed.

They speculated on what the new language might be called, but "Java" was not one of their guesses. Yet that's what Java is: a totally new language designed to replace C.

Unlike C++, which seeks to extend C and maintain a large degree of backward compatibility, Java starts from C and rips out its most troublesome and error-prone features:

• Pointers.
  
• Explicit memory management.
  
• Global variables.
  
• Goto statements.
  
• The preprocessor, header files, INCLUDE, and IFDEF.
  
• Use of integers as logical variables.
  
• Platform dependencies and the sizeof operator.
  
• Compilation into machine code.

Then it adds classes, strong typing, clean string and array handling, multi-threading, exception handling, a platform-independent virtual Java machine, complete support for distributed programs, and a package-naming convention that allows Internet-wide uniqueness of fully qualified names. Java's designers have declared it to be fully buzzword compliant.

I got this far into the column before mentioning the Internet. But if all you've heard is the hype, you may think Java is just a way to write interactive programs called applets that make three dimensional icons rotate on your screen when you visit cool web sites.

In fact, the latest Netscape web browser provides a runtime environment for Java programs, and Java allows easy dynamic linking of packages, even across the Internet. This is the source of a lot of the recent interest in Java and a lot of the controversy. The controversy centers on security.

Everyone knows that it's not a good idea to download executable programs from untrusted sources and run them on your machine. On the other hand most people are not afraid to download and let their web browsers display text, graphics, audio, video, or anything else that falls into the general category of "data." People trust data but not programs.

Java's designers have tried to make executing downloaded Java programs as safe as displaying data. A downloaded program really is data in the sense that control never passes to it. Instead, the Java interpreter reads each byte and performs a corresponding action from a carefully circumscribed set of prearranged actions.

To be worth bothering with, the list of prearranged actions can't be too small, but the longer the list, the greater the chance for error. Every week someone seems to find another loophole that a malicious developer could use to create misbehaving Java programs, and the designers quickly introduce a corresponding safeguard. Time will tell whether or not this process will converge to a mechanism that people can trust.

Even if it never makes the Web a safe way to deliver programs, Java is a serious programming language. Detractors compare it with other p-code languages, Pascal for instance, which never gained acceptance for systems programming. Other detractors, fond of the concise expression that C's ambiguities allow, complain that Java is too simple. Proponents of C++ who have finally figured out how to use such complexities as templates, operator overloading, and multiple inheritance may be unwilling to move to Java, which doesn't have those features.

I think Java will eventually replace C, but I think C++ will persist as its competitor for a long time. That conflict will probably follow the model of the RISC vs CISC wars, so that ten years from now it will be hard to know which is which.