Why does calling this method on the EDT cause a compilation error?

Question

I am trying to pop up a custom dialog box. When I try calling the method to do that on the EDT I get the following error:

Exception in thread "AWT-EventQueue-0" java.lang.Error: Unresolved compilation problem: 

at danind.com.gmail_coem.ui.CredentialEditor.promptPossibleDialog(CredentialEditor.java:29)
at danind.com.gmail_coem.ui.HomeScreen$ConfigureDatabase.<init>(HomeScreen.java:281)
at danind.com.gmail_coem.ui.HomeScreen.configureDatabase(HomeScreen.java:230)
at danind.com.gmail_coem.ui.HomeScreen.lambda$1(HomeScreen.java:105)
at danind.com.gmail_coem.ui.HomeScreen$$Lambda$7/2092062410.actionPerformed(Unknown Source)
at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)
at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)
at javax.swing.DefaultButtonModel.setPressed(Unknown Source)
at javax.swing.plaf.basic.BasicButtonListener.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.AWTEventMulticaster.mouseReleased(Unknown Source)
at java.awt.Component.processMouseEvent(Unknown Source)
at javax.swing.JComponent.processMouseEvent(Unknown Source)
at java.awt.Component.processEvent(Unknown Source)
at java.awt.Container.processEvent(Unknown Source)
at java.awt.Component.dispatchEventImpl(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)
at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)
at java.awt.Container.dispatchEventImpl(Unknown Source)
at java.awt.Window.dispatchEventImpl(Unknown Source)
at java.awt.Component.dispatchEvent(Unknown Source)
at java.awt.EventQueue.dispatchEventImpl(Unknown Source)
at java.awt.EventQueue.access$400(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.awt.EventQueue$3.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.awt.EventQueue$4.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)
at java.awt.EventQueue.dispatchEvent(Unknown Source)
at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)
at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
at java.awt.EventDispatchThread.run(Unknown Source)

After cleaning up my project in Eclipse, and doing some isolation tests I figured out that calling the method on the EDT was what caused the problem. When I moved the method to the background thread it worked, but I don't want that since I want to create my dialog GUI on the EDT.

//Creates compilation error
private class ConfigureDatabase extends SwingWorker<Void, String[]>
{
    private CredentialEditor instance;
    public ConfigureDatabase()
    { //Runs on EDT
        this.instance = CredentialEditor.promptPossibleDialog(true);
    }

    @Override
    protected Void doInBackground()
    { //Runs in background thread
        try(Database database = CredentialEditor.getCredentials(instance))
        {
            //code
        }
    }
}

vs

//Runs just fine, but dialog GUI is not on EDT
private class ConfigureDatabase extends SwingWorker<Void, String[]>
{
    @Override
    protected Void doInBackground()
    { //Runs in background thread
        try(Database database = CredentialEditor.getCredentials(CredentialEditor.promptPossibleDialog(true)))
        {
            //code
        }
    }
}

The method in question:

public static CredentialEditor promptPossibleDialog(boolean reset)
{
    if(reset || ConnectionPool.getInstance() == null)
    { //Checks to see if a dialog box needs to be created.
        if(SwingUtilities.isEventDispatchThread())
        { //Checks to make sure the thread is on the EDT.
            return new CredentialEditor();
        }
        else
        { //If it's not on the EDT throw an exception warning.
            throw new IllegalStateException("Must run on EDT!");
        }
    }
    return null; //If no dialog box needs to be created return nothing.
}

To be more detailed about the problem it seems simply just calling the method causes problems. It's not setting the instance variable or anything inside the method, it's just calling that static method in the EDT specifically. In fact, the stacktrace points to the line where it's simply stating the method, as in, the line where it says public static CredentialEditor promptPossibleDialog(boolean reset)

So what is causing the error and if I can't get around it how can I run my GUI code on the EDT even if the method for it is being called on a background thread?

Answer 1

Try running your dialog directly on EDT.

public ConfigureDatabase()
{
    //some code
    this.instance = CredentialEditor.promptPossibleDialog(true); //This is line 281
}

This means you are running the dialog in the worker thread, which is not a good idea. Worker Threads are mostly, afaik, for non interactive background tasks. if you must run a dialog from within a worker thread, you must separately start it of in the EDT like:

public ConfigureDatabase()
{
    SwingUtilities.invokeLater(new Runnable() { //or if you must wait for its end, use invokeAndWait

        public void run() {
                CredentialEditor.promptPossibleDialog(true); //This is line 281
        }
    });
}

This should work. It would be more helpful if would provide a full SSCE, at first how you execute your Worker.

Also dialogs are for interacting with the user and bringing back a result. Saving the dialog in an instance is therefor not the best thing to do. instead store its result or rethink your design.

see here, an example:

Note: calling get on the Event Dispatch Thread blocks all events, including repaints, from being processed until this SwingWorker is complete.

When you want the SwingWorker to block on the Event Dispatch Thread we recommend that you use a modal dialog.

For example:

class SwingWorkerCompletionWaiter extends PropertyChangeListener {
     private JDialog dialog;

     public SwingWorkerCompletionWaiter(JDialog dialog) {
         this.dialog = dialog;
     }

     public void propertyChange(PropertyChangeEvent event) {
         if ("state".equals(event.getPropertyName())
                 && SwingWorker.StateValue.DONE == event.getNewValue()) {
             dialog.setVisible(false);
             dialog.dispose();
         }
     }
 }

Run as:

     JDialog dialog = new JDialog(owner, true);
     swingWorker.addPropertyChangeListener(
         new SwingWorkerCompletionWaiter(dialog));
     swingWorker.execute();
     //the dialog will be visible until the SwingWorker is done
     dialog.setVisible(true);

Specified by: get in interface Future Returns: the computed result Throws: InterruptedException - if the current thread was interrupted while waiting ExecutionException - if the computation threw an exception

Answer 2

You are stumbling over the Eclipse feature of allowing to run code even if it has compile errors, which does more harm than any good, imho. You may consider turning it off. However, what you have to understand is that there is no use in looking at the line number of the stack trace as that won’t necessarily tell you the line number of the compilation error but the line number where the exception has been generated at runtime.

There is no attempt to compile your code when it runs. Instead the compiler has generated code that will throw that exception unconditionally once the execution reaches the piece of code which Eclipse couldn’t compile. And so it hasn’t anything to do with the thread your code runs in. Since the spurious compiler error appears within CredentialEditor it’s unbelievable that modifications made at the caller shall change whether it compiles correctly or not. However since the code throws IllegalStateException when called in the background threads but you say that it works in your second scenario it seems that there are changes you didn’t tell us about.

On the other hand, the behavior doesn’t have to look logical if it’s caused by a bug. Normally, the exception contains the compiler error but the empty line in you stack trace perfectly matches the observed behavior that the IDE didn’t tell you about that error. So you hit a bug where there either a compiler error is assumed where none exists or that a compiler error exists for which the message is missing.

Hitting a compiler bug is not that surprising considering what you failed to mention, that you are using Java 8 and even actively use the new features. Eclipse’s Java 8 support is … well … has much room for improvements. Just check whether you are really using the most recent Eclipse version. If you are using or if the problem remains after updating I recommend you create a minimal example that reproduces the problem and doesn’t depend on any other (3rd party) classes and file a bug report to the Eclipse team.