File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Disposing all Frames doesn't exit the JVM

 
Andreas Pax Lück
Greenhorn
Posts: 18
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
    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
    Bartender
    Pie
    Posts: 4826
    34
    Chrome Netbeans IDE Windows
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Bartender
    Posts: 5115
    11
    Java Netbeans IDE Opera
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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
    Sheriff
    Pie
    Posts: 20369
    44
    Chrome Eclipse IDE Java Windows
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    Andreas Pax Lück
    Greenhorn
    Posts: 18
    • 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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


    PAX
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic