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

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:

• Reliance on pointers for objects: Every Java object access means a pointer dereference; C++ programmers have the option of either linking objects with pointers or placing one object inside the other, thereby eliminating a level of indirection.
• Reliance on heap storage for objects: While basic types (int, float, etc.) can reside on the stack, objects in Java can only be allocated on the heap. This means more work for the memory manager and the garbage collector. Stack-based objects are much faster to reclaim, giving another advantage to C++.
• Garbage collection: While garbage collectors have their merits (they make programming a lot easier, they are a general solution to the memory reclamation problem. And for many application there is a specific solution to memory allocation and reclamation that will outperform the general one. Where performance is critical, the programmer can probably do a better job of handling this task than even the most cleverly written garbage collector (which the GC in today's Java most definitely is not).
• Run time method selection: C++ gives the programmer the choice of using virtual or nonvirtual methods. Nonvirtual methods are implemented at functions, while virtual methods require an extra level of indirection through a method table. All Java methods are virtual, which means more overhead on every method invocation. This does make life a lot easier for the programmer, who doesn't have to worry about which methods are resolved when. But there is a small price to pay.
• Insistence on object orientation: Although arguably better from a design, development and maintenance standpoint, object oriented programs tend to be written as a large number of small procedures. This means more frequent method invocations, which can mean slower code. C++ can be written in a more procedural fashion. In addition, C++ programmers can use inline declarations to eliminate function calling overhead. Java does not provide such programmer control.
• Thread-safety: Java was designed as a multithreaded language. Thread-aware languages need thread-safe libraries, in which each procedure allows for the possibility that it will be invoked simultaneously from multiple threads. To avoid problems should this happen, the procedure must set up access locks around critical sections of code. This extra work makes thread-safe libraries slower than their unsafe equivalents, which is why most thread-safe C and C++ libraries are also supplied in unsafe versions. Since Java's run time libraries are of necessity thread-safe, they are another source of overhead in comparison to C++.
• JIT translation has to be fast: Most compilers have optimization modules that perform highly sophisticated analysis on the code they generate to make it more efficient. One problem with optimization is that it increases compilation time, sometimes by quite a lot. But for performance critical applications that take a long time to run or are run regularly, the extra compilation time is more than compensated by the improved run time performance. Now apply this analysis to Java applets and just-in-time translation: instead of incurring the overhead once at compilation time, we would see it every time the byte code applet loads and is converted to native code. Clearly we don't want to wait any longer than necessary for our applet to start. This places severe limits on the kinds of optimizations that Java JIT compilers can do. Note that this constraint does not apply to Java applications, which can be compiled to native code just like C++ programs and can have a similar degree of optimization applied to them.
• Java doesn't need to be as fast as C++; just fast enough: Here's where economics come into play: once Java is fast enough for most tasks, the emphasis vendors place on performance is likely to move onto some other area where they can offer differentiation. Improving performance takes a lot of work for each small gain. So once the perception of Java as a poor performer dissipates, the marketing advantage of improving performance does the same. It's is much like the situation with C++ compilers: although C++ has features like variable references that would permit it to run faster than the equivalent C using pointers, compilers don't take advantage of that opportunity to produce faster code. In at least this regard, Marketing and customer demand drive technology.

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 disordered.org 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) {
        pushStack(input.form)
        computed = false
    }

    // make sure input.value is a string
    if(input.value == null || input.value == "0")
        input.value = character
    else
        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");
            clockThread.start();
        }
    }

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:

Google Yahoo Amazon.com Dictionary

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:

© 1996, 1997, 1998 Harris Shiffman