The Source for Java -
The Pluggable Look And Feel

[Home] [What is it?] [Overview of Features] [API Reference]
[FAQ] [Examples] [Changes] [Compatibility table] [JFC Home Page]

Explanation of the Pluggable Look and Feel

The JavaTM Foundation Classes "Swing" user interface building blocks are designed around a Pluggable Look and Feel architecture that allows us for the first time to get away from interpreting the visual manifestations, and instead "plug in" a non-visual manifestation. This architecture separates the expression of the user interface from the underlying structure and data on a component-by-component basis. This is accomplished by separating the user interface of the component from the "model" of the component (the structure which encapsulates the state and information that the user interface portion presents to the user).

Prior to the Pluggable Look and Feel, the non-mainstream user had two options: specialized software closely tailored to their non-mainstream modality (e.g. a talking web browser), or a specialized access application (e.g. a screen reader) which interpreted and re-presented the visual presentation of mainstream applications. With the Java Foundation Classes and Swing, we now have a third option:  direct presentation in non-mainstream modalities of mainstream applications.

How the Swing classes provide a Pluggable Look and Feel

For each component in Swing, there are actually (at least) five Java programming language objects that are needed to make that Swing component pluggable. These are: the component itself (e.g., a button); the Java programming language interface that defines the user interface (e.g., the button's UI); a default implementation of that user interface (e.g., the Basic Button); a Java programming language interface that defines the model of the component (e.g., the Button model); and finally, a default implementation of that model (e.g., the Swing Button model).

For most uses of a given Swing component (e.g., a Button), the programmer doesn't need to know or care about any Swing object other than the first of the five listed above. The programmer simply creates a new instance of the first object of the five, and writes code to interact with it. The others are created automatically based upon the settings on the user's machine. By default, the choice of which user interface and model to use is made in the user's preferences files, where an entire "factory" of user-interfaces and models is specified by the user.

What Swing provides

In order to make it easy to migrate from the user interface classes in the AWT to the new Swing user interface classes, Swing provides a parallel set of user interface classes to those in AWT. Each Swing class that has a parallel in the AWT bears a name that is identical to the AWT name, except that the letter "J" is prepended to it. Otherwise, each parallel user interface object contains a superset of the public methods and variables of the corresponding AWT class. There are roughly 55 user interface building blocks in Swing, including the common items such as buttons, check boxes, radio buttons, combo boxes, menus, and labels, as well more sophisticated items such as tooltips, tabbed panes, tree views, table views, editable text fields, HTML editors, a Color Chooser, a Money Chooser, etc. Each of these Swing user interface classes fully supports the Pluggable Look and Feel architecture.

Providing Direct Accessibility in Swing

In order to get direct access to a Swing program via a non-mainstream modality (e.g., audio, Braille, etc.), the user would need a factory containing a set of user interface classes installed on their system for each of the Swing classes listed above. Then the user would need to specify that this replacement set be used in the appropriate properties file. Finally, the user would need to run Swing programs that didn't explicitly bar the use of alternate user interface factories.

In setting this up, the user has three options: complete replacement of a mainstream user interface with their alternate one(s); having the mainstream interface and the alternate interface(s) working simultaneously (e.g., visual and audio) through the use of the special multi-plexing user interface factory supplied by Sun; or finally, by choosing on a component-by-component basis which user interface class to use.

Java LogoCopyright© 1995-99 Sun Microsystems, Inc. All Rights Reserved.
To submit comments or suggestions about Java Accessibility, please send mail to



Sun MicroSystems