JDK-6653395 : Default LAF is set to CrossPlatformLookAndFeel not SystemLookAndFeel
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6u10,7
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: generic,windows,windows_xp
  • CPU: generic,x86
  • Submitted: 2008-01-22
  • Updated: 2012-03-22
  • Resolved: 2008-06-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7
6u10 b13Fixed 7Fixed
Related Reports
Duplicate :  
JDK-6653165 - api/javax_swing/plaf/basic/BasicInternalFrameUI/index.html#protected fails 6u10 under plugin
Duplicate :  
JDK-6663202 - REGRESSION: The default look and feel for Swing components has become SystemLookAndFeel
Duplicate :  
JDK-6653174 - AccessibleJTabbedPane0005 fails under plugin 6u10 b10
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
SUGGESTED FIX Webrev: http://sa.sfbay.sun.com/projects/deployment_data/6u10/6653395.0
15-02-2008
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.
13-02-2008