Class LookAndFeel
LookAndFeel , as the name implies, encapsulates a look and feel. Beyond installing a look and feel most developers never need to interact directly with LookAndFeel . In general only developers creating a custom look and feel need to concern themselves with this class.
Swing is built upon the foundation that each JComponent subclass has an implementation of a specific ComponentUI subclass. The ComponentUI is often referred to as «the ui», «component ui», or «look and feel delegate». The ComponentUI subclass is responsible for providing the look and feel specific functionality of the component. For example, JTree requires an implementation of the ComponentUI subclass TreeUI . The implementation of the specific ComponentUI subclass is provided by the LookAndFeel . Each JComponent subclass identifies the ComponentUI subclass it requires by way of the JComponent method getUIClassID .
Each LookAndFeel implementation must provide an implementation of the appropriate ComponentUI subclass by specifying a value for each of Swing’s ui class ids in the UIDefaults object returned from getDefaults . For example, BasicLookAndFeel uses BasicTreeUI as the concrete implementation for TreeUI . This is accomplished by BasicLookAndFeel providing the key-value pair «TreeUI»-«javax.swing.plaf.basic.BasicTreeUI» , in the UIDefaults returned from getDefaults . Refer to UIDefaults.getUI(JComponent) for details on how the implementation of the ComponentUI subclass is obtained.
When a LookAndFeel is installed the UIManager does not check that an entry exists for all ui class ids. As such, random exceptions will occur if the current look and feel has not provided a value for a particular ui class id and an instance of the JComponent subclass is created.
Recommendations for Look and Feels
As noted in UIManager each LookAndFeel has the opportunity to provide a set of defaults that are layered in with developer and system defaults. Some of Swing’s components require the look and feel to provide a specific set of defaults. These are documented in the classes that require the specific default.
ComponentUIs and defaults
All ComponentUIs typically need to set various properties on the JComponent the ComponentUI is providing the look and feel for. This is typically done when the ComponentUI is installed on the JComponent . Setting a property should only be done if the developer has not set the property. For non-primitive values it is recommended that the ComponentUI only change the property on the JComponent if the current value is null or implements UIResource . If the current value is null or implements UIResource it indicates the property has not been set by the developer, and the ui is free to change it. For example, BasicButtonUI.installDefaults only changes the font on the JButton if the return value from button.getFont() is null or implements UIResource . On the other hand if button.getFont() returned a non-null value that did not implement UIResource then BasicButtonUI.installDefaults would not change the JButton ‘s font.
For primitive values, such as opaque , the method installProperty should be invoked. installProperty only changes the corresponding property if the value has not been changed by the developer.
ComponentUI implementations should use the various install methods provided by this class as they handle the necessary checking and install the property using the recommended guidelines.
Exceptions
All of the install methods provided by LookAndFeel need to access the defaults if the value of the property being changed is null or a UIResource . For example, installing the font does the following:
JComponent c; Font font = c.getFont(); if (font == null || (font instanceof UIResource))
If the font is null or a UIResource , the defaults table is queried with the key fontKey . All of UIDefault’s get methods throw a NullPointerException if passed in null . As such, unless otherwise noted each of the various install methods of LookAndFeel throw a NullPointerException if the current value is null or a UIResource and the supplied defaults key is null . In addition, unless otherwise specified all of the install methods throw a NullPointerException if a null component is passed in.
Nimbus Look and Feel
Nimbus is a polished cross-platform look and feel introduced in the Java SE 6 Update 10 (6u10) release. The following screen capture, from SwingSet3 shows the Nimbus look and feel.
Nimbus uses Java 2D vector graphics to draw the user interface (UI), rather than static bitmaps, so the UI can be crisply rendered at any resolution.
Nimbus is highly customizable. You can use the Nimbus look and feel as is, or you can skin (customize) the look with your own brand.
Enabling the Nimbus Look and Feel
For backwards compatibility, Metal is still the default Swing look and feel, but you can change to Nimbus in one of three ways:
- Add the following code to the event-dispatching thread before creating the graphical user interface (GUI):
import javax.swing.UIManager.*; try < for (LookAndFeelInfo info : UIManager.getInstalledLookAndFeels()) < if ("Nimbus".equals(info.getName())) < UIManager.setLookAndFeel(info.getClassName()); break; >> > catch (Exception e) < // If Nimbus is not available, you can set the GUI to another look and feel. > The first line of code retrieves the list of all installed look and feel implementations for the platform and then iterates through the list to determine if Nimbus is available. If so, Nimbus is set as the look and feel.
Version Note: Do not set the Nimbus look and feel explicitly by invoking the UIManager.setLookAndFeel method because not all versions or implementations of Java SE 6 support Nimbus. Additionally, the location of the Nimbus package changed between the JDK 6 Update 10 and JDK 7 releases. Iterating through all installed look and feel implementations is a more robust approach because if Nimbus is not available, the default look and feel is used. For the JDK 6 Update 10 release, the Nimbus package is located at com.sun.java.swing.plaf.nimbus.NimbusLookAndFeel .
java -Dswing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel MyApp
swing.defaultlaf=javax.swing.plaf.nimbus.NimbusLookAndFeel
Class UIManager
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());
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
- If the system property swing.defaultlaf is non-null , use its value as the default look and feel class name.
- 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.
- Otherwise use the cross platform look and feel.
Defaults
- Developer defaults. With few exceptions Swing does not alter the developer defaults; these are intended to be modified and used by the developer.
- 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.
- System defaults. The system defaults are provided by Swing.
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 .