Module java.desktop
Package javax.swing

Class UIManager

java.lang.Object
javax.swing.UIManager
All Implemented Interfaces:
Serializable
public class UIManager extends Object implements Serializable
UIManager manages the current look and feel, the set of available look and feels, PropertyChangeListeners that are notified when the look and feel changes, look and feel defaults, and convenience methods for obtaining various default values.

Specifying the look and feel

The look and feel can be specified in two distinct ways: by specifying the fully qualified name of the class for the look and feel, or by creating an instance of LookAndFeel and passing it to setLookAndFeel. The following example illustrates setting the look and feel to the system look and feel: 
   UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());
The following example illustrates setting the look and feel based on class name: 
   UIManager.setLookAndFeel("javax.swing.plaf.metal.MetalLookAndFeel");
Once the look and feel has been changed it is imperative to invoke updateUI on all JComponents. The method SwingUtilities.updateComponentTreeUI(java.awt.Component) makes it easy to apply updateUI to a containment hierarchy. Refer to it for details. The exact behavior of not invoking updateUI after changing the look and feel is unspecified. It is very possible to receive unexpected exceptions, painting problems, or worse.

Default look and feel

The class used for the default look and feel is chosen in the following manner:
  1. If the system property swing.defaultlaf is non-null, use its value as the default look and feel class name.
  2. If the Properties file swing.properties exists and contains the key swing.defaultlaf, use its value as the default look and feel class name. The location that is checked for swing.properties may vary depending upon the implementation of the Java platform. Typically the swing.properties file is located in the conf subdirectory of the Java installation directory. Refer to the release notes of the implementation being used for further details.
  3. Otherwise use the cross platform look and feel.

Defaults

UIManager manages three sets of UIDefaults. In order, they are:
  1. Developer defaults. With few exceptions Swing does not alter the developer defaults; these are intended to be modified and used by the developer.
  2. Look and feel defaults. The look and feel defaults are supplied by the look and feel at the time it is installed as the current look and feel (setLookAndFeel() is invoked). The look and feel defaults can be obtained using the getLookAndFeelDefaults() method.
  3. System defaults. The system defaults are provided by Swing.
Invoking any of the various get methods results in checking each of the defaults, in order, returning the first non-null value. For example, invoking UIManager.getString("Table.foreground") results in first checking developer defaults. If the developer defaults contain a value for "Table.foreground" it is returned, otherwise the look and feel defaults are checked, followed by the system defaults.

It's important to note that getDefaults returns a custom instance of UIDefaults with this resolution logic built into it. For example, UIManager.getDefaults().getString("Table.foreground") is equivalent to UIManager.getString("Table.foreground"). Both resolve using the algorithm just described. In many places the documentation uses the word defaults to refer to the custom instance of UIDefaults with the resolution logic as previously described.

When the look and feel is changed, UIManager alters only the look and feel defaults; the developer and system defaults are not altered by the UIManager in any way.

The set of defaults a particular look and feel supports is defined and documented by that look and feel. In addition, each look and feel, or ComponentUI provided by a look and feel, may access the defaults at different times in their life cycle. Some look and feels may aggressively look up defaults, so that changing a default may not have an effect after installing the look and feel. Other look and feels may lazily access defaults so that a change to the defaults may effect an existing look and feel. Finally, other look and feels might not configure themselves from the defaults table in any way. None-the-less it is usually the case that a look and feel expects certain defaults, so that in general a ComponentUI provided by one look and feel will not work with another look and feel.

Warning: Serialized objects of this class will not be compatible with future Swing releases. The current serialization support is appropriate for short term storage or RMI between applications running the same version of Swing. As of 1.4, support for long term storage of all JavaBeans has been added to the java.beans package. Please see XMLEncoder.

Since:
1.2