The technical resource will be providing educational information and resource links designed to assist our visitors in gaining additional insight into the technical field. NAW's technical experts and guests will be providing information on a regular basis. Additional information and resources can be found in our member's section. To join, please click here.

The following is an example of the technical reports that we will be covering.

The Speed of Java

By Bruce Eckel

As interesting as Java is, the popularity of the language has befuddled even Java creator Jim Gosling. While a lot has been written about Java, much of it is introductory in nature. As I take on this column, I write from the standpoint that there is enough hype and plenty of introductory Java information available in book form and on the Internet (my own book, for example, is freely available; see URL Resources).

This column, then, will not be about either of those things, but instead will add perspective to the language and where it's going. I'll also attempt to perform reality checks so you can avoid surprises, and review tools and books. At the end of this month's column, I'll look at The Java Programming Language (Addison-Wesley, 1996) by Gosling and Ken Arnold. But first, I'll discuss what Java can really be used for, explore its uses on the Web, and examine the main limiting factor -- speed.

Where does Java fit?
The original structure of Web documents made sense: The server hands you text containing benign HTML that describes page formatting. Since any calculations were performed on the server, this scheme was completely safe; no viruses could be executed on the client machine. However, the Web rapidly evolved from this document-delivery model into a client/server system, where the need for client-side programming becomes quite pressing to increase responsiveness, eliminate latency, and just to keep from bogging down the server and the Net.

Java has been put forward as the ultimate programming solution for the Net, and its attention to security, programming safety, and portability certainly has significant appeal. But the success of a programming language -- as demonstrated by C++ -- often depends more on how well it leverages programmers' existing knowledge. Java looks a lot like C++ and behaves a lot like Smalltalk, but it's a different language than either. While it's simpler than C++ in many ways, that doesn't make it a simple language (despite what the Sun folks would have you believe).

As Software Development editor Larry O'Brien said, "Claiming Java is easier than C++ is like saying that K2 is shorter than Everest." What most people would really like is to use the language they know best, but to have it work for client-side Web programming. That's happening, and it's pushing Java away from being all things to all people, and into more of a power-programming niche.

For example, a recent press release from Sun stated that Tcl/Tk will be available as a client-side programming language for the Web, and will run under Netscape Navigator (and no doubt Microsoft's Internet Explorer). The release was careful to note that Tcl/Tk doesn't compete with Java, and of course it doesn't solve all of the problems Java does. Yet it's a reason for Tcl/Tk programmers not to learn Java if they don't have to.

Thus, there are competitors to Java: JavaScript, VBscript, other scripting languages that seem to be announced on a regular basis, and schemes such as ActiveX and plug-ins that allow you to program in a language that you already know. The Java world domination that many envisioned -- especially the folks at Sun -- seems threatened.

Most readers are familiar with the experience of designing a solution to solve a problem, and then having the problem, and the solution along with it, evolve. I suspect that many other languages, especially scripting ones, will solve the bulk of the client-side programming problem. I think Java may find its true calling as a general-purpose programming language, not just for solving the more difficult Web programming problems but for platform-specific (albeit easier-to-port) application development. This would seem to be where Borland and Microsoft are focusing. Borland's Latte looks almost exactly like its Delphi, with improvements. Microsoft is also shooting for the Delphi model, but with an intent to seamlessly integrate their Common Object Model (COM) using Java's interface keyword, which seems ready-made for the task. Both vendors are either replacing or wrapping the AWT with their own much-improved libraries, although you can make applets and the AWT will still work.

The Speed Issue
The determining factor is speed, since there are classes of problems that simply cannot be solved unless the language is fast enough. For example, people have gone so far as to suggest that Java will be used, or even become the language of choice, for scientific programming. I recently had a consulting meeting with a researcher at Stanford University who was building finite-element models of water flow through rocks, and some of his models required 20 to 30 million elements. Such systems are not uncommon in scientific programming (an oceanographic-research model was my first experience with C++), and performance is critical.

So how fast is Java? In Core Java (my current favorite among the books; I'll review that next month), by Gary Cornell and Cay Horstmann, they run the Sieve of Eratosthenes on pages 374-375. While apologizing for the narrowness of the test, which focuses on bit operations, they compare its performance and find the Java implementation about the same speed as Visual Basic 4, and 40 times slower than C++.

Much of this overhead, of course, is from the interpreter in the Java Virtual Machine (JVM). This kind of overhead can be reduced greatly with Just-In-Time (JIT) compilers, but Borland, which pioneered the concept, estimates that those won't get better than five to ten times slower than C++. If we step out of the realm of applets, what kind of performance could you expect from a native-code compiler building an application to run on a particular target machine?

When I asked Jim Gosling this at a Java One press conference, he said that with optimizations he thought a Java program could run as fast or faster than C++. This baffles me, only partly because a language designer whom I trust and with whom I have had long association thinks Java could never run more than three to five times slower than C++. And partly because I've been compiling a list of the features in Java that provide safety, simplification, or improvement but also cost performance that I don't think can be optimized away (or can only be optimized in certain situations):

• All objects must be created with new, on the heap. Meaning you always have the overhead of dynamic memory allocation. C++ gives you the option of using the less flexible but much faster approach of creating objects on the stack.
  
• Array bounds checking. Every time you access an array, a runtime check ensures that you don't violate its boundaries. This feature could easily be turned off via a compiler switch when you are comfortable with the code.
  
• The primitive types are portable. The benefit is that you never need to worry if an "int" will behave differently on one machine or another, which is a great relief for portability. The drawback is that primitive types (boolean, char, byte, short, int, long, float, double) heavily used in certain types of programs may not run as fast as possible on your machine because their size may not fit easily into the machine's word size. Extra instructions may be required to perform operations on those primitives, so in exchange for portability you get a performance hit.
  
• Method-call type checking. Every method call involves a run-time check to make sure the call is correct. Although some of these can be eliminated by a good compiler using flow analysis, others cannot.
  
• Synchronized-method overhead. Currently there's a performance hit of roughly six times a normal function-call overhead when calling a synchronized method, which can theoretically be reduced to four times. Synchronized methods are used liberally (especially in the standard Java libraries), and it seems impossible to optimize away the cost. This is significant.
  
• Interfaces have extra overhead in their use. This is a bit mysterious since it seems that everything could be resolved at compile time, but it's generally agreed the extra overhead is there.
  
• Less compile-time checking means more run-time checking. A good example of this is container classes like "Vector and Hashtable:". Because there are no parameterized types in Java, these containers always hold the root class "Object". When you fetch an object out of the container, you must cast it to the proper type before you can make a method call. This must always be a run-time cast, even though you know what type it is at compile time. There's always some overhead that no amount of compile-time analysis can optimize away.
  
• The "String" class uses Unicode everywhere. This is good for internationalization but it is guaranteed overhead when you know you only need 8-bit characters.

C++ is designed for speed; Java compromises performance in favor of safety and ease of programming. You have to make a trade-off somewhere, and I suspect that Gosling may have been caught up in the marketing excitement engendered by his company when he made his outrageous claim.

If you've seen other aspects of Java that seem to exact an unremovable toll, please email them to ; the list will be updated in the "Java tall tales" appendix of my online book.