Bug ID: JDK-6470308 Switching between "Windows and button" style on XP, color schemes on Vista is throwing an NPE.

Type: Bug
Component: client-libs
Sub-Component: javax.swing
Affected Version: 6

Priority: P2
Status: Closed
Resolution: Duplicate
OS: windows_xp
CPU: x86

Submitted: 2006-09-13
Updated: 2010-04-02
Resolved: 2007-03-09

Switching between "Windows and button" style on XP, color schemes on Vista is throwing an NPE.
Steps to reproduce: 
 - Open SwingSet2, Switch to Windows LAF 
 - Switch to ProgressBar demo.
 - Now open the Windows "Display Properties"
 - Navigate to the "Appearance" Tab
 - Change the "Windows & Buttons" from "Windows XP style" -> "Windows Classic style"
 - And Apply the same
 - You can see the NullPointerException now, the bug is reproduced

On Vista
 - You need change the "Color Scheme" from "Windows Vista Basic" to "Windows Classic"

This is reproducible on the latest build b98. Tried regressing it on XP till build b36, earlier build it's not consistent. 

Stacktrace attached for both XP and Vista 5520.

EVALUATION Fix for 6491420 XPStyle.getSkin returning null is dangerous fixes this bug. closing as duplicate
09-03-2007
EVALUATION This problem is reproducible on XP I think NullPointerException started to happen from b96. After the fix for 6432397 : [Windows l&f on Vista JComboBox does not look like native] XPStyle.getSkin started to return null for the skins which are not defined. Before that skin was not null ever. If it is not defined it could have painted some garbage. We use skin painting only if XPStyle.getXP() is not null. XPStyle.getXP() should be not null only if theme painting is needed. The skins we use should always be defined thus we should never get unexpected null skin from XPStyle.getSkin. Here is why it does not quite work. XPStyle.getXP uses cached value which is refreshed on desktop property change in DesktopProperty.updateAllUIs using XPStyle.invalidateStyle() DesktopProperty.updateAllUIs call is send to the Event Dispatch Thread for the execution. All the pending paint events between the time the system theme was changed and DesktopProperty.updateAllUIs is invoked going to get wrong XPStyle.getXP value. Skins are not defined for classic theme. painting gets non null XPStyle from the previous state and tries to use skins. The skins are not defined for the current system theme and thus getSkin returns null. We end-up with NullPointerException. To address this problem my suggestion would be to call XPStyle.invalidateStyle() immediately rather than sending it to the EDT. All the pending events would pick up a new XPStyle.getXP (that is if it does not happen during some paint. There is not much we can do in this case) WDesktopProperties delivers property updates on the EDT. We going to have to update it too. In widnows L&F we use two sets of cached system resources : XPStyle.getXP and ThemeReader.getTheme This bug is about problem with XPStyle.getXP not sure if ThemeReader.getTheme might have a similar problem.
14-09-2006
EVALUATION > This is reproducible on the latest build b98. Tried regressing it on XP till build b36, earlier build it's not consistent. was the bug reproducible before b98? Do you know what was the first build it can be reproduced on?
14-09-2006
EVALUATION Heard back from SQE. This bug is consistently reproducable on Vista. It can be reproduced on XP, but less consistently.
14-09-2006
EVALUATION Moving this bug to incomplete for the following reasons: 1) I cannot reproduce this. 2) Description mentions Progress Bar demo, but stack trace shows a problem with Scroll Bars. Did submitter really mean Progress Bar? Can we please have the full steps to reproduce this and information on the test machine.
13-09-2006