Last week we gave some tantalizing information about the newly beta-released version of Java. This week, we're going to start a real survey of what's there and where Sun seems likely to be going with it. A Survey of the New Java
The list of additions and changes is substantial, and in many cases the improvements are even more rewarding than we expected. As a product hastily adapted to an unanticipated task, and perhaps too hastily brought from beta to final release, there were undebatably some aspects of Java that needed attention. We're happy to say that, for the most part, they got it in version 1.1.
Our informal survey indicates that the AWT was among the most roundly criticized areas of the 1.0 Java release. In the new version, it's been largely rewritten. With predictable sensitivity to market forces, the most attention was lavished on the 32-bit Windows implementation of the package. Windows users got a complete Peer rewrite--in other words, the Java "interface" to the native graphical environment was redesigned and, to our initial inspection, greatly improved. The emphasis was primarily on speed, but the changes ran deep; there were some far-reaching design changes made that warrant close examination.
For our own part, we felt the AWT to be a considerable improvement relative to the kind of interface programming we've had to do in the past, and a laudable piece of work given the amount of time it must have been accomplished in. But of the current crop of forward-thinking developers, few were satisfied. Certainly, it had its share of bugs and foibles, many of which have been the bain of those already developing seriously in Java. Some have claimed that the bugs in the AWT alone are enough to belie Java's claim to platform independence.
So aside from paying heed to the incessant chant of the user community ("Faster, faster, faster"), there were a number of worthwhile class additions: Several new interface components, better sensitivity for the host system's look and feel, support (after a fashion) for clipboard functionality, and the much overhyped drag-and-drop capability, as well as printing features, are all included in the update. And, as we've mentioned, the event-handling model that we were at such pains to describe earlier in the year has been replaced with something, if possible, even more interesting. No doubt we'll devote a few more weeks to events as version 1.1 passes out of beta and into the next Netscape release.
To summarize briefly what's treated in great depth in the features document, events are no longer represented by an individual Event class; a more complex hierarchy of classes replaces it. Interface components no longer simply inherit sensitivity to their user's actions--they register to receive them. We'll dive deeper into this later, when we have time to devote the proper amount of attention to it.
Speaking of the ever-present demand for speed, we discovered this need for speed was high on everyone's list. Many who were otherwise eager to get involved with Java derided it for having made too many efficiency compromises to achieve platform independence. Although our own experiences show many of the major speed problems with large applets to be localized in one or two specific (and improvable) areas, we were forced to agree. Naturally, Sun had been making the problem of efficiency a specter for its development people since before the project began. As everyone knows, Sun has been one of the worst offenders (next to Microsoft) in producing bloated and ridiculously inefficient commercial code, which is one of the reasons its release of Java was so startling and refreshing.
This much anticipated pressure provoked a rewrite of the JVM "interpreter loop" almost entirely in assembly for both Intel and Sparc platforms, as well as a few other clever (although obvious) performance tricks, especially where memory handling and garbage collection were concerned.
Then there came the improvement we liked the best, the JAR file. It didn't take Java developers long to discover what is perhaps one of the largest practical problems with Java applets on the Web: loading speed. The applet, comprising over a dozen classes (let alone subsidiary data files of other types), can take absurdly long to load. The class loader in Netscape's Java interpreter loads each required item single-file, each with a separate (and costly) network transaction. While we were expecting a loader that was simply better optimized and capable of concurrent, multithreaded loading, what we got was the ability to enclose an entire applet, so to speak--classes, data, images, and all--into a compressed archive file. The result, we're told (although experimentation hasn't yet completed bearing it out), is dramatically increased speed. This is great news, if it's true. Time will tell.
Next week, we'll have more to say about the new Java. In closing, we don't want to leave you with the impression that we found everything in these new developments to be rosy. On the balance, we saw the mark of the same ingenuity that Java seems to have been born out of (and we have plenty more good news for you), but there are a few disturbing features that seem decidedly lacking in the aggressive simplicity and cleverness that we've come to expect from the Java team. Until next week . . .
