 |  |  |  |  |  |  |  |  |  |  |  |  |  |
|
 Does Java suck? I
t was predictable, really. When Java first hit the Net, it was snapped up by a bored cyberpublic and billed as the greatest thing since Jolt cola. Then, this summer, the reaction set in and a round of Java bashing began.
The catalyst was the news that Corel Corp. had scaled back its ambitious effort to create a Java-based suite of office applications. That prompted a stor y in The Wall Street Journal that pegged Java as a problem-ridden programming language. The debate has spilled over to the technical community, where, "Does Java really suck?" was the prominent theme recently of one newsgroup, comp.lang.java.advocacy . Such activity might foster the impression that early advocates of Java are beginning to head for the exits. In reality, nothing could be further from the truth. Sure, Java has problems. Most troublesome have been concerns about the performance of Java, which suffers in comparison to existing high-level languages. Anecdotal reports peg Java applications at from two to 40 times slower than equivalent programs written in C++. The drag comes because Java isn't compiled--that is, converted before run time directly from source code into machine code. Instead, Java is translated into an intermediate form--called byte-codes--which then must be interpreted before execution on a target microprocessor. On the plus side, the use of byte codes gives Java its vaunted platform independence, because byte-codes can run on any CPU equipped with a software-based Java Virtual Machine. But the negative is the drag in performance--something that's made worse by Java's extensive reliance on bloated "packages," or software libraries that enable the language to implement graphics, printing and input/output features. There are two other technical issues that are bogging Java down. First is the lengthy and unpredictable process through which Java performs garbage collection--the freeing up of memory locations no longer needed by a program. Second is the drag caused by laggard context-switching times, which makes it difficult to ensure that interrupts will be swiftly serviced in real-time applications. Understandably, Sun isn't terribly eager to talk about Java's shortcomings. But if you ask company officials, they will tell you they're working hard to fold improvements into the language. Sun already owns the most important ingredient: the "Hot Spot" optimizing compiler, which will appear in the next version of the Java Virtual Machine. Sun acquired the technology through its purchase, this past February, of Longview Technologies (Palo Alto, Calif.). The compiler will enable developers to analyze their applications to find slow-running blocks of code that would then be run through the compiler, so that they could execute at the speed of the processor. On the garbage-collection front, Sun is developing improved techniques that promise to reduce delays caused when Java pauses to perform its memory-scavenging operations. The third bugaboo involving context-switching times will be tougher to get a grip on and may be addressed very soon. However, Sun has some breathing room here, since the issue is of conce rn mainly to developers of "hard" real-time applications. So, if you're not already testing the Java waters, it's time to start. Java will remain a worthwhile pursuit for professional programmers, as well as a solid resume highlight for years to come. Besides, the computer industry's alternative--C++, a ponderously complex language with which it's impossible to write clean code--is too horrible to contemplate.
|
| ||||||||||||||||
