I hate Java. As a programmer, I hate Java, the language, for what it has done to the field of programming. As a journalist, I hate the relentless hyping of Java by its supporters, as well as their unending excuses as to why Java has failed to deliver. And as a technologist who has been involved with three major projects that have used Java, I hate the complications that Java has caused.
I will concede that it is possible to use Java to create small applications that are downloaded over the Web and run within Web browsers. Over the past month, I've actually run into two such Java-based applications that worked pretty well. The first was a Java-based mortgage calculator that dramatically shows the financial advantage to pre-paying your home mortgage -- paying just $50 extra on a $733 monthly mortgage payment can save you $40,196 over the course of an 8 percent, 30-year loan. I was also particularly impressed by the Yahoo Finance Java-based portfolio manager, which lets you rapidly compare a large set of stocks using dozens of different variables.
But such examples are exceptions rather than the rule. The vast majority of the high-profile attempts to use Java to create major desktop applications have failed. The reasons are straightforward. Java hype is built on the promulgation of two Big Lies. No. 1: Java is as fast, or faster, than other programming languages. And No. 2: Java is "portable" -- it is "write-once, run-everywhere" -- in other words, a Java program can be written once and then run on any kind of computer or operating system. But five years after Java's introduction, it is still slow and cumbersome, and not only has the "write-once, run-everywhere" promise not been delivered on, it's also turned out to not even be necessary.
Java is far from even being the first attempt at portability. Let's not forget that the original motivation behind the C* language, way back in the early 1970s, was to create a portable computer language. The theory was that a programmer would be able to take a program written in C and be able to run it on different computers simply by recompiling* the source code. And to this end, C has been tremendously successful. I have many programs that can compile and run on Windows, on Intel-based Unix workstations, and even on Sun Ultra-SPARC servers. One of the advantages of Java over C was supposed to be that programs would be able to migrate from computer to computer without having to be recompiled. But while the portability works most of the time, Java is not, and never will be, a replacement for C or its successor C++.
The creators of Java tried to make a better C++. But they ended up with a language that is ugly, hard to read and that requires an inordinate amount of typing because of a variety of pedagogical restrictions imposed by Java's creators. They ended up with a slow mess.
Look behind Java's first Big Lie, and it's clear that a well-written program in Java could never run as fast as a well-written program in C or C++. That's because the Java bytecode is interpreted, not compiled. Programs written in C are compiled into binaries which can be executed by a specific computer processor. Programs written in Java require one more step -- they must be interpreted by the Java "virtual machine" before running on a particular computer architecture. As a result, a computer running a Java program has to execute more machine-language instructions to do the same amount of work than a computer running an equivalent program written in C.
Remember back in October 1996 when Corel announced that it was creating Corel Office for Java? Corel promised us a complete rewrite of WordPerfect and other office applications, which would have supposedly allowed these new Java-based applications to run on any Java-compliant machine.
Office for Java was a failure. While the product is still in the Sun Java Solutions catalog and you can download the beta from a few archive sites on the Internet, the project was abandoned in August 1997. Download it for yourself and you'll find out why: It's buggy and sluggish. On my 700 MHz Pentium III, Office for Java brought memories of my old Macintosh Duo's ill-fated attempts to run the heavily bloated Microsoft Word 6. The program's speed, alas, was dreadful.
Netscape had similar problems when it attempted to rewrite large parts of Netscape Navigator into Java. Indeed, the damning article What Netscape Learned from Cross-Platform Software Development," explains how Netscape's engineers were sold on the language and started writing large chunks of Navigator into Java. Netscape was committed to delivering Navigator on nearly a dozen different platforms, so Java seemed like the perfect solution. But Netscape's engineers couldn't make the language perform as Sun had advertised: Java was simply too slow. Netscape's engineers tried writing their own Java implementation, thinking that they could build a version that was faster than Sun's, but even that didn't work. "By mid-1998, Netscape was not only deemphasizing Java, it was even planning to replace existing implementations with C and C++." In other words, Netscape was taking the new code that had been written in Java and was rewriting it in C and C++.
Not the best advertisement for a state-of-the-art programming language, one might argue. Still, Java's supporters insist that many programs written in Java can be made to run as fast as programs in C. David Pollak, a San Francisco programmer who wrote an entire spreadsheet in Java and now does technology turn-arounds for companies that have Java disasters on their hands, is a huge fan of running Java applets inside Web servers: the performance difference between well-written Java and native C code is negligible, says Pollak. What really slows down Java programs, says Pollak, is when the Java applications try to display user interfaces on the screen of a computer. One way that Pollak has found to speed up Java programs is to rewrite their user interfaces in Microsoft's Visual Basic.
Pollak is a realist. But Sun Microsystems, which originally created Java, goes further, claiming on numerous occasions ( here and here, for example) that Sun's HotSpot technology would allow programs written in Java to actually run faster than programs in C++.
It's true that some programs written in Java do seem to run nearly as fast as similar programs written in C. It's also true that this experience isn't universal. So what gives?
A 1999 study of programming efficiency goes a long way toward explaining the conflicting experiences with Java's performance. For the study, Lutz Prechelt, a senior research associate at the school of Informatics at the University of Karlsruhe, Germany, had 38 graduate students write 40 different versions of a simple text manipulation program. The programmers, who had an average experience of eight years, created 24 versions in Java, 11 in C++, and five in C. The results, published in Communications of the ACM, were revealing. The majority of programs written in C or C++ could complete the given task in between one and five minutes. Most of the Java programs, on the other hand, required between two and 30 minutes, with some taking more than an hour. In other words, the fastest Java programs, written by the most experienced Java programmers, could significantly outperform the poorly-written C programs. But the typical Java program was much slower than the typical C program.
The upshot: It's better to train programmers to write efficient code than to depend on new programming languages to do it for them.
"The bottom line is that if you are a skilled-enough programmer and a dedicated-enough person to wade through the docs and learn to use Java effectively, you are going to be just as effective in any of the other computer languages that people have been using in the last 30 years," says Philip Greenspun, who teaches software engineering for Web applications at MIT. "If you weren't good enough to program in C or LISP or PL/1 or Pascal, then you aren't good enough to program in Java."
Java's second Big Lie was "write-once, run-everywhere." As long as every Java implementation was certified, Sun told us, they would all run the same Java bytecode equally well. But as programmers became experienced with the language, they soon realized that Java was really "write-once, test-everywhere." Every Java implementation is a little different, and sometimes those differences matter.
Write-once, run-everywhere isn't even that useful an attribute for a programming language today. Sure, it would have been a godsend in the 1980s or the early 1990s, when a dozen different companies sold different microprocessors and different versions of Unix and other operating systems. But by 1995, when Java was introduced, the business world had pretty much settled down to use Intel-powered PCs running Windows on the desktop. The truth is that most businesses didn't need Java's promise of "write-once, run-everywhere." The only people who needed it were companies like Sun and Apple: If these companies could just convince Windows programmers to code in Java, then their resulting programs would run equally well (or poorly) on Windows, Sun's Solaris and Apple's MacOS.
Java does have one good idea: automatic memory management, also called "garbage collection," which actually eliminates one of the most common causes of program crashes in the world of C and C++. Of course, SmallTalk had garbage collection in 1970, and LISP had it in the 1960s --- or was it the 1950s? But at least garbage collection is part of the language. (As an interesting side note, it's fairly trivial to add garbage collection to C and C++ as well, but for some reason the practice is not popular.)
I must also admit that, despite my animosity, it looks like Java will have a bright future. But that future probably won't be on desktop computers at all. Rather, it will be on smart cards, handheld devices and embedded computers, using the Java 2 Platform, Micro Edition. The Micro Edition actually comes with several slightly different -- and mutually incompatible -- versions of the Java language, but all of these Javas have essentially the same syntax and use essentially the same compilers. And since there are hundreds of thousands, if not millions, of people who have painstakingly learned Java over the past five years, companies adopting this so-called J2ME technology will have thousands of developers capable of writing programs for their products.
I've long argued that companies like Sony and Sharp should create developer kits for their microprocessor-containing consumer devices. With the J2ME platform, they don't have to create the developer kit: Sun has already done the work. Security professionals have warned that this will open the door wide for hostile code and malicious programmers, but who cares? It will be cool for people to be able to download programs to run on their cell phones.
But what will be the ultimate legacy of Java? The anti-Microsoft crowd said that Java would allow Sun to finally make inroads against Microsoft's dominance of the desktop. But in the final analysis, Java was nothing more than a ploy to capture the public's interest and, in so doing, boost Sun's stock price. And it worked marvelously. Java's introduction in 1995 marked the beginning of what was essentially a five-year climb in the price of Sun's stock: $1,000 invested in Sun on July 1995 would have been worth $18,535 at the close of trading on December 30th, 2000. Now that's the power of Java.
Shares