What is Swing?

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.

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.