JDK-6337517 : Call of JProgressBar.getPreferredSize() causes NPE on Windows L&F and custom desktop theme
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.4.2_22-rev,5.0,5.0u4
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp,windows_7
  • CPU: x86
  • Submitted: 2005-10-17
  • Updated: 2010-05-08
  • Resolved: 2006-02-02
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.
Other JDK 6
5.0u8Fixed 6 b70Fixed
Related Reports
Duplicate :  
JDK-6357324 - NullPointerException using WindowsProgressBarUI with unknown XPStyle pro
Relates :  
JDK-6425314 - Vista L&F: vertical progress bars are short and too wide.
Description
Call of JProgressBar.getPreferredSize() or ProgressBarUI.getPreferredSize() causes NPE on Windows L&F and custom desktop theme. Unfortunately I am not able to reproduce it with any custom desktop theme. But we have several user reports. It causes silent exit of our NetBeans IDE installer. See for example issue http://www.netbeans.org/issues/show_bug.cgi?id=64380 and attachment given there. Here is one exception call stack example:
Exception in thread "AWT-EventQueue-0" java.lang.NullPointerException

	at java.awt.Dimension.<init>(Dimension.java:91)
	at javax.swing.plaf.basic.BasicProgressBarUI.getPreferredSize(BasicProgressBarUI.java:757)
	at javax.swing.JComponent.getPreferredSize(JComponent.java:1615)
	at com.installshield.wizard.awt.ColumnLayout.layoutContainer(Unknown Source)
	at java.awt.Container.layout(Container.java:1401)
	at java.awt.Container.doLayout(Container.java:1390)
	at java.awt.Container.validateTree(Container.java:1473)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validateTree(Container.java:1480)
	at java.awt.Container.validate(Container.java:1448)
	at javax.swing.RepaintManager.validateInvalidComponents(RepaintManager.java:379)
	at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:113)
	at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
	at java.awt.EventQueue.dispatchEvent(EventQueue.java:461)
	at java.awt.EventDispatchThread.pumpOneEventForHierarchy(EventDispatchThread.java:242)
	at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:163)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:157)
	at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
	at java.awt.EventDispatchThread.run(EventDispatchThread.java:110)

As I checked sources it seems that WindowsProgressBarUI.getPreferredInnerHorizontal() can return null.
Comments
EVALUATION The fix for this bug introduced 6425314 [Vista L&F: vertical progress bars are short and too wide.]
12-05-2006
EVALUATION I can reproduce this bug by creating an invalid theme by deleting the NormalSize property from the theme. This will cause the code to throw an exception. Simply reverting to the super class could result in a progress bar which is too small because the BasicProgresBarUI hard codes a smaller size and then adds borders to it. Reverting to the skin.getWidth()/getHeight() values will also not return the exact same size as the NormalSize property would have. It will return 9x19 rather than 100x18 that NormalSize would have returned. Further research indicates that the ThemeReader.getPartSize() method (which is what the skin dimensions will return) calls a native function which returns a value based on the underlying PNG image. That's what it's only 9 pixels wide, because the image really only shows the edges of the widget. The ThemeReader.getPosition() method (which is what the older code uses via the xp.getDimension() method) will use the NormalSize property from the theme, which is 100x18 in Luna. My recommended fix is to use the old behavior, looking for the NormalSize property, and if it's null then use the skin dimensions via the ThemeReader.getPartSize() method since that will always return something valid (the underlying image size) even if it's a tad shorter. The width is the sticking point here. We are talking about the "preferred" size here, which is usually overridden by a layout manager in the case of a progress bar. However, if someone puts a progress bar in a container where the preferred size is needed (ie, a horiz progbar that's not stretched to the width of it's window, pane, etc), then it would be very narrow. Thus we do need *some* default for the width if the NormalSize property is missing. I think the width of the super class (BasicProgressBarUI) would be good. Again, this is only if the NormalSize property is missing, indicating an invalid theme.
12-12-2005
EVALUATION This has just been reported again in duplicate bug 6357324.
01-12-2005
EVALUATION Here is my question to original reporter and his response (tracked at http://www.netbeans.org/issues/show_bug.cgi?id=64380): Please could you send me additional info I asked for last time? As it is not in this issue description I repeat it here: Do you use any tool to customize your "visual style" or "skin"? Or do you use any custom skin? (Even if your theme file points to default msstyle file: Path=%WinDir%Resources\themes\Luna\Luna.msstyles.) The question is this if your default "skin" was modified anyhow.) "The company TGTSoft makes a tool called StyleXP which can be used to apply a different visual style on Windows XP. They also make StyleBuilder which allows you to create and edit visual styles and save them to a .msstyles file which can then be included in a theme. Judging from the bug description, the user might be running with a custom visual style. It could be one downloaded from www.themexp.org or one they made themselves. What is the name of the theme file?" Are you still able to reproduce problem with your original desktop theme? Thanks ------- Additional comments from fretful Fri Nov 4 13:37:41 +0000 2005 ------- Well i dont know which style it was cause i deleted it some years ago. and i just remeber having one of these themes from www.themexp.org. i didn't use any extra tool just copied the themes and locked up windows to use them.
08-11-2005
EVALUATION So far I did not get any additional info from original reporter or any other reports of this problem.
04-11-2005
EVALUATION Currently waiting some more information about the broken theme. We think we can fix this by making the relevant methods return the value from super incase of null, thus fixing the NPE.
03-11-2005
WORK AROUND Workaround is to change desktop theme to some default theme like Win XP or Classic. Then this problem does not happen.
18-10-2005