Disposing all Frames doesn't exit the JVM

[Andreas Pax Lück]

Hi friends! I hope you can help because I cannot see the mistake.

I've got a GUI application with a JFrame, a JOptionPane which appears and becomes closed and some daemon threads. The default close operation of the JFrame is set to "hide on close". Previously, I terminated my application by calling System.exit(0). But now, I have to replace this approach because of some GUI tests with the FEST library.

I tried to interrupt all created daemon threads and to invoke the dispose method on the JFrame but the JVM doesn't exit. In the end there are following threads running:

Thread [AWT-Shutdown] (Running)

Daemon Thread [AWT-Windows] (Running)

Thread [AWT-EventQueue-0] (Running)

Thread [DestroyJavaVM] (Running)

I also tried to dispose all still existing frames and windows with following piece of code:

        System.out.println("Terminate server application.");
        final Frame[] frames = Frame.getFrames();
        System.out.println("all frames:");
        if (frames != null)
            for (final Frame f : frames)
            {
                System.out.println("\t\t" + f.getTitle());
                f.dispose();
            }

        final Window[] windows = Window.getWindows();
        System.out.println("all windows:");
        if (windows != null)
            for (final Window w : windows)
            {
                System.out.println("\t\t" + w);
                w.dispose();
            }

The console outputs show following (curious) windows. I only know some of them:

all frames:

.::. Glass Wave Spider - Server control panel
PopupMessageWindow
all windows:
javax.swing.SwingUtilities$SharedOwnerFrame[frame0,0,0,158x45,invalid,hidden,layout=java.awt.BorderLayout,title=,resizable,normal]
de.paxoftwer.forms.JSplashScreen[win0,695,454,291x143,invalid,hidden,layout=java.awt.BorderLayout,rootPaneCheckingEnabled=true]
de.paxoftwer.gws.server.gui.view.ConsoleFrame[mainFrame,464,204,752x595,invalid,hidden,layout=java.awt.BorderLayout,title=.::. Glass Wave Spider - Server control panel,resizable,normal,defaultCloseOperation=HIDE_ON_CLOSE,rootPane=javax.swing.JRootPane[,9,36,734x550,invalid,layout=javax.swing.JRootPane$RootLayout,alignmentX=0.0,alignmentY=0.0,border=,flags=16777673,maximumSize=,minimumSize=,preferredSize=],rootPaneCheckingEnabled=true]
java.awt.Frame[frame1,0,0,158x45,invalid,hidden,layout=java.awt.BorderLayout,title=PopupMessageWindow,resizable,normal]

What is "SharedOwnerFrame" or "Frame" or "PopupMessageWindow"?

Finally, the meantioned threads are keeping alive and the JVM doesn't terminate. I tried to reproduce this issue with a very simple example but the invalid behavior didn't occur. I don't see the essential difference between this example and my application. The application uses the system tray (if this is important).

Thanks for your help.

Best regards


PAX

[Stephan van Hulst]

Well Andreas, it's hard to say without knowing your code. I don't know how this library you're using works, and how it interacts with your GUI. It very well may be the thing keeping your application alive.

You likely have some hidden frames lying around which keep the event dispatch thread operational. SharedOwnerFrame is probably a frame that Swing makes as the owner when you create a dialog without an owner (probably the PopupMessageWindow).

It seems whatever this popup is, it's hidden and keeping the shared owner alive as well.

See if you can create an SSCCE that reproduces the problem.

[Darryl Burke]

A few observations:

Window maintains a weak reference to every Window created (even those that have been disposed and/or are no longer reachable), so it's good practice to call System.gc() before getWindows(). Yes, calling gc() theoretically doesn't guarantee garbage collection, but in fact it does, in every Sun VM to date.

The name tellls you where you can look for SharedOwnerFrame -- it's an inner-or-nested class of SwingUtilities. In the version I have, it's found at line 1733 (package-private static class).

Research suggests that PopupMessageWindow may be associated with the TrayIcon (see http://www.docjar.com/html/api/sun/awt/windows/WTrayIconPeer.java.html)

[Rob Spoor]

SharedOwnerFrame is used with JOptionPane, for instance. JOptionPane has a habit of not closing its dialog if you take control over it yourself. If you use the static methods - not a problem. But if you do something like the following, the dialog is not disposed when you close it:

JOptionPane pane = ...;
JDialog dialog = pane.createDialog(...);
dialog.setVisible(true);

You need to add a dialog.dispose() afterwards to dispose it.

[Andreas Pax Lück]

Alright, my friends... This was very tricky... I just like this forum! Your good advices navigated me to the intrinsic issue!

Actually, there were two issues who prevented my application from terminating. The first very important thing is:

If you use tray icons you have to remove them from the system bar - otherwise, the JVM won't quit.

You can just obtain (and remove) all icons with following piece of code:

        final TrayIcon[] icons = SystemTray.getSystemTray().getTrayIcons();
        for (final TrayIcon icon : icons)
            SystemTray.getSystemTray().remove(icon);

And my second fail was that I created a special Timer thread that enqueued items into the event dispatching queue, continiously, if the application wasn't currently minimized.

I'm glad that we localized all these bugs because this wasn't easy to find out.

Very good work! Thank you so much!

Best regards


PAX