AWT was also criticized for its "lowest common denominator" approach to GUI portability. AWT only provided the GUI features that were common to all of its platforms. [For example, Windows offers a spinner control with no equivalent in Motif; and the Macintosh only has one mouse button, while most other hardware platforms offer two or more.] JFC addresses this problem by providing a rich set of GUI components, including table controls, tree controls, image buttons, internal frames, and a Rich Text and HTMLcapable text editor framework.
JFC 1.1 includes the Swing GUI components, an accessibility API, and a pluggable lookandfeel architecture. This architecture enables applications to dynamically select the Windows, Motif, or the new Java lookandfeel ("Metal") at runtime. It is also possible to develop your own pluggable lookandfeel. Due to a licensing issue, the Windows lookandfeel is only available on Windows platfoms.
[Source: David Johnson, "Comparing WFC and JFC", Dr. Dobb's Journal, Feb 99, p90]
Architecturally, the Swing class library is similar to AWT. This is a great benefit to those migrating from the older technology to the new. Most Swing component APIs are similar and often the same as their AWT counterparts, so developers can quickly grasp Swing's basics and port older applications with relative ease. The Swing class hierarchy closely resembles the AWT hierarchy; the most noticeable difference is the addition of a "J" prefix.
All Swing components inherit from the JComponent class. Since JComponent extends the AWT container class, this implies that all Swing user interface components are containers. This offers some avenues for developers to create interesting applications by building up components inside components. For example, inserting a checkbox or graphic into a list element is a relatively simple operation with Swing, but is impossible with AWT. Swing's capabilities generally start where AWT leaves off, letting developers create more advanced applications faster than they could before.
[Source: Steven Gutz, "Getting into Swing", Software Development, Nov 98, p38]
The architecture of Swing components is based on the modelviewcontroller (MVC) paradigm. In a Swing component, models provide information that specifies the component's value, views manage the way in which the component and its data are drawn on the screen, and controllers modify the information maintained by the model in response to user input.
In actuality, Swing uses a modified MVC pattern, in which the view and controller are combined into a single component called the "delegate object". This reduces the number of communication paths between the model, view, and controller, and the number of components to be created and managed. In short, both the appearance and behavior of a component can be managed together, using just one delegate object. The delegate object encapsulates the lookandfeel of each Swing component.
[Source: Mukul Sood, "What is Swing?", Dr. Dobb's Journal, Sep 98, p111]
javax.swing.*is the "current" path to Swing
LookAndFeelare two different classes
LookAndFeelInfois an "inner class" of class
LookAndFeelis not an "inner class"
getName()returns an easy to read String
getClassName()returns a "fully qualified" String
setLookAndFeel()can return 4 different exceptions
main()will not exit without
swing.propertiesfile like the one shown at the bottom. ['#' is the comment character.]
References to "plaf" in the Swing library mean "Pluggable Look-And-Feel".