Making Sense of Java

There is as much misinformation about Java as there is information. On this page I have listed some common claims and beliefs about Java, along with a description of how accurate the claims are and where they go astray:
* Java is a language for writing web pages; it's like HTML and VRML
* Java is easy to learn and use, unlike C, C++ and other programming languages
* Java code is portable, where C and C++ are not
* Java solves the problem of cross-platform application development
* Java can be extended to do anything the machine can do
* Java is suitable for building large applications
* Java's performance problems are temporary; it'll soon be as fast as C++
* Java is interpreted; Basic is interpreted; Java = Basic
* Java in a browser eliminates the need for CGI scripts and programs
* Netscape's JavaScript is related to Java
* Java will replace C++ as the language of choice

This is page two. Do you want to see page one?

Java's performance problems are temporary; it'll soon be as fast as C++

Right now Java is slow: slow to load, slow to start and slow to execute. Load time can be attributed in part to Java's insistence on storing each class in a separate file and using a separate HTTP request to retrieve it. Changing to an archive that stores a bunch of classes in a single file should help quite a bit. Start time is related to load time (classes are loaded the first time they're invoked, not at startup), but also includes late binding time. In essence, every time we run a Java applet we're paying a startup penalty so the developer doesn't have to do a link step. Since the Java classes don't change all that often, doing the link and placing the linked classes in an archive is generally preferable.

This leaves execution performance as the biggest problem. And a problem it is, with Java code taking an average of twenty times longer than native C++ code. Of course, an average tells you nothing about how a specific program will behave: some Java applets run nearly as fast as C++ (likely because most of their work takes place in native code run time libraries), while others run more like fifty times slower.

The best solution to this difference in performance is to translate Java source or byte code into native code. Most platforms have native code translators either already available or under development. Native translation can make a huge difference in performance for Java applications; when applied to applets in the form of just-in-time translators they provide similar gains at the expense of a small increase in startup overhead. Suddenly Java that runs twenty times as long as C++ can get a lot closer.

So how close can Java get? Will it ever reach the point where it can replace other languages for performance-critical tasks? Does it make sense to write compute-intensive codes in Java and design the Java run time to take advantage of multiprocessor architectures?

For a lot of reasons, Java is likely to always be slower than C++ and Fortran for the typical application. (A range of 50% to 300% slower than C++ has been suggested as the practical limit of Java performance improvements.) Some of these reasons are:

The upshot of all this is that Java will get a lot faster, but that there are likely limits on its performance. Java won't be as fast as C++; and C++ won't be as fast as Fortran. There will still likely be a need for at least a few different languages for different requirements.

Java is interpreted; Basic is interpreted; Java = Basic

Although Java does use an interpreter, it actually has more in common with fully compiled languages like C and C++ than it does with fully interpreted languages like Basic or APL. A fully interpreted language has to have very simple syntax, so that code can be parsed very quickly. (The source must be parsed every time the application is loaded.) The tradeoff is that such code becomes harder to understand and maintain as projects get larger and more complex.

Because Java is compiled, speed of compilation is less important than the quality and maintainability of the code. Its structure and object orientation make it suitable for large, sophisticated projects. It supports features that would be prohibitively expensive (in time, memory or both) in a fully interpretive language.

Java in a browser eliminates the need for CGI scripts and programs

Java applets will replace some uses of the Common Gateway Interface. Prior to Java, the only way to create a web page whose contents are not static was through CGI scripts or programs running on the web server. In some cases, this server-side code can be replaced conveniently by Java applets running in the browser. In many situations, however, browser-side Java can't be used in place of CGI. The reasons may involve security (do we want password validation code running in the interpretive Java environment, where a clever user could disassemble them?) or performance constraints that Java's interpretive environment can't satisfy.

In a lot of cases, Java will let us do things that CGI supported badly if at all. Client pull and server push are brute force, high overhead techniques for creating interactive pages. By eliminating the need to communicate with a server, we can create truly interactive pages. An example is this clock applet, which tells me that I have owned the domain for an unknown number of days ( an unknown number of weeks or an unknown number of years). These three instances of a particular applet class share a thread, which updates their display every eight seconds. A CGI-based equivalent would require communication with the server on every update.

In the short term, we may have to use CGI mechanisms simply because Java doesn't give us access to the resources we need. To write a web browser-based database query application, we would set up a form to capture the input and ship it off to a CGI script on the server. This server-side program would validate the data, run a query against the database and generate a new HTML page with the result. A Java applet could be used to replace server-side data validation, thereby improving user response in cases where the input is invalid. (No wait for the browser to communicate with the server and the server to send the error back.) If we have a Java class interface to the database (and our concerns about security don't keep us from using it), we could implement the query and display in Java as well and eliminate the server-side code.

This discussion ignores two other points: that JavaScript will sometimes be a preferable to Java for browser-side programming; and there are now opportunities to invoke server-side Java code in the form of servlets. Java on the server has many of the same advantages and disadvantages over other server-side languages that Java has as an application language. A large advantage of Java servlets is that it saves the process creation overhead inherent in CGI, particularly in situations where there will be multiple interactions between browser and server to satisfy a request; there are disadvantages as well in the increased complexity of the debugging environment for such code.

Netscape's JavaScript is related to Java

JavaScript and Java seem to have little in common other than their names. JavaScript is a scripting language that can be used within an HTML page. It is similar in concept (though clearly not in capabilities) to scripting languages like Perl and the shell languages of the Korn and Bourne shells. JavaScript commands appear as text within the HTML, as in this example from Netscape's site:

function addChar(input, character)
    // auto-push the stack if the last value was computed
    if(computed) {
        computed = false

    // make sure input.value is a string
    if(input.value == null || input.value == "0")
        input.value = character
        input.value += character

Java code does not appear as part of the HTML. Instead, the HTML contains a link to the compiled code module:

<applet code=Converter width=275 height=160></applet>

The syntax of Java and JavaScript are different as well. Java is more C++-like, where JavaScript looks more like ksh. (Notice the function keyword and the lack of semicolons at the end of each JavaScript statement.) It is even more class-oriented than C++: every Java function must be a method of some class. There are no global variables or functions in Java.

public class Clock extends java.applet.Applet implements Runnable {

    Thread clockThread;

    public void start() {
        if (clockThread == null) {
            clockThread = new Thread(this, "Clock");

It's possible that Netscape took a long, hard look at Java as they began work on LiveScript, which became JavaScript. But from a programmer's perspective, Java and JavaScript are about as similar as C and the C Shell.

Here's the square root example as embedded JavaScript. You'll need Netscape 2.0 or later to see it:

View the document source to see the JavaScript code that built this table.

Here's an example that uses JavaScript to access one of several search engines. There's a hidden form for each search. The form on the page invokes a JavaScript function which sets up the appropriate hidden form and submits the request. This technique will work with search engines that expect Get or Post requests:

To do the same task in Java would require a lot more code. A Java applet would have to set up the user interface, as well as format and submit the various types of requests.

In general, JavaScript is preferable when you want to manipulate the contents or behavior of an HTML page in simple ways. More dynamic or sophisticated behavior is better done within Java applets.

Java will replace C++ as the language of choice

I've been seeing this one a lot lately. Frequently the comment comes from a member of the original Java team. But other times it is voiced by someone whose fame and fortune is not tied directly to the belief that Java is the Second Coming. It is of course possible that everyone working in C++ today and all those who contemplate moving there will someday move all of their work to Java. But it's awfully unlikely.

The question is a pretty silly one today. Java code is far slower than C++, it can't do most of the things C++ can do and its object model and architecture hasn't been tested on large projects. We need to assume that Java can be made fast enough for most applications and that it will be given interfaces to all those libraries we need. We also need to assume that Java's long startup time (the time it takes to resolve method and data member location) can be reduced or eliminated without losing the flexibility that it was intended to provide. We need to assume that Java's garbage collector won't introduce unreasonable overhead when the programs and their data space requirements grow. (Remember that the 640KB memory limit in DOS was based on the experience with CP/M. CP/M gave you 64KB of memory. Who could possibly need more than ten times that?)

Even if Java were better than C++ at everything (a huge if), any claim to its replacing C++ ignores the inertia of the computer industry. Despite the success of C++, there are still more C developers in the world. The fact that PC-based development products include both C and C++ makes it difficult to know which language people use in what proportion. In the Unix world the answer is easier to see. And here C outsells C++ by a comfortable margin. This is in spite of the fact that C++ makes it easy to migrate existing C code with minimal modification in the code or in our development model. Java makes no such concession.

Of course, all this ignores the fact that most of the programming world doesn't work in C or C++. There is still a lot of Fortran out there among all the people who care about the best possible performance. And there's more Cobol than anything.

That the world is excited about Java is clear. That there is reason to be excited is clear as well. But I wouldn't start recycling those C++ books any time soon. Five years ago there was enormous hype about how C++ would change the world and usher in a new world for programmers. Ten years ago it was Lisp and Prolog and expert systems. Things have a way of not exactly turning out the way the press predicts. (Anybody remember how OS/2 was going to wipe Unix from the face of the planet?)

Take me home: Take me back: Show me another:

Comments to: Hank Shiffman, Mountain View, California

© 1996, 1997, 1998 Harris Shiffman