Does JFrame setVisibility(false) stop all threads I created? - java

When executing the command this.setVisible(false), does it stop all threads that are running specifically on that frame?
If not, is there an easy way to stop all of them automatically?

I think we have a conceptual problem here. There are no "threads running on a JFrame." There is one thread, the Event Dispatch Thread, that runs ALL Swing objects, frames, etc.
The EDT (Event Dispatch Thread) does not stop because you made one window invisible. However, if ALL Swing objects become unreachable (eligible for garbage collection) then the Swing EDT does shut down. (The app-note linked below says you can also call Window.dispose() on a frame to make it undisplayable; it then no longer counts for keeping the EDT running.)
The more precise conditions for shutting down the EDT are in this app-note:
Starting with 1.4, the behavior has changed as a result of the fix for
4030718. 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.
Prior to Java 1.4, the EDT never shuts down. Hopefully you don't need to go that far back.
If you want to shutdown a group of threads, you have to do it manually (other than using some course method like System.exit()). I would look at Executors which enable you to manage threads fairly easily.

No, setting the JFrame visibility to false won't stop all threads you created with new Thread().
If not, is there an easy way to stop all of them automatically?
To stop all of them automatically there is no way (unless terminate all the program)
You need to have them stored in a list or a vector, for example, and then use the method Thread.interrupt()
Something like this:
for(Thread thread : threads) //where threads is a List
{
thread.interrupt();
}

No it does not!
The Thread does still run in background, but you cant interact with the Frame.
To Stop all threads you could do:
System.exit(1) which would terminate all Threads or for every Thread
Thread.sleep(10000000000); which would stop the Thread for a certain amount of time (in milliseconds).

Related

Event Dispatching Thread execution

With Java Swing, is it possible to pause the current thread Runnable and give room to the Event Dispatching Thread to update the gui?
I know it is possible with multi-threading (SwingWorker class) but I was wondering if there's an easier way to achieve this for single threaded programs (aka: all my code is in the gui's Run()).
E.g. Matlab has the very convenient drawnow; method
If not: how can I split the updating task to a second thread without having to rewrite anything? Would that be the Updating the gui from a running thread from this link?
The short answer is no. If you pause the current thread (which according to you is the EDT) then you pause the EDT...
You can make requests that the UI be updated using methods like repaint, but this also assumes you are not blocking the EDT with things like loops and pauses, as the EDT will need time to process these requests.
And no, I wouldn't follow the link's advice, as it violates the single thread of Swing by updating the components outside of the of EDT
Depending on your needs you would either need to use a javax.swing.Timer or SwingWorker. Yes, you can use a Thread, you become responsible for ensuring that all updates to the UI are synced back to the EDT, which the other two suggest provide mechanisms for.
Take a look at Concurrency in Swing for more details

Thread output listener

I need to make a thread that start at swing button push and wait for input from rs232, process it and return String to my variable. The question is how to do that?
it should be something like that:
String myOutputString = waitForInputThread();
Or if its possible in swing panel make something like listener that do something if this waitForInputThread send interrupt (for example, if get rs232 input do update a list of items in JTable).
Could you give me some clues, tutorials, examples etc ?
To avoid blocking the Event Dispatch Thread (which is the thread that updates the GUI), start a new thread to interact with the RS232. The SwingWorker class is one option, but you can just as easily use a normal thread.1 Blocking the EDT causes your GUI to freeze, so it must never be used for lengthy tasks.
Once your result is computed, update the GUI using SwingUtilities.invokeLater(). This ensures the GUI change occurs on the EDT.
1 I tend to find normal threads executed via an ExecutorService are better for unit testing (as you can write an ExecutorService that immediately executes the Runnable, avoiding any nasty thread issues with JUnit).

EDT in Java, how does it work, does it behave like normal thread (single or mutli)?

this is a beginner question:
I am working on a small chat program that use TCP to deliver messages, and I have a simple GUI to display it, I have finished the program, but the EDT has confused me a lot...
does EDT behave like it "extends Thread"? I imagine it is a single thread since I will need worker thread to process the heavy logic, but apparently I can not do Thread.sleep/yield (I have a while loop that constantly reading message from the outputstream and append to the jTextArea, running in main Thread, I tried to terminate the while loop by set a false flag and then yield to main Thread, did not work.)
I am not so sure about how listener works, if I have to write it...I will probably start a thread for each listener, as soon as I hear something I will process it...but this is definitely wrong because it will make EDT a multithread ( a lot of ears ) but singlethread during the process ( only 1 brain )
This must be me lacking knowledge!! because in my head I just can not figure out how to fire an event... you pressed a button and java suddenly knows? I must missed something.
My first time post a question, hope it is clear
The Event Dispatching Thread is a Thread like any other Thread in Java.
It is responsible for dispatching all events and repaint requests (and few other things, like running synchronized Runnable). Any action you take that blocks the EDT will stop it from processing these events, making it look like your application has hung ... because basically it has.
All interactions with any UI component MUST be executed within the context of the EDT. That means you should never try and create or update any UI component from any Thread other then the EDT.
If you need to do any actions that are blocking or time consuming, you should use another thread. SwingWorker is an excellent place to start.
Adding listeners to component will not create more threads. The EDT will post event notifications back to the listeners (this is an incredibly shortened explanation, but the concept is sound), this is one of the reasons why you should never block the EDT.
How events are raised depends on the component. Mouse and keyboard events for example, will be posted to the Event Queue by a native portion of code dependent on the OS/implementation (as I understand it, coming from the ToolKit, but I could be wrong).
actionPerformed events raised by JButtons may be executed directly against the listener (not dispatched via the Event Queue), but within the EDT. This are raised by any number of events, but typically caused by mouse clicks and special key events. The JButton is notified of these because it registers itself with the Event Queue.
While getting an understanding of the workings is a good goal, you need to ask yourself, does it matter (in the short term)? Do you know how electricity gets from the light switch to the light? Or do you only care that it does?
Understand the rules required to use it (don't stick sharp objects into the power points) and let the understanding come as you become more confident.

Get a notification in Swing when a thread completes / is finished

It seems I miss a certain point in Java and Swing. The issue is as follows:
I have a swing GUI with a Start / Stop button (And some more)
It starts the function (What is set up as a thread in this case), Thread starts, it works, Swing GUI is fully operational and does all the other things it is made for, e.g. modifying parameters for the worker thread.
Of course, sending an interrupt to ask the thread to stop on users request is in and functions. So far so good.
But I did not found a way that Swing GUI notices the thread stopped on its own:
If I ignore it, it confuses the user.
I of course put a loop in, where Swing GUI regularly asks if Thread.isAlive (And sleeps some time to ask again), but this loop completely blocks Swing GUI.
Ideally, I would like to get a notification or an event that the thread has stopped.
Just like all the other events, Swing processes:-) .
What is the proper way to set it up?
Have a look at the SwingWorker. It is designed to perform tasks on the background as the result of a Swing event such a button press. It has hooks to listen for when the task finishes.
use a boolean flag 'done' private field. initialize done=false; when your thread run() method is complete set done=true inside thread run() method.
monitoring the value of the flag 'done' will tell you when your thread has finished.

What is the event dispatching thread?

I know what "thread" means and if I understand the event dispatching thread (EDT) as
"just a thread", it explains a lot but, apparently, it does not explain everything.
I do not understand what is special about this thread. For example I do not understand why we should start a GUI in a the EDT? Why the "main" thread is bed for GUI? Well, if we just do not want to occupy the main thread why we cannot start GUI just in "another thread" why it should be some "special" thread called EDT?
Then I do not understand why we cannot start the EDT like any other thread? Why we should use some special tool (called invokeLater). And why GUI, unlike any other thread, does not start immediately. We should wait until it is ready to accept our job. Is it because EDT can, potentially execute several task simultaneously?
If you decide to answer this question, could you pleas use a really simple terminology because otherwise, I am afraid, I will not be able to understand the answer.
ADDED:
I always thought that we have one "task" per thread. So, in every thread we execute a predefined sequence of commands. But it seems to me that in the event dispatching thread we can have sever task. Well, they are not executed simultaneously (thread switches between different task but there are still several task in one thread). Is it right? For example there is one thread in the EDT which display the main window, and then additionally to that we sent to the EDT another task which should update one of the window components and EDT will execute this new task whenever it is ready. Is EDT differ from other threads in this way?
The event dispatching thread is the thread that handles all GUI events and manages your Swing GUI. It is started somewhere in the Swing code if you have any GUI in your program. The reason it is done behind the scenes is because of simplicity - you do not have to bother with starting and managing an extra thread by yourself.
Regarding the fact that you have to update your GUI with invokeLater() it is because of concurrency issues. The GUI can be modified only from one thread because Swing is not thread safe(it is worth to note that most of toolkits are not thread safe, there is a nice article that gives some ideas why). This is why you have to submit all GUI updates to run on EDT.
You can read more on concurrency in Swing and event dispatching thread in Sun tutorial on concurrency in Swing. Also, if you would like to see how this could be done in a different way you might like to check out SWT toolkit. In SWT you have to manage EDT by yourself.
I always thought that we have one
"task" per thread. So, in every thread
we execute a predefined sequence of
commands. But it seems to me that in
the event dispatching thread we can
have sever task. Well, they are not
executed simultaneously (thread
switches between different task but
there are still several task in one
thread). Is it right? For example
there is one thread in the EDT which
display the main window, and then
additionally to that we sent to the
EDT another task which should update
one of the window components and EDT
will execute this new task whenever it
is ready. Is EDT differ from other
threads in this way?
No, the EDT is not fundamentally different from other threads. And "task" is not a good word to use, because it could be confused with OS-level processes (which are also often called task). Better use Runnable, the interface used to give code to the EDT to execute via invokeLater().
The EDT is basically connected to a queue of things it has to do. When the user clicks a button on the GUI, a Runnable that notifies all listeners attached to the button goes into the queue. When a window is resized, a Runnable doing revalidate&repaint goes into the queue. And when you use invokeLater(), your Runnable goes into the queue.
The EDT simply runs an endless loop that says "take a Runnable from the queue (and if it's empty sleep until you're notified that it's not) and execute it.
Thus, it executes all those little Runnable pieces of code one after another, so that each of them basically has the GUI all to itself while it runs, and doesn't have to worry about synchronizing anything. When you manipulate the GUI from another thread, this assumption is broken, and you can end up with the GUI in a corrupted state.
What is the EDT?
It's a hacky workaround around the great many concurrency issues that the Swing API has ;)
Seriously, a lot of Swing components are not "thread safe" (some famous programmers went as far as calling Swing "thread hostile"). By having a unique thread where all updates are made to this thread-hostile components you're dodging a lot of potential concurrency issues. In addition to that, you're also guaranteed that it shall run the Runnable that you pass through it using invokeLater in a sequential order.
Note that it's not just that you're dodging the concurrency issue: you must respect Sun's guidelines regarding what must and what must not be done on the EDT or you'll have serious problems in your application.
Another benefit is that some Swing components tend to throw unwanted exceptions and when this happen they're automagically dealt with and won't crash the EDT (AFAIK if you really manage to kill the EDT it is automagically restarted).
In other words: you don't have to deal with all the broken Swing components and the exceptions they throw yourself: the EDT is taking care of that (just take a look at the countless Swing bugs throwing exceptions in Sun's bug parade, it's fascinating... And yet most apps keep working normally).
Also, by doing only what's mandatory in the EDT allows the GUI of your app to stay "responsive" even tough there may be tasks running in the background.
The important thing to remember is that Swing classes are not thread-safe. This means that you always should call Swing methods from the same thread, or you risk getting weird or undefined behavior.
So the solution: only call Swing methods from a single thread. This is the EDT thread - it's not special in any way other than that it is the thread designated to call swing methods from.
Now you may ask why are Swing methods not thread safe? After several unsuccessful attempts, GUI toolkit designers discovered that it's inherently impossible to design a thread-safe GUI toolkit. Too often events are passed in opposite directions (input events from bottom to top, application events from top to bottom) which always leads to deadlocks. So that's just the way it is.

Categories

Resources