United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
Bug ID: JDK-6653395 Default LAF is set to CrossPlatformLookAndFeel not SystemLookAndFeel
JDK-6653395 : Default LAF is set to CrossPlatformLookAndFeel not SystemLookAndFeel

Details
Type:
Bug
Submit Date:
2008-01-22
Status:
Closed
Updated Date:
2012-03-22
Project Name:
JDK
Resolved Date:
2008-06-16
Component:
client-libs
OS:
generic,windows_xp,windows
Sub-Component:
javax.swing
CPU:
x86,generic
Priority:
P3
Resolution:
Fixed
Affected Versions:
6u10,7
Fixed Versions:
6u10 (b13)

Related Reports
Backport:
Duplicate:
Duplicate:
Duplicate:

Sub Tasks

Description
FULL PRODUCT VERSION :
java version "1.6.0_10-ea"
Java(TM) SE Runtime Environment (build 1.6.0_10-ea-b10)
Java HotSpot(TM) Client VM (build 11.0-b09, mixed mode, sharing)


ADDITIONAL OS VERSION INFORMATION :
 customer  Windows XP [Version 5.1.2600]


A DESCRIPTION OF THE PROBLEM :
With other JRE releases, the default look and feel (LAF) is set to "CrossPlatformLookAndFeel". See http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html#available

I can confirm that the correct behaviour is to default to CrossPlatformLookAndFeel, as per JRE 1.7 (and earlier versions of JRE 1.6).

So, just confirming, defaulting to CrossPlatformLookAndFeel is the _correct_ behaviour. This is done by JRE 1.7 but JRE 1.6.0_10-ea-b10 defaults to SystemLookAndFeel for some reason.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Run any Java application (or applet) which doesn't specifically set its own LAF. On JRE 1.6.0_10-ea it will display using the SystemLookAndFeel. On JRE 1.7 (or any other JVM version) it will display using CrossPlatformLookAndFeel.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It should use the CrossPlatformLookAndFeel as per http://java.sun.com/docs/books/tutorial/uiswing/lookandfeel/plaf.html#available.
ACTUAL -
It renders with SystemLookAndFeel.

REPRODUCIBILITY :
This bug can be reproduced always.

CUSTOMER SUBMITTED WORKAROUND :
Specify platform specific LAF in swing.properties: e.g.
swing.defaultlaf=javax.swing.plaf.metal.MetalLookAndFeel

Release Regression From : 6
The above release value was the last known release where this 
bug was not reproducible. Since then there has been a regression.
Posted Date : 2008-01-23 08:53:08.0

                                    

Comments
EVALUATION

Before 6594219, DeployUIManager called javax.swing.UIManager.setLookAndFeel(), thus setting LAF for the plugin's AppContext. Applets, because they live in different contexts, were getting default LAF, and could change it if they wished to. So everything worked properly, except for the fact that calling UIManager method caused loading of many Swing classes, and that was bad for jkernel.

The fix for 6594219 tried to avoid calling into Swing by setting a system property, "swing.defaultlaf". Unfortunately this setting affected all AppContexts, so applets started getting system LAF by default. This bug, 6653395, is a regression introduced by 6594219.

To fix the issue properly, we need a way to specify default LAF on a per-AppContext basis, like UIManager.setLookAndFeel() does, but without loading Swing. A natural way of doing this is through AppContext properties. Another thing to note is that plugin may customize LAF by setting properties (currently it sets "Slider.paintValue").

So the suggested fix is as follows:
- plugin creates an AppContext property whose value is a hashmap. This hashmap contains name of the default LAF class associated with a special predefined key, "defaultlaf". It may also contain any number of LAF properties. Currently the hashmap looks like:
	{
	  "defaultlaf" -> <system LAF class name>
	  "Slider.paintValue" -> Boolean.FALSE
	}
- UIManager.initializeDefaultLAF() examines the AppContext property, and if it's present, takes default LAF from there. After LAF has been set, it also sets any properties received through AppContext.

This approach is quite flexible - it's easy for plugin to specify additional properties if needed. It's also secure - no public API is involved, no client code will see the AppContext properties we create.
                                     
2008-02-13
SUGGESTED FIX

Webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6653395.0
                                     
2008-02-15



Hardware and Software, Engineered to Work Together