I've recently been experimenting with AWT instead of Swing in Java. AWT is the "original" GUI widget toolset, and it essentially ties straight to the native GUI widgets of the Java virtual machine's host platform. Using it, you can't help but have a "native look and feel".

AWT was the "obvious" way to create GUIs at Java's birth. Grabbing native widgets saves you the extra programming of making something new. But this missed Java's goal to write once and run anywhere [with essentially the same feel, which is part of running [the same] anywhere].

Thus Swing was born. Now Java had a GUI toolkit that could "look like Java", the Metal Look and Feel, no matter where it was run. Swing made Java its own platform, and you could really feel like you weren't primarily running Windows or Linux or Solaris or Mac OS when you were using a Java application. The underlying OS really was just a foundational layer, and everything from server-side apps to the most complex GUI wouldn't care if you had one, two, or three buttons on your mouse. More importantly, developers could code knowing that if the Java L&F (Metal) worked on their dev platform, it'd likely behave in the same fashion anywhere.

What's more, because Swing is skinnable, look and feels that imitated native widgets on each OS coiuld be -- and were -- created as well. The Windows and Mac L&Fs are found only on that platform, b/c the look is copyrighted, but Motif for *NIX is found everywhere, though that's no cause for celebration! Finally, full GUI functionality, occasionally better than the native host's, ready crossplatform without more than one line of code changed to go from a generic look to a native one. Or back. Swing appeared to be the perfect solution, and for a while everyone was using/trying Swing.

Strangely, there is now another player for creating widgets in Java, IBM's SWT (example). SWT is doing exactly AWT was doing, but for a much different reason. SWT is trying to provide better performance than but the same functionality you'd find in Swing in a "pure Java" solution across OSes, but again using native widgets and a native-only look.

But if SWT is essentially just AWT, conceptually, at least, what's the reason for bothering?

Recently I had a fellow tell me his spin on what happened, and it's so obvious it can't help but be right. AWT development died at Sun about 140 computer-years ago at Sun. They can't kill AWT itself, as Swing is built on top of AWT; Swing extends AWT for its foundation. But Swing has so many more mature widgets in its bag than AWT could ever hope to claim (click on the button at the top), that we can quickly see the suggestion I got was on the money.

Why, then, doesn't IBM just contribute to AWT? Ha! That's funny. Sun's got it all closed up, licensing wise, afaik. And IBM is also trying to do something fancy that makes the method they summon up SWT's copies of the native widgets differnt than AWT's.

Anyhow, there you go, three types of GUI widgets for Java. I was initially blogging to suggest that you take another look at AWT and see if you can't get away with those widgets -- SWT requires a separate install and a relatively recent JVM; Swing requires a 1.2 JVM or a lot of coaxing/separate install. AWT based apps can run on WindowsXP and 2k right out of the box. No, really. Using AWT means you'll also have, as the same fellow suggested, an inside track on keeping things simple enough for the "Micro" edition of the JVM. But I'm not going to argue that now. The intro was much too long, and I'm tired o' blogging for now, bion.