Java 1.5 JOptionPane paint bug when using panel me

Question

I have a JOptionPane with a custom message panel in it, in an application targeted for Java 1.5. The panel contains, among other things, a JTextField. Every 20 invocations or so, nothing in the dialog gets painted (not even the OK/Cancel buttons). If I drag the dialog off the screen and back again to force a repaint, the components are visible as expected, and apart from the painting problem, the components respond fine. Here is the smallest example I could get to exhibit this bug:

public class BugTest {
  public static void main(String args[]) {
    SwingUtilities.invokeLater(new Runnable() {
      public void run() {
        // The text field needs to be wrapped in a panel for the bug to show up.
        JPanel messagePanel = new JPanel();
        // A JLabel won't exhibit the bug, but a JTextField will.
        JTextField textField = new JTextField("Some content");
        messagePanel.add(textField);
        // Loop so we can keep clicking OK until the bug shows up.
        while (true) {
          int res = JOptionPane.showOptionDialog(null, messagePanel,
              "SomeTitle", JOptionPane.OK_CANCEL_OPTION,
              JOptionPane.PLAIN_MESSAGE, null, null, null);
        }
      }
    });
  }
}

Is this a well-known bug in Swing? Is there a standard workaround? I haven't been able to find an official bug report for this. The bug does not appear to be present in Java 1.7, but my application needs to run on the older 1.5, and I'd like to find a workaround that works on the latter.

Related: Modeless JDialog not showing contents (does not include a code example, so it's hard to know if it's the same bug)

The specific Java version I've found the bug on is 1.5.0_22.

Answer 1

This bug seems to be reporducible on Java 1.5 up to Java 7 running on Windows Vista and XP (probably also on Win7)

Take a look at this bug report (Bug ID: 6859086)

The most likely cause of the problem is a GDI resource leak. See if you could track GDI resources consumed by the java process with either task manager or process explorer.

EDIT: According to the bug report the workaround is not available but you may try to play around with a couple of runtime options:

• -Dswing.handleTopLevelPaint=false
• -Dsun.java2d.d3d=true