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?
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.
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
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):
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.