Occasional InterruptedException when quitting a Swing application

Question

Your Disposer is blocked in a call to remove() (removing the next platform native resource). This means that the disposer thread (a daemon thread) is not being shutdown naturally when the VM exits (which you should expect since you are terminating it via System.exit()).

You have a non-daemon thread in your application which is keeping the VM from exiting when all your swing windows have been disposed.

Solution: find it and cause it to exit.

Normally a swing application exits gracefully if all of its swing windows have been disposed of, for example, this program will pop a window then exit once it is closed (all with no call to System.exit()):

public static void main(String args[]) throws Exception {
    JFrame jf = new JFrame();
    jf.setDefaultCloseOperation(JFrame.DISPOSE_ON_CLOSE);
    jf.setVisible(true);
}

You might also try running the garbage collector before exiting, just for kicks.

If you are using swing application then first call System.gc() and then call dispose() method. I think it will work fine.. I also use this.

Would like to up-vote this but I need more rep. This solution worked for me although I cannot find the explanation why and my co-worker also says it makes no sense.

I have 1.7 and a swing app that I have created, it reads in a file, rearranges the contents and then outputs to a file. has a run and quit button. uses preferences API, writer, reader, and a few other things. Upon opening and closing the app (without System.gc()) immediately only two times successively will return this same Exception as stated above. but with System.gc() right before dispose() I cannot get the Exception to throw again.

System.exit() probably isn't the cleanest way of closing down a Swing based app

Can't you set your main frame to EXIT_ON_CLOSE:

mainFrame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE )

Then set it to invisible?

Related Q here; System.exit(0) in java

I wonder if it is not related to this bug :

Java Bug 6489540

Basically it means that if Java2D is used when an InheritableThreadLocal object exists or a custom contextClassLoader is present they are captured and live forever causing memory leaks and possibly these kind of weird locks.

If this is the case a workaround would be to trigger a Java2D action on the main thread (i.e. immediately when the application starts) so the DisposerThread lives in a "squeky clean" environment. It is started by a static initializer so just a dummy load of a java2d resource and freeing it would be enough to get a DisposerThread which does not hang on to undesirable stuff.

I think i have found where the bug comes from !

When you have a basic java application with an Exit submenu into a File menu... There is a shortcut to activate the exit Action...This shortcut must makes a circular link or something like that...

There is the solutions :

First of all this is optional to get all clear: Implements this Interface "WindowListener" from your main window.

At the construction of this main window do this :

JFrame frame=this.getFrame();
if(frame!=null)
{
   Window[] windows=frame.getWindows();
   for(Window window : windows)
   window.addWindowListener(this);
}

implements the functions from the interface :

public void windowOpened(WindowEvent e) {}

public void windowClosing(WindowEvent e) {
    JFrame frame=this.getFrame();
    if(frame!=null)
    {
        Window[] windows=frame.getOwnedWindows();
        for(Window window : windows)
        {
            window.removeWindowListener(this);
            window.dispose();
        }
    }
    //clear();
    System.gc();
}

public void windowClosed(WindowEvent e) {}
public void windowIconified(WindowEvent e) {}
public void windowDeiconified(WindowEvent e) {}
public void windowActivated(WindowEvent e) {}
public void windowDeactivated(WindowEvent e) {}

After that you'll have to be careful about yours shortcuts ! You 'll have to remove the Action from the Exit Menu in order to manage it with an actionPerformed :

private void exitMenuItemActionPerformed(java.awt.event.ActionEvent evt) {
    //this.clear();
    svExitMenuItem.removeActionListener(null);//this call removes the end error from this way to exit.
    javax.swing.ActionMap actionMap = org.jdesktop.application.Application.getInstance(etscampide.ETScampIDEApp.class).getContext().getActionMap(ETScampIDEView.class, this);
    actionMap.get("quit").actionPerformed(null);//null to avoid end error too
}

I don't explain why but it works for me... I think that there is a kind of circular references... Hope to help you. See ya.

I have the same issue ( Java 6 ). I noticed an unknwon sun.awt.image.ImageFetcher thread in the debugger. I think it comes from me using JButtons with Icons. The ImageFetcher thread disappears after 2 seconds. If the ImageFetcher thread is not running my programm exits just fine.

It sounds like you have a thread running which hasn't terminated when you quit. Notably, the thread is wait()ing, and that method throws an interrupted exception if you try to stop the thread while it's running. I always set background threads to run as Daemons, which might help as well.

I would do the following in your JFrame:

myJFrame.setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
addWindowListener(new WindowAdapter() {
  public void windowClosing(WindowEvent we) {
    // Some pieces of code to instruct any running threads, possibly including
    // this one, to break out of their loops

    // Use this instead of System.exit(0) - as long as other threads are daemons,
    // and you dispose of all windows, the JVM should terminate.
    dispose();
  }
});

By manually breaking out of the loop, you allow the wait method to terminate (hopefully you're not waiting terribly long, are you? If you are, you might want to re-examine how you're utilizing your threads) and then get to a point in your code where it's safe to break - safe because you coded it to do so - and then the thread will terminate, letting the application terminate just fine.

Update Perhaps you are using the event dispatch thread inappropriately somewhere, and it's waiting/still working for you when you try to exit? The dispatcher thread should be doing as little work as possible, and should be passing anything complex off to another thread as quickly as it can. I'll admit I'm stabbing around in the dark a little bit, but I'm inclined to think it's not a bug, especially considering that you started noticing it on a more powerful machine - which to me screams "Race Condition!" not Java bug.