The Story Of Awt
The Story Of AwtDisclaimer: This is from memory. I didn't archive the mailing list where I watched all of this occur. I can't remember exactly what I read where. But my memory is usually pretty good, especially when it comes to names and the broad scope of events. This is my recollection of how JavaAwt happened, which explains part of why it's so terrible. -- GlennVanderburg
I received one of the first dozen or so copies of Java to be released outside Sun. I quickly became a convert, and spent much of 1995 reading the original Oak mailing list (whatever it was called) and then java-interest (after the name change).
The alpha version of Java contained an AWT that was different in many details from what we have now. The basic OO structure was the same, though, except for one huge difference: the components were all drawn and managed by Java code, in otherwise empty and featureless native windows.
Then came the beta release and, about the same time, the announcement that Netscape (then the single biggest mover on the Internet) had licensed Java. There were a few improvements to the AWT, but nothing earth-shaking; the goal of the first beta release was to fix problems they saw in the API, so that as few users as possible would be affected by the change. So there were some AWT API changes, but the basic object model stayed the same.
(Recall that, at this point, most people who were excited about Java were excited about applets, and Netscape was seen as the means for Java to gain acceptance. The Netscape license was the ticket to greatness!)
Netscape had a demand, though, before they would consent to put Java in their browser. These Java-based GUI components had to go. Java's GuiToolkit had to use the native widgets provided by the host window system, whether Windows, Motif, or the Mac. Mimicking the look-and-feel in Java wasn't good enough; it had to be the real native components.
So ArthurVanHoff? and SamiShaio? rewrote the AWT, virtually from scratch, in a very short timespan. (I seem to recall something like four weeks, although I have very little confidence in that memory.)
The result? Well, obviously the AWT would have been seriously flawed even had this not happened. But there were some unfortunate results from this. First, many of the flaky behaviors that today's AWT must maintain compatibility with stem from this rewrite. A system that, for all its weaknesses, had been in use for a couple of years, was replaced by something written "in an entirely different style at great expense and at the last minute," just like the credits for Monty Python and the Holy Grail. The peer architecture (making it impossible to create a new AWT component purely in Java) was a part of the rewrite. And finally ... who knows what Arthur and Sami might have been able to spend their time on had this not happened?
Without the peers in the way, many of the problems could have been fixed much more easily.
Almost as soon as Java 1.0 was released, there was talk of enabling "lightweight components" -- AWT components just like the older ones, with no native peers, drawn and controlled entirely by Java code. Basic support for such components was one of the heralded features of Java 1.1. Netscape waned, their Java support lagged, and it was difficult to remember why their demands had been so important.
And then the plugin: applets can be run by a plugin, so that we don't have to depend on Netscape's awful Java port or Microsoft's splintering tactics. (Netscape introduced the APPLET and EMBED tags in the very same release of Navigator. Did anyone else ever wonder why Java support wasn't plugin-based from the very start?)
How the worm turns.
It's interesting to note that nowadays TheMozillaProject absolutely will not use native widgets (in their non-Java-based portable user interface), because (at least as far as I've gathered) they are notoriously buggy, they make it difficult for webmasters trained in the pixel-pushing school, etc. etc. Interesting to see them turn around like that. -- MattBehrens
And this is why Mozilla's UserInterface is painfully slow and non-standard.
Though it's still possible Mozilla will become popular in spite of this.
-- EricUlevik
Really, all it needed was performance tuning. Today's Mozilla is responsive, perhaps even bordering on snappy. Grab a nightly and check it out. Just don't get NetscapeSix?... bleargh. -- MattBehrens
Not snappy on a 400 MHz, and I don't see the point in springing for new motherboard just to run a Web browser. -- DavidBrantley
Here is another angle on this. My original reaction to JavaAwt, like that of many other people, was that it was a toy. It wasn't nearly as powerful as the GUI framework with VisualWorks, and I knew that there were better GuiFrameworks than that. But one of the advantages of toys is that they are easy to play with. AWT was easy for people to learn, and soon millions of people had used it to build simple apps. It didn't take long for them to realize the limitations of AWT, but by then they had been sucked into the Java world. Swing is much more powerful (and complex) than AWT, but now there are millions of people to help new converts. In the mean-time, the better frameworks have a much smaller number of users. It is another example of WorseIsBetter. -- RalphJohnson
And the wheel continues to turn. This argument went back to the old days of Smalltalk (which was better -- VisualSmalltalk because it used native widgets, or VisualWorks because it didn't use native widgets)? Well, we found out in Smalltalk that either one would work, at about the same speed. Now, the same argument is coming up again in Java with the introduction of IBM's JavaSwt which embodies the "native widgets" approach for Java. SWT is used in the EclipseIde and is widely credited as being one of the reasons the Eclipse user interface is snappy -- or not... -- KyleBrown
Interestingly, IntellijIdea uses Swing. Most people I mention that to are surprised at how responsive and clean it is.
Idea demonstrates the best use of Swing I've seen so far, but anyone that isn't annoyed by its sluggishness has probably been using Java apps so long they've forgotten what quick feels like.
Yet another angle on this. AWT, even with native widgets, failed to emulate the look and feel of standard Windows apps. Swing fails harder at this. This may not seem like a problem to developers accustomed to using a variety of GUIs, but everyday garden variety Windows users have rigid expectations of how GUIs should behave. The WriteOnceRunAnywhere premise is fundamentally flawed because it assumes that anywhere can be made to look the same as anywhere else from the application's perspective.
EditText of this page
(last edited September 25, 2007)
or FindPage with title or text search