5

Up to now I used my application as a stand alone product. So, when user pressed "Stop" button I called System.exit(0); and it was fine.

Now my application will be called (in a programmatic way) from another program. So, I afraid that System.exit(0); will kill not only my process but also the external software which started my program.

So, what is the correct way to shutdown my application if a corresponding request from an external software is received? My application is an GUI application. So, I want to close the window but I also want to close all processes performed by my program.

ADDED:

To be more specific, I want to close all threads started by my program. My program does not start any OS process or any other program.

Bart Kiers
  • 166,582
  • 36
  • 299
  • 288
Roman
  • 124,451
  • 167
  • 349
  • 456
  • @Roman: by *"processes performed by my program"* do you mean all the threads your Java program is running or did your program spawn, say, other executables (Un*x shell processes, .exe, other Java program running in their VM, whatever)? – SyntaxT3rr0r Apr 21 '10 at 16:01
  • @WizardOfOdds, I mean "all threads my Java program is running". – Roman Apr 21 '10 at 16:07
  • 1
    How is your program invoked? Is some method of it called by an already running Java program, so effectively the two become one program? Or is the other program making a system call to start a new Java VM with your program? – Christian Semrau Apr 21 '10 at 16:25
  • The answer I gave below describes how to terminate threads properly - not processes. I hope you find it helpful. – Steve Neal Apr 26 '10 at 11:03

4 Answers4

2

If the threads you've launched are still processing then calling System.exit(0) will cause them to be killed. In some cases, this can leave your application in an inconsistent state. Imagine that the thread was saving a file for example.

You should ensure that the your threads are all 'happy' to die before calling System.exit.

One technique you can use for this with long running threads is poisoning. To do this you send the threads a message that they should now die gracefully - i.e. a poson message. Once they have all died, it is safe to call System.exit(0) to terminate the Swing event handling thread.

There a loads of different ways of implementing poisoning, you could just set a global flag variable that the threads check to see if they've been poisoned, or you could use the Java 5 threading libraries. Take a look at this Javadoc for example and you'll find references to this technique:

http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/BlockingQueue.html

Steve Neal
  • 756
  • 3
  • 8
  • 16
0

As long as your programm isn't sharing an application server with others, shuting down the VM by calling System.exit(0) terminates all threads.

From Javadoc System.exit Terminates the currently running Java Virtual Machine)

EDIT: If you want to do some clean up code before shutdown, http://java.sun.com/j2se/1.4.2/docs/guide/lang/hook-design.html

stacker
  • 68,052
  • 28
  • 140
  • 210
  • @stacker, do you mean that `System.exit(0)` will shut all threads down including thread of the external software (which started my program). – Roman Apr 21 '10 at 16:18
  • 1
    It will kill the JVM. So if the external software started your program by spawning a Java process, it will be fine. If the external software is Java code that simply creates an instance of your class(es) and runs them, then that external code will be killed too. – Andrzej Doyle Apr 21 '10 at 16:37
0

There is on "one-size-fits-all" answer to this that's a drop-in replacement for System.exit, unfortunately.

You will generally need to set some kind of flag that signals to all of your threads that it is time to exit, and ensure that they check this flag regularly. This will let them clean up gracefully without stopping abruptly, and it also ensures the effects are limited to your own components. In this case your application's main thread would also observe the flag, wait for all the "worker" type threads to finish and would then return all the way up the stack until your application's entry point was reached.

This question is not too dissimilar to the deprecated Thread.stop (etc) methods, especially with regards to replacing System.exit with something more respectful. In that light, the why is Thread.stop() deprecated page may be useful reading.

Throwing an exception (a custom one called something like ApplicationStopException) to unwind the stack of the main thread is not such a bad idea; this prevents you from having to handle the special logic all over your code and instead lets the "message" propagate to the higher levels, where they can take whatever action is needed to exit your program gracefully.

Community
  • 1
  • 1
Andrzej Doyle
  • 102,507
  • 33
  • 189
  • 228
0

I recommend you to do flagging to stop the thread so that the thread will know when it has to stop. For GUI and window, you can call frame.dispose().

For System.exit(), I think it will not affect the caller, you may try to see what is the real effect but as other people already recommended, do not call it directly like that, just let the threads stop by itself

vodkhang
  • 18,639
  • 11
  • 76
  • 110