4

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.

Community
  • 1
  • 1
eirikbakke
  • 43
  • 4
  • please which version of Java5, cos I have jdk1.5.0_22 as most stable vesion of – mKorbel Dec 05 '11 at 20:57
  • It's JRE 1.5.0_22 to be specific. – eirikbakke Dec 05 '11 at 21:03
  • can't reproduce that, including profiling in JProfiler – mKorbel Dec 05 '11 at 21:11
  • errrrrrrrrhht this Bug you can reproduce anytime when you want, JOptionPane must be done on EDT – mKorbel Dec 05 '11 at 21:12
  • @mKorbel SwingUtilities.invokeLater() ensures the JOptionPane and its dialog is created on the EDT. – eirikbakke Dec 05 '11 at 21:14
  • agreed with EDT, I'm talking how to reproduce that, as I tried whatever (Java5) with setModal (ModalityTypes was implemnted in Java6), another question isn't there applied some Custom L&F – mKorbel Dec 05 '11 at 21:35
  • The bug is reproducible both on the default L&F as well as on the Windows 7 L&F. I've also now confirmed that the bug is not dependent on using a JOptionPane; I've seen it once on a manually created JDialog as well (though it's less frequent). Thus manually creating a JDialog turned out not to be a workaround. – eirikbakke Dec 06 '11 at 18:00

1 Answers1

5

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
nowaq
  • 2,748
  • 19
  • 25
  • That looks like the correct bug report, yes--thanks! Ugh, so the bug is still there up to Java 7. I'll wait a little to see if someone knows of a workaround; the bug seems more likely to appear in some cases than others. Otherwise I'll mark this as the answer. – eirikbakke Dec 05 '11 at 21:19
  • Yeap, it's up to Java 7... unless you're on Solaris or Linux. You could always try using using some other, non-sun (uups, oracle) JVM for Windows ([List of Java virtual machines](http://en.wikipedia.org/wiki/List_of_Java_virtual_machines) :-) – nowaq Dec 05 '11 at 21:34