File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Swing / AWT / SWT and the fly likes Disposing all Frames doesn't exit the JVM Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Swing / AWT / SWT
Bookmark "Disposing all Frames doesn Watch "Disposing all Frames doesn New topic

Disposing all Frames doesn't exit the JVM

Andreas Pax Lück

Joined: Nov 04, 2009
Posts: 18
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:
    all frames:

    .::. Glass Wave Spider - Server control panel
    all windows:
    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.

    Best regards


    "Wenn man irgendwann mal von allen akzeptiert wird, dann weiß man, dass man irgendwas falsch gemacht hat."
    Excerpt by: Mr. Weidner
    Stephan van Hulst

    Joined: Sep 20, 2010
    Posts: 4616

    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.
    Darryl Burke

    Joined: May 03, 2008
    Posts: 5115

    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

  • luck, db
    There are no new questions, but there may be new answers.
    Rob Spoor

    Joined: Oct 27, 2005
    Posts: 20271

    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.

    SCJP 1.4 - SCJP 6 - SCWCD 5 - OCEEJBD 6 - OCEJPAD 6
    How To Ask Questions How To Answer Questions
    Andreas Pax Lück

    Joined: Nov 04, 2009
    Posts: 18
    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:

    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

    I agree. Here's the link:
    subject: Disposing all Frames doesn't exit the JVM
    It's not a secret anymore!