JDK-6442363 : Solaris Install does not work in GUI if you use SUNWj6rt from snv_42.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: solaris_nevada,windows_xp
  • CPU: generic,x86
  • Submitted: 2006-06-22
  • Updated: 2011-01-31
  • Resolved: 2006-08-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.
6 b94Fixed
Related Reports
Relates :  
See comments.

EVALUATION The first evaluation indicates this might be a threading problem. That isn't the case. The bug occurs when invoking getGraphics during paint on the same thread. For example, a component that overrode paintComponent as outlined below triggers the bug: protected void paintComponent(Graphics g) { getGraphics(); }

EVALUATION This is a regression introduced in the fix for 6415339. As part of fixing 6415339 Swing will turn of true buffer per window if the Graphics is obtained (getGraphics is invoked). The fix didn't adequately deal with the case where getGraphics is invoked while painting. In such a scenario, getGraphics is invoked with triggers the BufferStrategy to be disposed. After the painting has completed the BufferStrategy is shown. But as the buffer strategy isn't valid now, an exception is thrown. The fix is to delay disposing the buffer. If in the process of painting and the graphics is obtained, a flag that the buffer strategy should be disposed is set. When painting is complete the flag is checked, and if necessary, the buffer is disposed.

WORK AROUND Run java with -Dswing.bufferPerWindow=false .

EVALUATION I'm not familiar with this area but it sounds like a thread race: backBuffer element gets null while from the other thread we are accessing it. I searched through the swing bugs but found nothing related to this. It also might be a defect in 2d. I'd ask swing to look into it first. I also believe we may invent a way to reproduce this without installer. Seem there just a Dialog appears on the screen.

WORK AROUND After the crash, you will need to refresh the screen and it will display properly.