Get ready to Swing (1.0)

The Java look and feel goes Organic -- and it adds a new default, cross-platform look

As you probably already know, the JavaSoft Swing 1.0 component group is set to appear late this month (February 1998). The Swing components are an extension to the Lightweight UI (user interface) Framework, which itself became a part of the Java AWT (Abstract Windowing Toolkit) when JDK 1.1 was introduced. One of the most important features of the Swing component set, which will be fully incorporated with Java 1.2, is its pluggable look-and-feel (L&F) architecture. This feature allows developers to choose from several preset L&Fs, or craft their own custom appearance and behavior for controls.

A look back at the pre-release Swing

The pre-release Swing, announced at the 1997 JavaOne conference and available to developers since July 1997, contains three pre-defined L&Fs:

  • Java (the original cross-platform L&F)
  • Motif
  • Windows 32-style

In the 1.0 release, the Java L&F will be renamed the Organic L&F and will include two color schemes, Santa Fe and Vancouver, not available with the pre-release Java L&F. Users of pre-release version who continue to use this L&F will have to substitute OrganicLookAndFeel for JLFLookAndFeel in code statements.

The Organic L&F, Santa Fe style
The Organic L&F, Vancouver style
The Motif L&F
The Win32-style L&F

Feedback from users of the pre-release versions of Swing (and specifically on the Java L&F) provided the design team with many ways to enhance the Java L&F for Swing 1.0. Following are some of the changes made to the Organic (neé Java) L&F.

  • Color schemes -- The Swing engineers added earth-tone Santa Fe and gray-tone Vancouver Java-looking color schemes to the Organic L&F to satisfy beta users' requests. The L&F encapsulates color information about the current UI into a Theme object, that the application can apply by using the setCurrentTheme() method. Expect Theme objects to encapsulate more than color schemes in future versions of Swing.

  • Tabbed panes -- Also from feedback, Swing engineers changed the appearance of tabs in tabbed-pane windows to better resemble folder or notebook tabs. The tabs no longer shuffle around when you select one (most developers liked it this way). Also, the justified full-width-of-window tab bug has been corrected.

  • Combo boxes -- Even though they retained most of the look of combo boxes, the engineers did make slight design modifications enabling the addition of visual clues so developers will know at a glance whether a combo box can be edited or not.

  • Scroll bars and other enhancements -- Because developers are decidely split on the rollover effect of scroll bars, no scroll bar changes have been implemented at this time. radioButtonMenuItems and checkBoxMenuItems have been enhanced. And sliders now come in filled and unfilled versions.

The Motif and Windows 32-style L&Fs are pretty straightforward. There is a locking method on the Windows L&F that keeps it from working on non-Windows platforms -- Microsoft hasn't granted JavaSoft the rights that would allow Sun to offer the Windows L&F for other platforms.

Swing 1.0 gets a new look (actually, two!)

JavaSoft is planning two additional L&Fs for Swing 1.0. The Symantec Visual Café development team and Apple engineers helped JavaSoft design the Macintosh L&F. And the JavaSoft design team has crafted a new default, cross-platform L&F (known as the Metal L&F).

The Macintosh L&F
The Metal (default) L&F

Metal was created as a compromise between the burden of overamped 3D design and the need for some sort of 3D effect to provide visual cues. Many users complained about the "bumpiness" of 3D bevels, especially on buttons in toolbars. So the designers went for an "etched" or "flush" 3D look, eliminating some of the visual clutter while still providing visual clues as to the state of the element.

The traditional, 3D bevel look (top) versus the new Metal L&F "etched" look

Also, since Metal is the new default L&F in Swing 1.0, it was designed with a simpler color model than the pre-release default, so it won't develop color-mapping problems from platform to platform. (For more on the Metal design, see "Metal design highlights" in Resources.)

According to JavaSoft officials, the Macintosh L&F won't be available when Swing 1.0 makes its debut later this month, but it should follow soon after. Also, because Metal is the new default cross-platform L&F, the Organic L&F (Vancouver and Santa Fe) will be available for downloading, but won't be bundled in Swing 1.0.

Swing's place in the JFC

Swing components support the JavaBeans event model, which means they can work "out of the box" in applications and IDEs that support beans. In JDK 1.1 (and forward), Swing is one of the five APIs that make up the Java Foundation Classes (JFC). The others are:

  • The Abstract Windowing Toolkit (AWT) -- A GUI-development toolset that serves as a foundation for many Swing classes.

  • Java 2D -- A set of classes for advanced 2D graphics and imaging; the API is based on technology from IBM/Taligent.

  • The Accessibility API -- An assistive technologies interface, designed to help people with disabilities interact with JFC and AWT components through such features as screen magnifiers and audio text readers.

  • Drag and Drop -- Based on the JavaBeans "Glasgow" specification, this technology allows data to be shared between Java and native applications, between different Java applications, and within a single Java application.

Swing component classes

Swing is implemented by three elements of the JFC:

  • UI classes -- A set of components that descended from JComponent (which descended from AWT's Container class). The hierarchy lets Swing components contain other components, which allows developers to nest components.

  • Non-UI classes (1) -- Swing-related support classes that don't create visible onscreen Swing components, but provide services to the Swing API.

  • Non-UI classes (2) -- A set of Swing-related interfaces that are implemented by Swing's component classes and support classes.

The UI classes are responsible for the pluggable L&F, component extensibility, keyboard-stroke trapping, component border customization, tool tip support (short descriptions of components), auto-scrolling, and debugging and localization support.

The Swing widgets can be used to specify exactly how a GUI appears, regardless of the underlying platform. The Swing components work atop the Java 2D, Accessibility, and the Drag and Drop APIs in the JFC.

Many of the Swing components are all-Java versions of such AWT components as button and scrollbar. Plus, Swing includes higher-level Java components such as tree-view, list-box, and tabbed-pane, none of which were available in the original AWT API.

Besides the preset L&Fs, Swing provides a toolset that allows applications to automatically implement custom L&Fs for any operating system. The Swing toolset is a comprehensive library of more than 250 classes (twice as many as are found in AWT) and more than 75 interfaces for creating lightweight, Java GUI components.

The Swing packages

Swing bundles its classes and interfaces into packages. The existing and upcoming Swing 1.0 packages are listed here:

  • The Accessibility package defines a contract between Java UI objects (such as screen readers and Braille terminals) and screen-access products used by people with disabilities.

  • The Swing component package, the largest package, implements all the component classes used in Swing (with the exception of JTableHeader and JTextComponent). The UI classes (which begin with the letter J) are used to implement components; non-UI classes provide services and functionalities to applications and components.

  • The basic package, the second largest package, defines the default L&F characteristics of Swing components.

  • The beaninfo package defines the SwingBeanInfo class, which provides default implementations of the getIcon() and getDefaultPropertyIndex() methods. It also provides default implementations for utility methods, such as createPropertyDescriptor(), which makes it possible to write BeanInfo implementations.

  • The border package consists of one interface and nine classes that you can subclass when you want to draw a specialized border around a component.

  • The event package defines Swing-specific event classes, in a similar manner to that of the java.awt.event package. This package is especially useful if you need to craft a component to monitor another component.

  • The multi package contains Swing's Multiplexing UI classes, which permit the creation of components from different UI factories.

  • The pluggable L&F package delivers pluggable look-and-feel capabilities.

  • The preview package will contain the JColorChooser and JFileChooser components in Swing 1.0.

  • The table package contains several low-level classes used to help you build, view, and manipulate tables.

  • The text package contains classes and interfaces that deal with text components.

  • The HTML package has an HTMLEditorKit class that implements a simple text editor for HTML text files.

  • The RTF package implements a simple text editor for rich text format files.

  • The tree package contains classes used to create, view, and manage tree components.

  • The undo package contains classes and methods designed for undo capabilities.

What's new in Swing 1.0

As expected, Swing 1.0 will include several new and enhanced features. In this section we'll take a look at the more important additions.

The big change to the JTable API in Swing 1.0 will be the removal of the DefaultCellRenderer, originally designed to act as an all-purpose default renderer for the JList, JTree, and JTable classes. Each of those classes now has its own specialized renderer.

The JTabbedPane class in Swing 1.0 will be getting a new tabPlacement property to allow developers to put tabs at the top, left, bottom, or right of a tabbed-panes content area. Also, this class will get two methods to control whether a tab is enabled or disabled; several methods to set individual foreground and background tab colors; an individual tab current-bounds return method; and a method that returns the current number of tab runs displayed.

In the JComponent class, the getClientProperties(), and setClientProperties() methods will be removed. The clientProperty will be bound.

The JDialog class used to use a fake "modality" for dialog classes as a workaround for the AWT 1.1 limitation (that windows can't be parented from Dialog objects). This meant that components that created Windows objects, like the JPopupMenu and JComboBox, didn't work when placed in real modal dialogs -- input to them was blocked. This, in turn, also blocked input to other windows, which caused applet security exceptions because the object didn't have direct access to the system event queue.

Swing 1.0 modifies JDialog to use true AWT modality. And for Swing components that contain popups, Swing 1.0 constrains components so that they always use lightweight popup menus when they are placed inside modal dialogs.

A Swing(ing) design philosophy

To close, maybe a look at the JavaSoft design team's philosophy is the best way to get a glimpse of how Swing may evolve. The Swing implementation team adheres to the following philosophy when it comes to designing, tweaking, or updating an industrial-strength, cross-platform user interface:

  1. Create a unique appearance and identity without logos
  2. Enable easy skills transfer from other GUI designs
  3. Emphasize content more than component bells and whistles
  4. Eliminate clutter and needless decoration from the UI
  5. Fix common problems with existing components
Kane Scarlett is a contributor to JavaWorld and NC World magazines, as well as the executive editor of NC World.

Learn more about this topic

  • What is Swing?
  • The Swing toolset
  • The Swing Connection online newsletter
  • Metal design highlights
  • Regular JavaWorld columnist, Todd Sundsted, demonstrates the power of Swing's lightweight components in "Put your user interface on a diet" (JavaWorld, March 1997)