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 isn't a page description language like HTML. It's a programming language. Description languages specify content and placement; programming languages describe a process for generating a result. Where there is generally a direct mapping between an HTML description of a document and the result, the relationship between a Java program and its result is likely to be more complex. It's a little like the difference between a list of square roots of numbers from zero to 10 and a program to calculate the list.
Make no mistake about it: Java is a programming language. If you find Pascal hard, you won't care for Java. Writing in Java may be different in degree from C or C++, but it is not different in kind.
Is Java easy to learn? It may be somewhat easier than C or C++. Not because its syntax is any simpler, but more because there are fewer surprises. (Try explaining the difference between a C pointer and its array implementation some time. And C++ adds lots of its own peculiarities, like temporary variables that hang around long after the function that created them has terminated.)
Is Java easier to use? Again the answer is a firm maybe, possibly, perhaps. It eliminates explicit pointer dereferences and memory allocation/reclamation. These two features are the source of many of the hardest-to-find bugs C programmers have to deal with. And Java does add array bounds checking, so out-of-range subscripts are easy to find. It's too soon to tell whether Java is really easier or just seems that way because no one is writing anything truly complex with it.
Java source code is a little more portable than C-based languages. In C and C++, each implementation decides the precision and storage requirements for basic data types (short, int, float, double, etc.). This is a major source of porting problems when moving from one kind of system to another, since changes in numeric precision can affect calculations and assumptions about the size of structs can be violated. Java defines the size of basic types for all implementations; an int on one system is the same size (and can represent the same range of values) as on every other system. It does not permit the use of arbitrary pointer arithmetic, so assumptions about struct packing and sizes can't lead to non-portable coding practices.
Where Java is more portable than other languages is in its object code. Most language compilers generate the native code for the target computer, which then runs at the best speed of which the system is capable. Java compiles to an object code for a theoretical machine; the Java interpreter emulates that machine. This means that Java code compiled on one kind of computer will run on every other kind of computer with a Java interpreter. The tradeoff is in performance: the interpreter adds a significant level of overhead to the program.
Note that this extra overhead can be reduced considerably by just-in-time compilation techniques. When the Java interpreter receives a chunk of code to execute, it could convert it from Java object code into the native code of the machine and then execute the real code. This adds some overhead during the translation process but permits the resulting code to run at close to native speeds. (Java is still likely to be slower than C or C++, due to some ease-of-development features of the language. However, the difference in performance may not be all that significant.)
In theory a Java applet can do anything: manipulate 3D VRML models, play movies, make sounds, you name it. In practice it's a lot more limited. We've already seen one important limitation: an applet has control of its region of the page but no ability to operate outside the page. But here's a more serious one: an applet can do only what the runtime environment allows. Today that's limited to some low level graphics, user interfaces (buttons, menus, text fields and the like), reading and writing files (under strict security guidelines), playing a sound file and some network capabilities.
What's missing? There is no way today to control a VRML model. And what if we want to do more to a sound file than just play it? What if we want to change the volume? Or do a fade in? Or add a reverb? None of these effects exist in Java's bag of tricks. And none of them can be built in Java. They would need to be written in a fully compiled language like C and then made available to the Java run time environment.
And therein lies the real limitation. To do more than Java can do today requires that we do two things: write new libraries that can be used by the Java interpreter; and then make each of those libraries available on every single system that might try to use these new capabilities. An applet is only usable if the capabilities on which it depends are available wherever we want to run them. Because although we can download applets at the moment we want to run them, we can't do the same with the underlying libraries. Java's built-in security makes downloading an applet low in risk; the same can't be said for arbitrary code libraries which do the low level work.
So Java is limited by the pervasiveness of support libraries. We need general sound and video manipulation and other multimedia capabilities on every system with a Java-enabled browser. Then we won't be quite so limited. This is the plan for SGI's Cosmo Motion, a set of cross-platform libraries to extend Java into sound, video and animation.
For this point, we need to distinguish between Java the programming language (the description of syntax and semantics) and Java as it is implemented today. As a language, Java may be perfectly suitable for big projects. Its object orientation supports integration of large numbers of object classes. By eliminating explicit pointers, it allows programmers to write more maintainable code. So Java as a language is likely to be a better choice than C and perhaps better than C++ for large applications. Of course, we won't know until someone actually tries it!
But while the Java language may be appropriate for big programs, Java as it is implemented in web browsers is not. With a fully compiled language like C, all of the compiled code is combined into an executable program as part of a link process. References to symbols in one module are resolved to their definitions in another.
Java resolves all symbols when an applet is loaded into the browser. Each class mentioned in the applet class is loaded to the browser and all the symbolic references are resolved. Inheritance relationships among classes are also resolved at this time; where C++ decides the location of each class member at compile time, Java defers this decision until you attempt to load and run the class.
The upshot of all this is that the equivalent of program linking occurs when you run the code in a class. The larger the class, the larger the number of classes and the more complex the inheritance tree, the longer all this will take.
In addition to dynamic linking, Java performs one other important task before it can begin running a class: validating the code to prevent it from doing anything dangerous. This requires a scan of all of the loaded code to look for funny operations and attempts to break out of the restrictions placed on untrusted applets. Again, the more code you have the longer it will take to process the code before it can begin to run.
Note that the first commercial Java applets don't use Java for everything. Applix's Java-based spreadsheet, for example, uses Java for the user interface. All the real processing, including loading and saving spreadsheets, is done in CGI code on the server. This is probably the best model for using Java in sophisticated applications. Once there are fully compiled Java implementations, of course, all the rules change.
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 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, 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.
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.
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 to shell languages like the Korn or Bourne shells or Perl. JavaScript commands appear as text within the HTML, as in this example from Netscape:
function addChar(input, character){// auto-push the stack if the last value was computedif(computed) {pushStack(input.form)computed = false}// make sure input.value is a stringif(input.value == null || input.value == "0")input.value = characterelseinput.value += character}
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.
It's possible that Netscape used the Java virtual machine to implement the JavaScript runtime, so the naming may have some validity. But from a programmer's perspective, Java and JavaScript are about as similar as C and the C Shell.