> Hey everyone,

> So, I have started testing on a product that is new to me. The code
> for the gui is using System.exit which kills the whole VM and so I
> cant run more than one test...I am trying to figure out a way to
> remove this but have been unsucessful. When I just remove the
> System.exit() line the program will never exit by itself. I looked at
> the java docs and found this:
> ...

> Simeon

> On Fri, Nov 6, 2009 at 5:29 PM, bpedman <bped...@gmail.com> wrote:

>> Hey everyone,

>> So, I have started testing on a product that is new to me. The code
>> for the gui is using System.exit which kills the whole VM and so I
>> cant run more than one test...I am trying to figure out a way to
>> remove this but have been unsucessful. When I just remove the
>> System.exit() line the program will never exit by itself. I looked at
>> the java docs and found this:
>> ...

> So, I have started testing on a product that is new to me. The code
> for the gui is using System.exit which kills the whole VM and so I
> cant run more than one test...I am trying to figure out a way to
> remove this but have been unsucessful. When I just remove the
> System.exit() line the program will never exit by itself. I looked at
> the java docs and found this:

> With the current implementation, AWT terminates all its helper threads
> allowing the application to exit cleanly when the following three
> conditions are true:

>     * There are no displayable AWT or Swing components.
>     * There are no native events in the native event queue.
>     * There are no AWT events in java EventQueues.
> <http://java.sun.com/javase/6/docs/api/java/awt/doc-files/
> AWTThreadIssues.html#Autoshutdown>

> So, I replace System.exit() with this:

> Window[] activeWindows = Window.getWindows();
> for (int i=0; i<activeWindows.length; i++) {
>     activeWindows[i].dispose();
>     activeWindows[i] = null;}

> EventQueue eventQueue =  Toolkit.getDefaultToolkit
> ().getSystemEventQueue();
> while(eventQueue.peekEvent() != null){
>     eventQueue.getNextEvent()

> }

> And it still sits there and waits for something...is there something
> else I need to do???

> Thanks for any help

> -Brandon

> as I understand to exit the application without call to System.exit()
> you must ensure 2 things:
> 1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE for
> this purpose);
> 2) no *live* thread is running (you can use daemon threads for
> background tasks).
> Due to all your windows are probably disposed, I suspect there is at
> least one non-daemon thread running.

> Andriy

> On Nov 7, 12:29 am, bpedman <bped...@gmail.com> wrote:

> Andriy Tsykholyas wrote:
> > Hi,

> > as I understand to exit the application without call to System.exit()
> > you must ensure 2 things:
> > 1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE for
> > this purpose);
> > 2) no *live* thread is running (you can use daemon threads for
> > background tasks).
> > Due to all your windows are probably disposed, I suspect there is at
> > least one non-daemon thread running.

> Well be careful that Swing dialogs use a hidden window (can't remember
> for which purpose exactly) that is reused for all dialogs and never
> disposed of. Hence you have to find a ref to it and dispose it as well!
> Also beware that this way of exiting a Swing application won't work with
> Java Web Start :-(
> If using Java Web Start for your app, you definitely have to  call
> System.exit().

> I remember when I was using abbot (a couple of years ago), it had a
> trick to intercept System.exit() and it was working fine with my app.
> Maybe FEST should reuse the same trick?

> Cheers

> Jean-Francois
> > best regards

> > Andriy

> > On Nov 7, 12:29 am, bpedman <bped...@gmail.com> wrote:

> Does that make sense? If it does, Brandon, can you please file a bug?

> Jean-Francois, is this similar to Abbot's solution (I tried to find it
> but couldn't)

> On Sat, Nov 7, 2009 at 5:11 PM, Jean-Francois Poilpret
> <jfpoilp...@gmail.com <mailto:jfpoilp...@gmail.com>> wrote:

>     Andriy Tsykholyas wrote:
>     > Hi,

>     > as I understand to exit the application without call to
>     System.exit()
>     > you must ensure 2 things:
>     > 1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE for
>     > this purpose);
>     > 2) no *live* thread is running (you can use daemon threads for
>     > background tasks).
>     > Due to all your windows are probably disposed, I suspect there is at
>     > least one non-daemon thread running.

>     Well be careful that Swing dialogs use a hidden window (can't remember
>     for which purpose exactly) that is reused for all dialogs and never
>     disposed of. Hence you have to find a ref to it and dispose it as
>     well!
>     Also beware that this way of exiting a Swing application won't
>     work with
>     Java Web Start :-(
>     If using Java Web Start for your app, you definitely have to  call
>     System.exit().

>     I remember when I was using abbot (a couple of years ago), it had a
>     trick to intercept System.exit() and it was working fine with my app.
>     Maybe FEST should reuse the same trick?

>     Cheers

>     Jean-Francois
>     > best regards

>     > Andriy

>     > On Nov 7, 12:29 am, bpedman <bped...@gmail.com
>     <mailto:bped...@gmail.com>> wrote:

> Apparently this is a bug in java that they are not going to fix.http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4465537

> Alex Ruiz wrote:
> > I think Simeon's link is a possible solution for this issue. I'm
> > thinking about providing a hook that doesn't allow the JVM to
> > terminate on System.exit until all tests are executed.

> > Does that make sense? If it does, Brandon, can you please file a bug?

> > Jean-Francois, is this similar to Abbot's solution (I tried to find it
> > but couldn't)

> Hi Alex, yes I just checked the link provided by Simeon and it uses the
> same trick as in Abbot.
> In abbot, there are several classes for this problem (IIRC they are a
> bit hard to follow and understand):
> - abbot.NoExitSecurityManager
> - abbot.util.ThreadTerminatingSecurityManager (not sure where this one
> is used)
> - abbot.ExitException
> - abbot.StepRunner (defines ExitHandler -derived from
> NoExitSecurityManager- and sets it as SecurityManager
> - abbot.ForkedStepRunner (refines further ExitHandler to notify -through
> sockets- the script launcher in case of termination attempt)

> Basically that's it! I think the most important for udnerstanding the
> whole stuff are NoExitSecurityManager, ExitException and StepRunner. I
> hope I haven't missed some other classes impacted by that.

> Cheers

> Jean-Francois
> > Thanks!
> > -Alex

> > On Sat, Nov 7, 2009 at 5:11 PM, Jean-Francois Poilpret
> > <jfpoilp...@gmail.com <mailto:jfpoilp...@gmail.com>> wrote:

> >     Andriy Tsykholyas wrote:
> >     > Hi,

> >     > as I understand to exit the application without call to
> >     System.exit()
> >     > you must ensure 2 things:
> >     > 1) all windows are disposed (you can use Window.DISPOSE_ON_CLOSE
> for
> >     > this purpose);
> >     > 2) no *live* thread is running (you can use daemon threads for
> >     > background tasks).
> >     > Due to all your windows are probably disposed, I suspect there is
> at
> >     > least one non-daemon thread running.

> >     Well be careful that Swing dialogs use a hidden window (can't
> remember
> >     for which purpose exactly) that is reused for all dialogs and never
> >     disposed of. Hence you have to find a ref to it and dispose it as
> >     well!
> >     Also beware that this way of exiting a Swing application won't
> >     work with
> >     Java Web Start :-(
> >     If using Java Web Start for your app, you definitely have to  call
> >     System.exit().

> >     I remember when I was using abbot (a couple of years ago), it had a
> >     trick to intercept System.exit() and it was working fine with my app.
> >     Maybe FEST should reuse the same trick?

> >     Cheers

> >     Jean-Francois
> >     > best regards

> >     > Andriy

> >     > On Nov 7, 12:29 am, bpedman <bped...@gmail.com
> >     <mailto:bped...@gmail.com>> wrote:

> You might want to use some profiler to find the problem. The one
> bundled with netbeans is free and should be sufficient for this
> purpose. You can check both threads and windows there.

> A bit off-topic, but if you've not checked out the latest
> VisualVM<https://visualvm.dev.java.net/> (bundled
> with Java 6 except on MacOS) for profiling of all sorts. It's pretty sweet.
> It will run standalone and/or integrated with Netbeans or Eclipse (I think
> it's built on the Netbeans framework, so the integration is better there).

> Here's a screencast<http://e.blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss...>of
> it in action.

> Simeon

> Thanks, VisualVM is nice....

> So, I am using it and I am still a bit lost as to what it could be,
> here is an image of the running threads:

> http://imagebin.ca/view/5fDJCbty.html

> And then the thread dump shows:

> http://pastebin.com/m28935f17

> It looks like the only non-daemon threads are AWT-Shutdown, AWT-
> EventQueue-0, DestroyJavaVM, and FlushBufferTimerTask

> Not sure what the FlushBufferTimerTask is, Any thoughts?

> Thanks,

> -Brandon

> On Nov 8, 12:36 pm, Simeon Fitch <simeon.fi...@mseedsoft.com> wrote:
> > > You might want to use some profiler to find the problem. The one
> > > bundled with netbeans is free and should be sufficient for this
> > > purpose. You can check both threads and windows there.

> > A bit off-topic, but if you've not checked out the latest
> > VisualVM<https://visualvm.dev.java.net/> (bundled
> > with Java 6 except on MacOS) for profiling of all sorts. It's pretty
> sweet.
> > It will run standalone and/or integrated with Netbeans or Eclipse (I
> think
> > it's built on the Netbeans framework, so the integration is better
> there).

> > Here's a screencast<
> http://e.blip.tv/scripts/flash/showplayer.swf?file=http://blip.tv/rss..
> .>of
> > it in action.

> > Simeon