JFC

"The term Java Foundation Classes (JFC) refers to a collection of features that are included in, or can be used with, version 1.1 of the Java Development Kit (JDK) together with some new features introduced by JDK 1.2." [Topley, pxix] Altogether, it consists of:

Swing components
Desktop Colors feature of JDK 1.1
Printing facility of JDK 1.1
Java2D API (enhanced text, color, and image support)
Accessibility (support for technologies that target users with disabilities)
Cutandpaste and clipboard facility of JDK 1.1
Draganddrop facility of JDK 1.2

Sun created the JFC to address the widely acknowledged problems with Java's original AWT user interface toolkit. AWT was based on the native GUI components (known as "peers") of each platform, and this caused subtle but problematic variations in behavior and lookandfeel from platform to platform. JFC addresses this problem by avoiding the use of peers altogether. JFC components are written in pure Java to ensure identical behavior across all platforms. JFC provides pure Java or lightweight components to replace all of the fundamental GUI components found in AWT, such as buttons, edit fields, combo boxes, radio buttons, scrollbars, and menus.

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]

Pluggable Look-And-Feel

The example at the right demonstrates how to query, get, and set Swing's look-and-feel capability. Notice that:

javax.swing.* is the "current" path to Swing
classes LookAndFeelInfo and LookAndFeel are two different classes
class LookAndFeelInfo is an "inner class" of class UIManager
class LookAndFeel is 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 System.exit(0)

The JVM's default look-and-feel can be set by creating a swing.properties file like the one shown at the bottom. ['#' is the comment character.]

References to "plaf" in the Swing library mean "Pluggable Look-And-Feel".