ajtgarber wrote:Isn't it the other way around, that AWT is the lightweight while Swing is the heavy weight?
No, Swing is referred to as lightweight, and AWT is referred to as heavyweight.
All the drawing of heavyweight components are handled by OS calls. While this can sometimes result in a faster program, there are drawbacks. The framework is not guaranteed to work identically across all platforms, one OS may contain features that another doesn't, and for a cross-platform language, development is limited to what features are shared between platforms. Classes from the AWT toolkit aren't as extensible as their lightweight counterparts, and because drawing is handled by the OS, there is no way to manipulate the way a component is painted on the screen (e.g., Rotating a button).
ajtgarber wrote:Swing uses AWT internally but just adds extra features. Yes AWT is implemented natively on each different platform but thats the only way that Java can open a window.
That's correct, the top-level Swing components rely on being heavyweight in order to create a visible space that can be drawn to, while all other Swing components are painted in pure Java, but still subclass AWT for simplicity, compatibility (mixing heavyweight and lightweight components), and ease when porting historical code.
Lightweight components allow your programs to look and feel the same across platforms. You can modify the opacity and shape of lightweight components, or transform, add to, and even completely change the look and feel of existing components using the Java 2D API. Using Swing in games can allow you to create and maintain
pluggable look and feels that are attractive and compliment your game, instead of looking awkward and out of place.
The eye-candy that can be made with the Swing framework is only limited by your imagination. For example, you may call a component's paint methods while passing in a Graphics object as a parameter that may be used by a texture that has been applied to a shape within a scene graph, essentially making 3D components (with some clever event dispatching, of course), which can be useful when you really need to woo rich clients.
ajtgarber wrote: If you've ever use the JFileChooser or pretty much any Swing dialog/window you almost always notice that it takes an extra few seconds to come up, but if you were to do the equivalent in AWT it would almost instantly pop up.
In most cases, the performance increase of heavyweight components is negligible. JFileChooser on the other hand, has been
reportedly slow, but you can use FileDialog if it fits your needs.
When choosing which API you want to use (and you may not always get to), you should pick the one that satisfies your projects needs the best.