SwingUtilites: how to return values from another thread in Java?

You can use AtomicReference<String> for passing values between threads in a thread-safe manner.

As noted by Hemal, you'll need some synchronization between two threads to make sure it was already executed. For example, you can use CountDownLatch or use SwingUtilities.invokeAndWait (make sure you don't call it from Swing thread!)

Update: here is the complete example using AtomicReference and CountDownLatch

public class Main {    public static void main(String[] args) throws InterruptedException {        final AtomicReference<String> result = new AtomicReference<String>();        final CountDownLatch latch = new CountDownLatch(1);        SwingUtilities.invokeLater(new Runnable() {            public void run() {                String input = JOptionPane.showInputDialog(null, "Stop?", "Stop?", JOptionPane.QUESTION_MESSAGE);                result.set(input);                // Signal main thread that we're done and result is set.                // Note that this doesn't block. We never call blocking methods                // from Swing Thread!                latch.countDown();            }        });        // Here we need to wait until result is set. For demonstration purposes,        // we use latch in this code. Using SwingUtilities.invokeAndWait() would        // be slightly better in this case.        latch.await();        System.out.println(result.get());    }}

Also read this answer about general design of GUI (and Swing) applications.

How would I get this input string in my main body?

You wouldn't. The idea that your "main" would invoke a Swing dialog box and then do something with the results is contrary to the entire idea of a graphical user interface.

In a GUI, you design your program to deal with a series of user-initiated events. Those events may be completely asynchronous, such as the keystrokes, selection, and menu choices of your typical word processor. Or they may be scripted, such as the question-answer format of a "wizard."

Assuming that you want to do something like the latter, you would implement it using the following sequence:

1. The user initiates some action, perhaps selecting a menu choice. This is turned into an invocation of an ActionListener, which decides that it needs more input from the user.
2. The ActionListener, which is executed on the event dispatch thread, is permitted to do anything that it wants to the UI, such as displaying a dialog. That dialog may be modal or non-modal; in one case the output is available to the original listener, in the other you need to write a new listener to take subsequent action.
3. Once you have enough information, you may choose to invoke a background operation. You would typically have a thread-pool to service these requests. You would not attempt to perform the request on the "main" thread; in fact, for all intents the main thread is no longer running.
4. When your operation completes running, it would push data back to the event dispatch thread using SwingUtilities.invokeLater(). While you could use invokeAndWait() to send results to Swing in the middle of your background operation, that's rarely a good idea. Instead, create a sequence of operations, preferably one that is easily canceled by the user.

The "standard" way to initiate operations on a background thread is via SwingWorker. There are alternatives; for example, you could use a BlockingQueue to send operations to a single long-running background thread, and use invokeLater() to return the results.

Regardless, there's one rule that you do not want to break: never, ever, perform a blocking operation on the event dispatch thread. If you do that, then your application is broken.

Right now you have two threads going: the main thread and the EDT (event dispatch thread). I assume you know that SwingUtilities.invokeLater(runnable) is running a task on the EDT.

To share data between threads, you just need some variable that is in the scope of both threads. The easiest way to accomplish that is to declare a volatile data member or AtomicReference in the class containing the main method.

In order to ensure that you read the value after it is returned by the JOptionPane, the simplest thing you can do here is to change the invokeLater call to an invokeAndWait call. This will cause your main thread to stop executing until what you have put onto the EDT has completed.

Ex:

public class MyClass {  private static volatile String mySharedData;  public static void main(String[] args) throws InterruptedException {    SwingUtilities.invokeAndWait(new Runnable() {      public void run() {        mySharedData = JOptionPane.showInputDialog(null, "Stop ?", JOptionPane.QUESTION_MESSAGE);      }    });// main thread is blocked, waiting for the runnable to complete.   System.out.println(mySharedData);  }}

If your main thread is executing some task that shouldn't be stopped while the option pane is present, then in the main thread you can periodically check (i.e., in the outer part of the loop that is running your task) whether or not mySharedData has been set. If your task doesn't loop and is instead doing some I/O or waiting, you can make use of Thread.interrupt and check mySharedData in the InterruptedExecption handlers.