JDK-6467366 : REGESSION: JFileChooser displays garbage as Applet using WinXP LAF
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2006-09-05
  • Updated: 2011-12-21
  • Resolved: 2006-09-14
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
6 b99Fixed
Related Reports
Relates :  
JDK-6432397 - Windows l&f on Vista JComboBox does not look like native
Relates :  
JDK-6491420 - XPStyle.getSkin returning null is dangerous
Relates :  
JDK-6467869 - sun.awt.windows.ThemeReader.flush is invoked too often for javax.swing.JFileChooser
Description
J2SE Version (please include all output from java -version flag):
  java version "1.6.0-rc"
  Java(TM) SE Runtime Environment (build 1.6.0-rc-b98)
  Java HotSpot(TM) Client VM (build 1.6.0-rc-b98, mixed mode, sharing)

Does this problem occur on J2SE 1.3, 1.4.x or 1.5?  Yes / No (pick one)

  NO. The bug does only occur, when the code is run as an applet. 
  It works fine, when run as an application.

Operating System Configuration Information (be specific):
  WinXP SP2

Bug Description:

  JFileChooser displays garbage file selector and shows exception when using
  "UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());" 
  on Windows XP SP2 (system LAF class name is 
  com.sun.java.swing.plaf.windows.WindowsLookAndFeel ).


  However the file choose works fine but looks ugly.

  Attached a screenshot of the file chooser and a sample source code. 
  The code runs as an applet and a standalone application.

Steps to Reproduce (be specific):

  appletviewer.exe -J-Djava.security.policy=all.policy capFilechooser.html


Stack trace

Exception in thread "AWT-EventQueue-1" java.lang.NullPointerException
    at com.sun.java.swing.plaf.windows.WindowsButtonUI.paintXPButtonBackground(WindowsButtonUI.java:226)
    at com.sun.java.swing.plaf.windows.WindowsToggleButtonUI.paint(WindowsToggleButtonUI.java:118)
    at javax.swing.plaf.ComponentUI.update(ComponentUI.java:143)
    at javax.swing.JComponent.paintComponent(JComponent.java:758)
    at javax.swing.JComponent.paint(JComponent.java:1022)
    at javax.swing.JComponent.paintChildren(JComponent.java:859)
    at javax.swing.JComponent.paint(JComponent.java:1031)
    at javax.swing.JComponent.paintChildren(JComponent.java:859)
    at javax.swing.JComponent.paint(JComponent.java:1031)
    at javax.swing.JComponent.paintChildren(JComponent.java:859)
    at javax.swing.JComponent.paint(JComponent.java:1031)
    at javax.swing.JComponent.paintChildren(JComponent.java:859)
    at javax.swing.JComponent.paint(JComponent.java:1031)
    at javax.swing.JLayeredPane.paint(JLayeredPane.java:564)
    at javax.swing.JComponent.paintChildren(JComponent.java:859)
    at javax.swing.JComponent.paintToOffscreen(JComponent.java:5111)
    at javax.swing.BufferStrategyPaintManager.paint(BufferStrategyPaintManager.java:285)
    at javax.swing.RepaintManager.paint(RepaintManager.java:1132)
    at javax.swing.JComponent.paint(JComponent.java:1008)
    at java.awt.GraphicsCallback$PaintCallback.run(GraphicsCallback.java:21)
    at sun.awt.SunGraphicsCallback.runOneComponent(SunGraphicsCallback.java:60)
    at sun.awt.SunGraphicsCallback.runComponents(SunGraphicsCallback.java:97)
    at java.awt.Container.paint(Container.java:1797)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:738)
    at javax.swing.RepaintManager.paintDirtyRegions(RepaintManager.java:683)
    at javax.swing.RepaintManager.seqPaintDirtyRegions(RepaintManager.java:663)
    at javax.swing.SystemEventQueueUtilities$ComponentWorkRequest.run(SystemEventQueueUtilities.java:128)
    at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:209)
    at java.awt.EventQueue.dispatchEvent(EventQueue.java:597)
    at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:273)
    at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:183)
    at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:173)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:168)
    at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:160)
    at java.awt.EventDispatchThread.run(EventDispatchThread.java:121)
Comments
EVALUATION The root cause of the bug was there forever. You can run the test case on the previous version of java and observe that JFileChooser in applet and application does not look the same. The buttons on the left side are different. NullPointerException started to happen after the fix for 6432397 : Windows l&f on Vista JComboBox does not look like native After this fix XPStyle.getSkin returns 'null' if the skin is not defined in the current theme. Before that fix the skin was never 'null' it just did not paint anything. (Thus the difference in JFileChoser in applet and in application). Here is what the root cause is. All swing XP uxtheme calls go through ThemeReader. For every call theme handler is used. Theme handlers are cached and after ThemeReader.flush() call all current theme handlers are obsolete and purged from the cache. The problem is if we get theme handler first, then ThemeReader.flush() is called, then we use obsolete theme handler. Here is the source of one of the methods in ThemeReader public static void paintBackground(int[] buffer, String widget, int part, int state, int x, int y, int w, int h, int stride) { paintBackground(buffer, getTheme(widget), part, state, x, y, w, h, stride); } If ThemeReader.flush() is called on another thread after getTheme(widget) we get exactly this problem. Calls to ThemeReader happen on EDT thread. In the applet case there are more than one EDT thread that is why we get this problem. ThemeReader.flush() is called from sun.awt.windows.WDesktopProperties on any desktop property change on the system EDT while we paint on the applet EDT. Suggested fix: We need to make sure that flush() is never happen in the middle of any of ThemeReader.method invocations.
06-09-2006
EVALUATION I didn't see this problem in a stand-alone application. However, I was able to see it with appletviewer on JDK 6. It did not happen on JDK 5.0u8 or Swing's JDK 7 workspace. This suggests the cause is a change that's gone into 6 but not yet pushed to our 7 workspace.
05-09-2006
EVALUATION This bug looks like a swing issue, it happens on standalone application as well, I reassign it to swing team.
05-09-2006