I filed this bug based on an email I received about feedback on JDK1.4 RC.  

I filed the platform as generic because that information was not given.  

There's another problem I've been having w/ modal dialogs that appears
in JDK1.3.1 & JDK1.4-rc1, but does not appear JDK1.3.0 and did not
appear in JDK1.4-beta3.  Basically the modal dialog comes up, but all of
the components within the dialog are not useable (it's like there's a
glass pane that covers the dialog making the components unusable), only
the dialog close box takes events.  

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;


public class DialogBug extends JFrame implements ActionListener {

    private DialogBug bug;

    public DialogBug() {
        super("Frame");
        bug this;
        getContentPane().setLayout(new FlowLayout());
        JButton b new JButton("Press Me");
        b.addActionListener(this);
        getContentPane().add(b);
        Dimension d Toolkit.getDefaultToolkit().getScreenSize();
        setBounds(d.width/2-120, d.height/2-160, 200, 200);
        addWindowListener(new WindowAdapter() {
                              public void windowClosing(WindowEvent e) {
                                  System.exit(0);
                              }
                          });
        setVisible(true);
    }

    public void actionPerformed(ActionEvent e) {
        new MyDialog();
    }


    public class MyDialog extends JDialog implements ActionListener {

        public MyDialog() {
            super(bug, "Modal Dialog", true);
            getContentPane().setLayout(new FlowLayout());
            JButton b new JButton("Threaded");
            b.addActionListener(this);
            getContentPane().add(b);
            b new JButton("Not Threaded");
            b.addActionListener(this);
            getContentPane().add(b);
            Rectangle r bug.getBounds();
            setBounds(r.x, r.y, 200, 200);
            setVisible(true);
        }

        public void actionPerformed(ActionEvent e) {
            String command e.getActionCommand();
            if (command.equals("Threaded")) {
                //
                // The problem appears when threaded otherwise ok...
                //
                Runnable runner new Runnable() {
                    public void run() {
                        JOptionPane.showMessageDialog(null, "Try to press OK button!!!");
                    }
                };
                new Thread(runner).start();
            } else {
                JOptionPane.showMessageDialog(null, "Try to press OK button!!!");
            }
        }
    }


    public static void main(String args[]) {
        new DialogBug();
    }
}

N/A

Commit to fix in mantis (hang).  
 xxxxx@xxxxx  2002-02-11




The problem is as follows:
when the first modal dialog (MD1) is shown on EventDispatchThread, AWT
starts discard all events which aren't targeted to MD1's hierarchy.
But the second modal dialog (MD2) is shown not on the EDT, and this
doesn't affect started filter.  MD1's hierarchy doesn't include MD2,
thus all events which are targeted to MD2 is dicarded.
 xxxxx@xxxxx   July 25, 2002


======================================================================

JOptionPane also has the same problem when showing a modal 
dialog in JDK 1.4 final. This is so basic functionality 
that is used often in Swing applications. How could this 
have been missed? 

All you have to do is use SwingUtilities.invokeAndWait() 
around the dialog setVisible(true).  It is extremely 
frustrating for sure...

invokeAndWait will not work from the event thread, if you 
have dialog code that can be called both from the event 
thread and from a non-event thread.  invokeLater will work 
in either case.

/** Display an error dialog or print a message to stdout. */
public void showError (String title, String text)
{
	class SafeMessageDialog implements Runnable
	{
		Component parentComponent;
		Object message;
		String title;
		int messageType;
		public SafeMessageDialog( Component 
parentComponent, 
			Object message, String title, int 
messageType )
		{
			this.parentComponent = 
parentComponent;
			this.message = message;
			this.title = title;
			this.messageType = messageType;
		}

		public void run()
		{
			JOptionPane.showMessageDialog( 
parentComponent, message,
							
			   title, messageType);
		}
	};

	// Works around Java Bug 4636311: Hang when showing 
a modal dialog
	// from a Runnable.
	// Workaround - Use invokeLater() around the dialog 
setVisible.
	SwingUtilities.invokeLater( new SafeMessageDialog( 
		null, text, title, 
JOptionPane.WARNING_MESSAGE ) );
}

Dialog hangs because of wrong parent. If you pass the right 
one, then problem should gone. However determinig the right 
parent can be difficult in some situation. There is an RFE 
4466805 to improve this situation.

Hello,

there is a somewhat related Bug report concerning freezing 
of JFileChooser boxes under sdk 1.4 with BugID 4479139. I 
had that problem with freezing, too.

After having read the information given here for BugID 
4636311 I came back to my code with the JFileChooser. I 
recognized that I had used that very JFileChooser object in 
a syncronized() statement to prevent concurrent access in a 
multi-threaded, event-thread based environemt. I changed 
the object to synchronize on from the file chooser object 
to an unrelated string, and ... it worked !

Synchronization on the file chooser object was totally OK 
with sdk 1.3.1_02, but froze the dialog under sdk 1.4.0_b92 
which I'm currently using. I don't know whether that is the 
general solution to one or both of the Bugs reported, but 
with me it's OK.

Best regards,
Kurt Spanier

I am puzzled that the evaluation says this was a bug?! The 
provided snippet violates Swing's single-thread rule, hence 
the problem. 
JOptionPane.showMessageDialog needs to be called on the 
event-dispatch thread (SwingUtilities.invokeLater) and the 
problem disappears.

Or what am I missing?

I agree with torsten. This is violating the Swing
single-thread rule and therefore should be ignored.

torsten has good point.  Although this was originated in the
event,  it actually called in a separate thread than the
current action event.
The code already has a runnable, just invokelater and that
would do.

I am not sure if this is really violating the single thread rule of Swing. The rule states that no calls may be 
made from another thread _after the Window/Dialog has been realized_, i.e. after the dialog is packed/show. 
Therefore creating and showing the dialog the way the example does should be valid.
Maybe JOptionPane does some things the wrong way round so that it gets bitten by the single thread rule. 
But then JOptionPane is broken and not the sample code.

WördehoffH is right, this *isn't* violating the thread 
rule (because you're allowed to call show() / setVisible
(true) from non event-threads). 

/However/, the main (and only) reason this is hanging is 
because of this:

JOptionPane.showMessageDialog(null, 
                              ^^^^

This isn't just a 1.4 issue, using a null parent when 
invoking a modal dialog on a thread other than the event 
thread causes this behavior in 1.3 too.

Simple fix: supply a valid parent for the dialog. It's 
good practise to do this anyway. 

Swing's single-thread rule states: 
"Once a Swing component has been realized, all code that 
might affect or depend on the state of that component 
should be executed in the event-dispatching thread."

Opening a Dialog clearly *does* change the state of an 
already realized frame, like grabbing the input focus. Hence 
my understandig is that you are allowed to realize a top-level 
component on a non-AWT (typically the main) thread *only 
once* - the first one that actually starts the event dispatch 
thread. Everything else has to be realized on the event 
dispatch thread. 
Again, this is how I understand the single-thread rule. I might 
be wrong.

I certainly agree that providing a dialog parent is good 
practice anyway ;-)

Agree with Thorsten / cairn. This is not a Bug.

However, I come to this bug while searching for a (possible) 
Bug I found out. When trying to show the modal Dialog during 
a WindowActivated event of MyDialog, the whole Application 
hangs! Showing the dialog with invokeLater solves the 
problem, however, this is not a threading-problem.
Will file this as a new Bug.

Duplicated on Mandrake Linux 8.2, KDE 3, J2SDK 1.4.1beta.

Is this related to the drag and drop bug? If you try displaying 
a modal dialog before completing a drop operation you get a 
busy hang....

I seems to see what *schlm3* above seem.  With the lastest
JDK 1.4.1 FCS, the problem is still there.  The 1 thread
rule does not seem to be violated.  Changed to invokeLater
worked.  But it should be a bug.  I'll see if I need to file
a bug report on this.

torsten_welches:

yes, however, Dialog (which JDialog inherits from, and does
not override show()) is NOT a swing component, it's a
heavyweight peer. So the thread rule for swing does not
apply. The javadoc for Dialog.show() actually says you can
invoke it from any thread (albeit in a subtle and slightly
misleading way).

Any focus change as a result of showing the dialog would be
handled by the focus manager, and this would always be in
response to a generated AWT event - i.e. not in the same
thread you called show() from. So, it's not a swing thread
safety issue at all.

If you're still not convinced, consider this... If you
wanted to write an application that was solely dialog based,
the very first thing you'd do in your main() method would be
to call show() on a (J)Dialog instance you constructed.
However, your main() method is NOT on the AWT event thread,
because your application has not invoked any UI at that
point. If you were not able to call show() from threads
other than the AWT event thread, you would never be able to
safely show a dialog in such an application (actually, this
applies to frames too, so you'd never be able to display a
graphical application period).

The single-thread rule applies to both AWT and Swing: unless
the docs 
for an API specifically state that it is thread-safe, it is
not thread-safe. 
However, cairn is right: it is permissible to initialize the
GUI on the 
main thread.  To continue modifying the GUI on the main
thread after 
initialization is not supported.  

I use the following method:

public static void runInSwing( Runnable r ) {
    if( SwingUtilities.isEventDispatchThread() ) {
        r.run();
    } else {
        try {
            SwingUtilities.invokeAndWait( r );
        } catch( InterruptedException ex ) {
        }
    }
}

I wonder if we can get something like this put into 
SwingUtilities?

This bug prevents us from creating a modal dialog that shows 
the progress of uploading files. The dialog's components are 
painted only when the action finishes. This defeats the whole 
purpose of the progress monitor. Please fix this.