Java is big news. Both the technical and mainstream press have been filled with articles about how Java will change the nature of the World Wide Web, client/server application development and the economic model for delivery of software for everything from spreadsheets to video games. It is taken as some sort of natural law that Java will supersede C++ as the language of choice for general development, that Java is C++ done right.
Before you start recycling all of your C++ books, perhaps it's a good time for a dose of reality about Java: what it is, what it isn't yet and what it might become some day. Although there is value to Java now (and there will be a lot more value in the future), it isn't the solution to all of the world's problems. Java is a programming language, not a recipe for world peace.
Part of the difficulty in separating hype from reality is that Java is actually many different things. And Java's potential varies considerably depending on which Java we're talking about. Today Java is:
Each of these describes a different version of Java. Each has its own set of advantages and limitations. It is important to understand that just because the Java language supports some form of behavior doesn't mean that it will be permitted in all implementations. Practicality, performance and security all conspire to limit what we can build with Java.
Java is based heavily on C++. Its designers clearly intended to produce a language that is easier to learn and to use than C++. To this end they removed many features that developers find confusing (and C++ is loaded with them!) and added features like garbage collection. Java is easier to learn than C++. And the addition of garbage collection and the elimination of explicit pointer manipulation do reduce the most common sources of errors in C and C++. But these enhancements are not without cost.
C++ was intended to be a better C, to use object-oriented techniques to support the development of much larger, better organized programs. Its design was influenced by two important requirements:
The design of the Java language was not hamstrung by either concern. It is not a superset or a subset of C or C++; it shares some of their characteristics and goes its own way on others. It is also not as concerned with efficiency. Fully optimized Java code will always be slower than the C++ equivalent, thanks to Java's use of heap memory and pointers for all objects (C++ allows one object to be embedded into another; Java doesn't), garbage collection and other language features.
(Note that we are not talking about the poor performance that we see with Java today. Current performance problems are the result of run time interpretation. But even with true compilation to native code, Java will still be slower than C or C++ although not by the factor of twenty to fifty we see today.)
As a language, Java is more object-oriented than C++. While C++ supports both the procedural style of C and its own object orientation, Java requires the use of objects. It offers neither global variables nor functions; all data items and functions must be members of a class. Java also reduces the number of syntactic elements it inherits from C++: a period character in Java serves as both the namespace specifier and the member access operator:
classname::method()becomesclassname.method()
object->method()becomesobject.method()
Beyond the characteristics of a language, programmers are aided or limited by the interfaces available to them. It is in this area that Java is particularly weak. Its classes permit a program to:
Anything else must be provided by the programmer. This includes use of any system services accessible from C or C++ but not provided by Java. Java does not use the shared library conventions of other languages, so it is necessary to create special Java interfaces for everything. This is not a bug; it's a feature and, as we'll see later, a requirement for applet security.
Java can be used like C++ to write standalone applications. In the current environment, Java source code is compiled to a byte code; the byte code is interpreted during execution by the Java virtual machine. This byte code interpretation runs far slower than.native code. Its advantages are portability and code size (byte code is typically much smaller than the equivalent native code).
Of course, nothing prevents vendors from writing Java compilers that generate native machine code instead of byte code. Native compilers would make Java more competitive in performance with other languages but would remove its portability advantage.
An alternate solution is just-in-time compilation, where the Java virtual machine translates the byte code into native code just before execution. For small applications this would still offer portability and reasonable performance. (A just-in-time compilers would want to do little if any optimization to keep its overhead low. As a result, the performance of the resulting code would likely be much lower than optimized C or C++, although still far better than interpreted byte code.)
However, even the portability advantage of Java applications may not be real. Given the limited capabilities of the standard Java environment, most applications are likely to depend on additional capabilities written as Java-callable native libraries. These libraries will have to exist everywhere the application is to run; if the application needs to run on many different kinds of systems, the native libraries will have to be ported there as well.
Most of the interest in Java does not involve applications. It centers instead around Java applets: little pieces of Java that are downloaded automatically to run on a web page. Although Java applications and applets are very similar, security requirements prevent applets from doing many of the tasks that applications can do.
An APPLET tag attaches a Java applet to a page. The tag tells the browser what code to retrieve and how large a region to use as the applet's display area. PARAM tags provide the applet with parameter values:
<applet codebase="java" code="DaysSince" width=60 height=11>
<param name="date" value="6 Feb 1995 1:00 PST">
<param name="textColor" value="0000ee">
<param name="URL" value="java/DaysSince.java">
</applet>
The applet is responsible for everything that happens within its display area. It cannot affect any of the HTML-specified contents of the page. It can communicate with other applets on the page. It can also cause the browser to load a new page. But most of its visible behavior is constrained to its own display area.
In some ways, an applet is like an image. Like the IMG tag, the APPLET tag identifies the size and contents of its rectangular region and the region's alignment within the page. One difference is that images are better integrated into the page than applets: an image display area inherits the background color and image from the page, which causes transparent GIF images to display correctly. An applet does not inherit this information; it's the applet's responsibility to use a background, text color and fonts that match the surrounding page. Since it isn't possible to match an applet's background image with that of the surrounding page, many Java pages use a solid colored background.
When a page containing an applet is retrieved, the applet's code is transferred as well. An applet is an object class based on the java.applet.Applet class. This class may refer to or inherit from other classes; each class is retrieved from the server in turn. (The standard classes are installed on the user's system and are loaded directly from disk.) Linking of all the classes into one program happens at this point, with all of the classes from all the applets on the page sharing one address space. The code is checked for attempts to violate security. Assuming none are found, it then begins to run. This architecture makes it easy to try out new software, since there's no installation or user setup to go through.
Security is a big part of the Java run time environment. Any web page that a user retrieves may also cause Java code to be transferred and executed, without the user knowing that it happened. If a Java applet can write files, a rogue applet could destroy every writable file on the local system. If it can read files or open arbitrary network connections to other systems, it could pass private information back to the web server. It is for just this reason that Java applets are restricted in their access to local resources. In the current Netscape implementation a Java applet can not read or write local files, start other programs or open a network connection to any host except the one which supplied the page.
(At least that's the way it's supposed to work. Like any other new and complex piece of software, the Java virtual machine isn't quite as secure as was claimed. Several security holes have already been identified and plugged. One can assume that more will be found and that at some point one will be exploited to do real damage.)
Security requirements make Java applets rather less useful than we would like. We can't write a web-based spreadsheet, since we can't read or write files. (A Java-based spreadsheet from Applix uses Java just for the user interface; all of the calculation and file manipulation happens in a process on the server.) We can't do file manipulation programs like spell or grammar checkers, image processors or any other program that takes our data, processes it and returns a result, unless the input and result can be represented directly on the web page.
So what's left? What are Java applets good for? Two important categories that come to mind are interactivity and animation. HTML has limited support for interactivity through the form mechanism. Forms let us write data entry and query kinds of pages. They are also useful when returning results that the user may wish to use in a new query. What they don't do is give us any way to validate the data without having to talk to the server. Server-side validation won't feel terribly interactive if network bandwidth is limited or the server is slow to respond.
Java can address this problem nicely. A Java applet can implement a form-like user interface. The Java code can examine the user's entries, apply validation rules and identify input problems from inside the browser. No communication with the server generally means a faster, more interactive environment.
(Java isn't the only way to do this. Netscape's JavaScript language can be combined with the existing form mechanism to provide data validation. In Java's favor is the fact that the entire interface can be managed as a single entity by a single piece of code. Java has other advantages over JavaScript, especially as the problem to be solved becomes more complex.)
HTML has even less support for animated content than for user interaction. Techniques like client pull, server push and progressive image files all require repeated contact with the web server and work poorly when network bandwidth is limited. Java can do much better to provide images that animate without constantly grabbing information from the server. And Java can combine animation and interactivity to provide easier navigation through a complex user interface. An example of this is SGI's own Silicon Surf (www.sgi.com), which offers a Java-based system of menus to its various sections.
What keeps us from going further? Java is severely limited by its performance and by the availability of class libraries. Where C++ programmers can call upon libraries like ImageVision for 2D image processing or Open Inventor for 3D modeling, Java programmers are left to do all the work themselves. This will change with the delivery of Java libraries like SGI's upcoming Cosmo 3D. The just-in-time compilers we discussed earlier for Java applications can also be employed to improve the performance of applets.
Note that just-in-time compilation is the only way to speed up applets. Native code compilers are inappropriate here. The virtual machine's security mechanism needs to validate the code in an applet before it can run. Such a validation can't be done on native code, at least not in anything approaching reasonable time.
The new VRML 2.0 specification uses Java to add animation and interactivity to the Virtual Reality Modeling Language's 3D models and scenes. The interaction between Java and VRML is significantly different than that of Java and HTML. With VRML the relationship is much tighter: small pieces of Java code are used to manipulate parts of the 3D scene in response to time or proximity events. This is also different from using Cosmo 3D within a Java applet. In one, Java is used to construct and manipulate a 3D scene. In the other the scene is described with VRML and only the changes are implemented with Java. The VRML approach is likely to be easier, especially as VRML authoring tools become available to automate large parts of the process.
There are many other languages being implemented or at least discussed in relation to web browsers. What's significant about Java is its pervasiveness (available or soon to be available on all Netscape-supported platforms), the portability of its byte code (one executable runs everywhere, assuming that all of its libraries are also available on the target system) and its acceptance within the industry. It could be argued that the Java language has less acceptance than the current implementation. A different language could be compiled into the same byte code and run in the same virtual machine. So a better language (or just a better variation on Java) could gain acceptance and replace Java without breaking anything.
In fact, significant parts of Java are already being rejected as inadequate. The best example is the AWT window toolkit. Many in the know expect AWT to be replaced by a toolkit that is more flexible, more object-oriented and generally easier to use. Even members of the original Sun team admit that AWT is a hack. They blame the weakness of AWT and other parts of the standard library on the limited amount of time before they had to deliver software to Netscape.
With all the excitement about Java it's easy to miss the fact that it isn't Java that deserves the excitement; it's the ability to produce interactive distributed applications using the web. Java is one way to achieve this. (Or at least it will be when all the missing pieces are in place.) Java isn't the ultimate solution; it's just one more step along a long and tortuous path.
Take me home:  |
Show me another:  |