Disclaimer: 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
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.
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
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
- The directors of the firm hired to continue the credits after the other people had been sacked, wish it to be known that they have just been sacked.
I couldn't decide whether to laugh or cry when JavaSwing
was announced, in all its coolness: all lightweight components, with pluggable look-and-feel support. What a novel idea! Why didn't anyone think of that before!? Who ever dreamed up those peers anyway!?
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.
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
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
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.
- garden variety Windows users have rigid expectations of how GUIs should behave
The Windows users are actually relatively forgiving, having gotten used to basic UI components like the File/Open dialog changing with every "upgrade" or being re-implemented by vendors wanting something that works better for their application's domain. It's the MacIntosh
users who are the real tough cookies. Because Apple has retained such tight control over the UI toolkit, the consistency of interfaces across all apps is much greater. Never
argue look-and-feel with a MacZealot?
. -- StevenNewton