• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Understanding System.exit

 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have a graphics application (similar to autocad) that has a native compiled macro language that we still use extensively. I eventually plan to have everything in Java, but in the mean time I am trying to access java apps from the old application. The macro language has a single blocking system call $scall('cmd'). I have ran some simple tests and as long as I end the Java app with a System.exit() call all is well. But if I omit the System.exit() call, even though the java app completes its task and finishes, $scall('cmd') blocks forever. It happens whether I use java or javaw. Does anyone have a clue as to why? Not that it's a big deal to call System.exit(), but just curious.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Does the Java program you're dealing with use any Swing or AWT components? Once you create anything that can receive events, an event-listening thread is spawned, and it doesn't seem to die unless you explictly exit, or use something like setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE). Not sure if there's a better way to take care of this; I just get used to putting in an explicit exit() when I want a GUI to really exit. If there are no GUI components, then I have no idea what the cause is...
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No Swing or AWT, just a plain vanilla app. No way to connect a pipe between the two either (that's a real bummer). The java app creates a file which the graphics app reads afterwards.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Weird. You may be able to gain some useful info by sending a SIGINT (kill -INT [pid] on Unix; dunno the Windows equivalent). This can sometimes/often cause the Java program to suddently throw some sort of Error or Exception, I forget - which, if it's then caught and logged, gives you a stack tract which helps tell you what the heck the system was doing at the time the interrupt was sent. Maybe useful; maybe not. You might also consider starting another thread in your program which periodically wakes up and uses methods from ThreadGroup and Thread to go through all the active threads currently in the JVM and print out info on them, like their names at least. This can again give clues about what's still running after you thought everything else was finished.
[ April 10, 2003: Message edited by: Jim Yingst ]
 
Francis Siu
Ranch Hand
Posts: 867
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi Jim & Michael
Is there any different between using setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE)
and System.exit() when close the top level frame?
I mean the function meaning and the process using.
thanks
 
Michael Morris
Ranch Hand
Posts: 3451
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm not sure siu. I would guess though, that it would be a little more graceful than a System.exit(). For Swing apps, I usually set it to DO_NOTHING_ON_CLOSE so I can check the state of everything in a WindowAdapter and if all is well I just call System.exit().
BTW Jim, I do have a java.util.Timer to simulate a lengthy task and I did not set its thread to a daemon. That could be the problem although it only fires once. I'll try setting it to a daemon and see if that works. One other point to note, the $scall() utility apparently creates a cmd shell on windows systems because you can do $scall('dir') and a cmd window will pop up listing the graphics user's home directory. Alternatively, if you say $scall('regedit') or any other pure windows program, it simply returns without the external process ever starting. So, the problem could have to do with the cmd shell not giving up the ghost without the System.exit() call. The $scall() routine is supposed to return the exit status, but invariably returns 1. <Warning: Rant in progress> What is so upsetting about this sort of problem is that this particular graphics program was way ahead of its time. It was originally a Unix only app that ran on Sun minis. The original developers did an excellant design and implementation and created a robust graphics platform with a C-like compiled macro language. But when the Bozos that ported it to the Windows platform got thru with it, it just wasn't the same. This was circa 1996 and they decided to change the free-style Unix file naming convention to an enforced DOS 8.3 format! Man, I spent months putting out little grassfires and forrest fires from that idiocy. The damn thing doesn't run in DOS anyway. That's the most glaring thing that happened in the porting but believe me there are legions of others.
Michael Morris
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Using EXIT_ON_CLOSE is exactly equivalent to calling Systemexit(0) in response to a window close event. Here's the code from JFrame, JDK 1.4.1:

BTW Jim, I do have a java.util.Timer to simulate a lengthy task and I did not set its thread to a daemon. That could be the problem although it only fires once.
Could be, but once that task has completed the TimerThread should terminate, I think. If you're sure it's sheduled for single execution, not repeated. I'll be interested to hear what the cause is when you eventually discover it.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic