wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes How do I kill a GUI thread without exiting JVM? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "How do I kill a GUI thread without exiting JVM?" Watch "How do I kill a GUI thread without exiting JVM?" New topic
Author

How do I kill a GUI thread without exiting JVM?

Paul Smiley
Ranch Hand

Joined: Jun 02, 2000
Posts: 244
Hi all,
I'm doing some JUnit tests and am having difficulty terminating a GUI thread. I have a JFrame that is displayed in one thread with the JUnit in another. I want the JUnit thread to be able to terminate the GUI without clicking a close window button. I have done a destroy() on the GUI thread that apparently terminates it, but the GUI itself is still presented to the user. Any ideas?
Chris Shepherd
Ranch Hand

Joined: Jun 27, 2000
Posts: 286
Since GUIs start their own threads when they are created, try killing the GUI instead of its thread. when the GUI dies, so will its thread.
I use guiFrame.dispose().
John Dale
Ranch Hand

Joined: Feb 22, 2001
Posts: 399
Are you trying to kill the various threads that are fired up when you use Swing, like the dispatch thread? From what I've seen, that doesn't go away when you dispose() of everything. I'm looking forward to a good answer to your question.
Paul Smiley
Ranch Hand

Joined: Jun 02, 2000
Posts: 244
Thanks, guys. I'm running a JUnit program in a JVM which forks off a Thread that starts a GUI. I want to exercise each of the public methods in the GUI classes. After that is done, I want to exit the GUI.
At this point, I cannot access the listeners that would close the GUI. So yes, John, I'd like to kill all threads except the main one that the JUnit is running in. The problem appears to be that the GUI thread is blocking - waiting for user input. I thought that the easiest way was to kill the GUI thread, but it is not that simple - or so it appears.
Chris Shepherd
Ranch Hand

Joined: Jun 27, 2000
Posts: 286
Hmm I'm not sure I know what a JUnit program is and what its supposed to do...
Tell me more about this GUI... Is it based on JFrame? Did you write it and are you allowed to change it? If it's based on JFrame and you can change it, you could just extend JFrame and include a static variable that points to the gui you have open(itself). Then you would be able to call YourFrame.openFrame.dispose(). Thats assuming you would never have 2 open at once when you needed the self pointer.
Not knowing JUnit, this may be a dumb question, but do you actually create a seperate thread to create a GUI? Why not just skip a thread and create the GUI directly?
Paul Smiley
Ranch Hand

Joined: Jun 02, 2000
Posts: 244
JUnit - http://www.junit.org
In order to do a test I have to create a GUI, interact with it from outside, and then destroy it. Our tests are all automated (via Ant), so we want to go on to the next test without killing the JVM and without leaving garbage behind. I need Threads for 1) the GUI and 2) for the interaction with the GUI. The GUI, when presented, blocks waiting for customer input. My second thread exercises the GUI from outside. When the exercises are done, I need to get rid of the GUI - unblocking it.
Basically, I had to throw an exception into my GUI and then kill the thread with:
this.currentThread().stop(new ThreadDeath()); this.currentThread().destroy();
If anyone can think of a cleaner way of doing it, I'm all ears!!
Paul
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

I think you are not realizing what the GUI thread is. the GUI thread that people commonly refer too is not the thread that started the GUI, but the thread that the GUI actually runs in. There are several threads related to the GUI. Their is no need to create a thread to start a GUI from because simply starting a frame like
new Frame().setVisible(true)
will create a set of threads. 1 is the display update thread, another is the events thread. these 2 threads will die when you call dispose on yout last existing GUI object. as for the thread that you use to start the GUI, I dont know what it looks like so I cant say when it will die but I assure you
new JFrame().setVisible(true); is not a blocking call.
Chris Shepherd
Ranch Hand

Joined: Jun 27, 2000
Posts: 286
CL Gilbert, doesn't each frame create its own set of threads? Or is there really only 1 set of threads that handles all open frames and their events? I always thought that each open frame got its own set of threads... I just want to be sure I know... This is a bit off from what Paul asked, but maybe it will help him as well...
Thanks
Mr. C Lamont Gilbert
Ranch Hand

Joined: Oct 05, 2001
Posts: 1170

No, each frame does not create its own set of threads. If that were the case managing modal issues would be such a pain. In any event, only 1 is active at any one time and their is only 1 swing/AWT event thread. If you have a debugger you should be able to see the running threads to verify for yourself what happens. But yes, their is 1 eventThread, and I am not sure but I think their is one painting thread too.
 
 
subject: How do I kill a GUI thread without exiting JVM?
 
Similar Threads
ConfigurationException
Junit advantages
Distribute with or without dependencies?
Novie JUNIT user need helps - NoClassDefFoundError + bash + windows
How to mock the Swing thread?