invokeLater is NOT what you want to do for Thread

invokeLater passes a Runnable object to be executed on the
EventDispatchThread.

Thread happens to implement Runnable, so your code will get called on
the EDT, but your thread object itself doesn't know or care about the
EDT vs its self.

Generally, if you are updating the GUI, you want to create a Runnable
(not thread) and use invokeLater, or invokeAndWait.

Although, I believe the JOptionPane calls are safe to call from any
thread, so you don't need to create a new thread to do so.  Double
check the API doc before you take my word on that.

    The thread `t' never starts at all, hence remains forever
in state NEW.  The argument to invokeLater() is not a Thread
per se, but a Runnable (Thread implements Runnable, which is
why the code compiles).  invokeLater() arranges for the run()
method of its Runnable to be called by the Event Dispatching
Thread, and its the EDT that displays your JOptionPane.  But
the "thread-ness" of t is never used; only its "runnable-ness"
comes into play -- and on a different thread, at that.

    What are you trying to accomplish with this JOptionPane?
Yes, you said to "ignore the issues with result for now," but
I suspect those very issues are central to finding the right
solution.

SwingUtilities (or better java.awt.EventQueue) .invokeLater takes a
Runnable argument, which by a piece of terrible design is implemented by
Thread. It calls run on the argument, in the Event Dispatch Thread
(EDT). In order for your thread to start, Thread.start would need to be
called.

(
You can pick up these sort of problems by using a subclass of Thread
that does not allow itself to be used as a Runnable.

http://groups.google.com/group/comp.lang.java.programmer/browse_thread/thread/56
687253dbf9a11f/e634f82ccd1161a6?lnk=st&q=SafeThread&rnum=3#e634f82ccd1161a6
)

So, replace Thread with plain Runnable.

The easiest way to get the calling thread to wait is to use
EventQueue.invokeAndWait instead of invokeLater, although it does add
checked exceptions that need to be dealt with.

There are a number of ways to get results back from Runnable. The
obvious way is to go one level up from an anonymous inner class and use
a local class.

        class InputDialogTask implements Runnable {
            String result;
            public void run() {
                result = (String)JOptionPane.showInputDialog(
                JOptionPane.showInputDialog(
                    null, "Enter a random string:"
                );
            }
        }
        InputDialogTask inputDialogTask = new InputDialogTask();
        java.awt.EventQueue.invokeAndWait(inputDialogTask);
        return inputDialogTask.result;

If you don't mind being a little obscure, you can do it in a terser fashion.

        return new Runnable() {
            String result;
            public void run() {
                result = (String)JOptionPane.showInputDialog(
                JOptionPane.showInputDialog(
                    null, "Enter a random string:"
                );
            }
            // (this is an instance initialiser)
            {
                java.awt.EventQueue.invokeAndWait(this);
            }
        }.result;

Alternatively, a more sophisticated approach is to have the main thread
waiting on a (java.util.concurrent) blocking queue. This could be
extended to make the main thread become event based (not shown).

        final BlockingQueue<String> resultQueue =
            new ArrayBlockingQueue<String>(1);
        java.awt.EventQueue.invokeLater(new Runnable() {
                public void run() {
                    String result = (String)JOptionPane.showInputDialog(
                    JOptionPane.showInputDialog(
                        null, "Enter a random string:"
                    );
                    resultQueue.add(result);
                }
        });
        return resultQueue.take(); // blocks

(Disclaimer: Not tested or even compiled.)

Tom Hawtin