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:
The console outputs show following (curious) windows. I only know some of them:
.::. Glass Wave Spider - Server control panel
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]
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.
"Wenn man irgendwann mal von allen akzeptiert wird, dann weiß man, dass man irgendwas falsch gemacht hat." Excerpt by: Mr. Weidner
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.
The mind is a strange and wonderful thing. I'm not sure that it will ever be able to figure itself out, everything else, maybe. From the atom to the universe, everything, except itself.
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).
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:
You need to add a dialog.dispose() afterwards to dispose it.