Design Goals for Swing
- Be implemented entirely in Java to promote cross-platform
consistency and easier maintenance.
- Provide a single API capable of supporting mulitple
look-and-feels so that developers and end-users would not be
locked into a single look-and-feel.
- Enable the power of model-driven programming without requiring it in the
highest-level API.
- Adhere to JavaBeans design principles to ensure that components behave
well in IDEs and builder tools.
- Provide compatability with AWT* APIs where there is overlapping, to leverage
the AWT knowledge base and ease porting.
A Visual Index to the Swing Components
Sun's Component Gallery
Swing API
Component Overview
Java Look and Feel Specification
Differences between Swing and the AWT components
- Programs should not, as a rule, use "heavyweight" components alongside Swing components. Heavyweight components include all the ready-to-use AWT components (such as Menu and ScrollPane) and all components that inherit from the AWT Canvas and Panel classes. This restriction exists because when Swing components (and all other "lightweight" components) overlap with heavyweight components, the heavyweight component is always painted on top. For more information, see Mixing Heavy and Light Components, an article in The Swing Connection.
- Swing components aren't thread safe. If you modify a visible Swing component -- invoking its setText method, for example -- from anywhere but an event handler, then you need to take special steps to make the modification execute on the event-dispatching thread. This isn't an issue for many Swing programs, since component-modifying code is typically in event handlers.
- The containment hierarchy for any window or applet that contains Swing components must have a Swing top-level container at the root of the hierarchy. For example, a main window should be implemented as a JFrame instance rather than as a Frame instance.
- You don't add components directly to a top-level container such as a JFrame. Instead, you add components to a container (called the content pane) that is itself contained by the JFrame.