Swing provides a richer set of components than AWT. They are 100% Java-based.
AWT on the other hand was developed with the mindset that if a component or capability of a component wasn’t available on one platform, it won’t be available on any platform. Something quickly portable from platform x to y to z. Due to the peer-based nature of AWT, what might work on one implementation might not work on another, as the peer-integration might not be as robust. Many of the original AWT problems were traceable to differences in peer implementations.
This is not to say that there are fewer bugs in Swing, though most are out these days. It’s just that if a bug exists in Swing, it’s the same problem on all platforms, which was not the case with AWT.
[FAQ Manager Note] There are a few other advantages to Swing over AWT:
- Swing provides both additional components and added functionality to AWT-replacement components
- Swing components can change their appearance based on the current “look and feel” library that’s being used. You can use the same look and feel like the platform you’re on, or use a different look and feel
- Swing components follow the Model-View-Controller paradigm (MVC), and thus can provide a much more flexible UI.
- Swing provides “extras” for components, such as:
- Icons on many components
- Decorative borders for components
- Tooltips for components
- Swing components are lightweight (less resource-intensive than AWT)
- Swing provides built-in double buffering
- Swing provides paint debugging support for when you build your own components
Swing also has a few disadvantages:
- It requires Java 2 or a separate JAR file
- If you’re not very careful when programming, it can be slower than AWT (all components are drawn)
- Swing components that look like native components might not act exactly like native components