Swing gone crazy

An article I saw yesterday on the SWTSwing project, which attempts to allow you to program to the SWT interfaces but really use Swing underneath, brought back a lot of bad Java GUI memories for me. Here is how I remember the big mess that has been made of Java on the client side:

In the beginning - Java 1.0 - Java supported GUI components as part of its core library. At the time this was fantastic because most of the other competing languages did not provide a "standard" GUI package. The Java GUI framework was called Abstract Window Toolkit (AWT).

Now, AWT had its limitations. It only supported a few of the most common widgets. It also had threading issues - all of the AWT components are updated from a single event thread, so you have to jump through a few hoops to get updates from another thread on to the AWT thread (NOTE: this is common in GUI frameworks, including .NET forms). And most serious from Sun's point of view (and IBM complained a lot about it as well) was that AWT was built on top of "native" widgets, which look different on different operating systems.

Sun's solution - with more than a little help from IBM - was Swing. Swing had lots of widgets - menus, popups, sliders, you name it. Threading was solved by implementing a MVC pattern. And the different look on different operating systems problem was solved by "drawing" (simulated) each Swing widget so that it looked identical on each operating system.

Swing, however, was painfully slow. Most of the blame was attributed to the widgets have to draw themselves line-by-line, pixel-by-pixel, although I reckon some of the internal implementation was just badly done.

So a few years went by without Sun doing much to improve the performance of Swing. There were a few religious wars over native widgets vs simulated widgets, but Sun stuck to their guns when it came to ensuring the same look and feel across all operating systems.

Finally IBM - cohorts in the creation of Swing - went a different direction and created SWT, which was based on top of native widgets. And it didn't have any MVC support. SWT was used as a foundation for Eclipse.

A couple of years ago RedHat decided to support Java in a big way. In particular they wanted to add Java compiler support - actually compile Java programs to assembler - to the fantastic gcc and be able to run Eclipse on Linux. One major stumbling block to this ambition was getting Swing to run natively. Since SWT was implemented on top of native widgets it worked pretty much straight away with gcc. So along comes the SwingWT project which implemented the Swing interfaces on top of SWT.

And as I said at the top of this post SWTSwing implements SWT on top of Swing. And now SWTSwing is integrated with SwingWT, which is "great for those places where you want native if available, but can fall back to Swing if not".

When will this madness end! (Particularly now that Swing in Java 5 is actually pretty speedy and looks ok.)