If you open a dialog in Swing, for example a JFileChooser, it goes somewhat like this pseudocode:
swing event thread {
create dialog
add listener to dialog close event {
returnValue = somethingFromDialog
}
show dialog
(wait until it is closed)
return returnValue
}
My question is: how can this possibly work? As you can see the thread waits to return until the dialog is closed. This means the Swing event thread is blocked. Yet, one can interact with the dialog, which AFAIK requires this thread to run.
So how does that work?
The existing event dispatch thread is blocked, and so swing creates another thread that pumps the events. This is then the event dispatch thread for the duration of the dialog.
Swing creates a separate native thread for pumping native OS window messages. This is separate from the AWT event thread.
On Windows, you see these threads
"AWT-Windows" - the native UI thread
"AWT-EventQueue-0" - the current AWT event dispatch thread
EDIT: The downvote is correct. This is not true, at least not in all cases.
Modal dialogs often take care of pumping AWT events themselves. If you run the code
SwingUtilities.invokeAndWait(new Runnable()
{
public void run()
{
JOptionPane.showInputDialog("hello");
}
});
and then break, looking at the threads, you will see only one EventQueue thread. The show() method of JOptionPane pumps events itself.
Frameworks like Spin and Foxtrot take the same approach - they allow you to create a long running blocking method on the EDT, but keep the events flowing by pumping events themselves. It is possible for swing to have multiple dispatch threads (I'm sure this was the case with older versions of swing) but now that multicore is common, the concurrency issues, in particular ensuring changes on one thread are correctly published to other threads, mean that using multiple EDTs produces bugs in the current implementation. See
Multiple Swing event-dispatch threads
It's the AWT's thread, not Swing's.
Anyway, AWT runs the dispatch loop within the show. Input events to blocked windows are blocked. Repaint events, events to unblocked windows and general events are dispatched as usual.
You can see this either by adding the line:
Thread.dumpStack();
into the even handling for the modal dialog, or more easily from the command line with jstack or use ctrl-\/ctrl-break in the command window of the application.
The Foxtrot library abuses this to provide a more procedural (as opposed to event-driven) model. It's also used by WebStart/Java PlugIn to provide dialogs for JNLP services and others when called from the application EDT.
Related
My question is related to SwingUtilities.invokeLater. When should I use it? Do I have to use each time I need to update the GUI components? What does it exactly do? Is there an alternative to it since it doesn't sound intuitive and adds seemingly unnecessary code?
Do I have to use each time I need to update the GUI components?
No, not if you're already on the event dispatch thread (EDT) which is always the case when responding to user initiated events such as clicks and selections. (The actionPerformed methods etc, are always called by the EDT.)
If you're not on the EDT however and want to do GUI updates (if you want to update the GUI from some timer thread, or from some network thread etc), you'll have to schedule the update to be performed by the EDT. That's what this method is for.
Swing is basically thread unsafe. I.e., all interaction with that API needs to be performed on a single thread (the EDT). If you need to do GUI updates from another thread (timer thread, networking thread, ...) you need to use methods such as the one you mentioned (SwingUtilities.invokeLater, SwingUtilities.invokeAndWait, ...).
Swing is single threaded and all changes to the GUI must be done on EDT
Basic usage for invokeLater()
Main methods should be always wrapped in invokeLater()
Delayed (but asynchronously) action/event to the end of EventQueue,
If EDT doesn't exists then you have to create a new EDT by using invokeLater(). You can test it with if (SwingUtilities.isEventDispatchThread()) {...
There exists invokeAndWait(), but till today I (just my view) can't find a reason for using invokeAndWait() instead of invokeLater(), except hard changes into GUI (JTree & JTable), but just with Substance L&F (excellent for testing consistency of events on the EDT)
Basic stuff: Concurrency in Swing
All output from background tasks must be wrapped in invokeLater()
Every Swing application has at least 2 threads:
The main thread that executes the application
The EDT (Event Dispatching Thread) is a thread that updates the UI (so the UI will not freeze).
If you want to update the UI you should execute code within the EDT.
Methods like SwingUtilities.invokeLater, SwingUtilities.invokeAndWait, EventQueue.invokeLater, EventQueue.invokeAndWait allow you to execute code by the EDT.
My question this time is related to SwingUtilities.invokeLater: When should I use it?
What is key to understand is that Java has a separate thread (EDT) handling Swing related events.
You should use invokeLater() to display the main JFrame of a desktop application (for example), instead of trying to do it in the current thread. It will also create the context for graceful closing of the application later.
That's about it for most applications.
Do I have to use each time I need to update the GUI components? What does it exactly do?
No. If you modify a GUI component, it will trigger an event which is registered for later dispatching by Swing. If there is a listener for this event, the EDT thread will call it somewhere down the road. You don't need to use invokeLater(), just set your listeners on components properly.
Keep in mind that this thread is the same thread drawing frames etc... on your screen. Hence, listeners should not perform complex/long/CPU intensive tasks, otherwise your screen will freeze.
Is there an alternative to it since it doesn't sound intuitive and adds seemingly unnecessary code?
You don't need to write more code than displaying your application with invokeLater() + listeners you are interested in on component. The rest is handled by Swing.
Most user-initiated events (clicks, keyboard) will already be on the EDT so you won't have to use SwingUtilities for that. That covers a lot of cases, except for your main() thread and worker threads that update the EDT.
I was comparing the differences between Swing's SwingWorker and Android's AsyncTask classes. While Android has a Main Thread/UI Thread and then spawns a background thread (using AsyncTask), SwingWorker has three threads that are involved -
Current thread
Worker thread
Event Dispatch Thread.
And then I also came across the statement (in docs) -
Often, the Current thread is the Event Dispatch Thread.
Now, what does this mean?
Does it mean that Swing also has only 1 thread - the Main Thread and
even the events are received on the same thread OR
Is it different for different JVM implementations?
This is only valid for Swing, which shares some similarities with Android UI programming but is indeed not the same.
A little bit of context
The EDT (Event Dispatch Thread) is Swing's thread dedicated to handling UI events (mouse and keyboard input, events on controls, rendering of the UI, etc...).
This is an Event Loop model, similar to what is done in Android.
The fact that event listeners in Swing are executed on the EDT is the root cause for freezing UIs in Swing applications: developers misunderstanding the threading model often put long-running code in the listeners, which blocks the EDT and thus the GUI.
SwingWorker was introduced to better guide developers in separating UI updates from long-running background code. It spawns a dedicated background thread for the I/O processing (or long-running task) in doInBackground and executes UI updates in done and process methods. While these 3 methods guarantee in which thread they'll be executed, all other methods are executed in the current thread.
What is meant by the sentence you quoted
The whole reason for SwingWorker to exist is to properly initiate a long-running process from the GUI, without blocking the GUI.
Often, it will be in reaction to a user's input (e.g. clicking a Button). Since reactions to the user's input (implemented as Listeners) are always executed in the EDT by the Swing framework, unless you happen to call execute or get from another thread explicitly, it will get executed on the EDT.
By the way, execute is "fire-and-forget" and is the typical use-case (call it from a listener). get on the other hand blocks, and is not suited to be called from a listener (it would defeat SwingWorker's purpose, call it on your own threads if needed)!
I am new to java and there was an interview question for a Graduate role which i didn't understand, so can you tell me which thread and its purpose please.
Swing UI toolkit is single threaded (in the sense that it is unsafe to call any of the swing libraries from any other thread). All the UI events, both rendering and dispatching them is done by the EDT thread.
So on clicking at a button on desktop. The OS gives the notification to EDT which receives the event and then triggers the callback function which was registered for the button click. Moreover from the code, when you do some action (for ex: repaint screen or draw Image). The EDT delivers the change to the OS and it is rendered on the screen. Hence a 2-way interaction.
Because as mentioned Swing UI toolkit is single-threaded. Hence it is advisable to call any of the Swing libraries from EDT only usign System.invokeLater. More info here.
You're looking for the Event Dispatch Thread.
Knowing about it is pretty.. important. It is vital to understand what thread your code will end up running on - long-running tasks should not be run on the EDT. Instead, dispatch those tasks on their own thread, then run a callback at the end of the operation to update the GUI using SwingUtilities.
I'm coding a Java 7 Swing application which calls a non-GUI class to do something in a loop. Unfortunately, I can't interact with the GUI while the loop is running. Is it possible to force the processing of GUI events while in that loop?
I'm searching for something that tells the JVM to process other GUI events like button clicks before continuing with the loop.
Is there something in Java 7 Swing that does what I want or do I really have to mess with multi-threading by myself (I'm not that far yet...)?
No, unlike Qt framework (which is C++ based), Java does not support manually processing and/or dispatching UI events (at least, at time of writting, 2022).
In other words, don't block the EDT (Event Dispatch Thread) - the GUI will 'freeze' when that happens (and there is not way out yet).
Instead of calling Thread.sleep(n) implement:
a Swing Timer for repeating tasks
or a SwingWorker for long running tasks.
See Concurrency in Swing for more details.
Use a SwingWorker. Basically, all UI event handling is always done on a single specific thread, called the Event Dispatch Thread, and doing anything else in that thread prevents UI events (mouse clicks, keyboard input etc) from being processed and thus makes the UI "hang".
The SwingWorker class was added to the JRE specifically for doing time-consuming tasks "in the background" (not in the UI thread) and allows you to easily do your heavy lifting someplace else, optionally update the UI at intervals (think progress bar), and, again optionally, update the UI once you're done. You do this simply by overriding specific methods (doInBackground() and done()) and you never need to directly deal with threading.
The SwingWorker Javadoc page has everything you need to start using it, including example code.
My question is related to SwingUtilities.invokeLater. When should I use it? Do I have to use each time I need to update the GUI components? What does it exactly do? Is there an alternative to it since it doesn't sound intuitive and adds seemingly unnecessary code?
Do I have to use each time I need to update the GUI components?
No, not if you're already on the event dispatch thread (EDT) which is always the case when responding to user initiated events such as clicks and selections. (The actionPerformed methods etc, are always called by the EDT.)
If you're not on the EDT however and want to do GUI updates (if you want to update the GUI from some timer thread, or from some network thread etc), you'll have to schedule the update to be performed by the EDT. That's what this method is for.
Swing is basically thread unsafe. I.e., all interaction with that API needs to be performed on a single thread (the EDT). If you need to do GUI updates from another thread (timer thread, networking thread, ...) you need to use methods such as the one you mentioned (SwingUtilities.invokeLater, SwingUtilities.invokeAndWait, ...).
Swing is single threaded and all changes to the GUI must be done on EDT
Basic usage for invokeLater()
Main methods should be always wrapped in invokeLater()
Delayed (but asynchronously) action/event to the end of EventQueue,
If EDT doesn't exists then you have to create a new EDT by using invokeLater(). You can test it with if (SwingUtilities.isEventDispatchThread()) {...
There exists invokeAndWait(), but till today I (just my view) can't find a reason for using invokeAndWait() instead of invokeLater(), except hard changes into GUI (JTree & JTable), but just with Substance L&F (excellent for testing consistency of events on the EDT)
Basic stuff: Concurrency in Swing
All output from background tasks must be wrapped in invokeLater()
Every Swing application has at least 2 threads:
The main thread that executes the application
The EDT (Event Dispatching Thread) is a thread that updates the UI (so the UI will not freeze).
If you want to update the UI you should execute code within the EDT.
Methods like SwingUtilities.invokeLater, SwingUtilities.invokeAndWait, EventQueue.invokeLater, EventQueue.invokeAndWait allow you to execute code by the EDT.
My question this time is related to SwingUtilities.invokeLater: When should I use it?
What is key to understand is that Java has a separate thread (EDT) handling Swing related events.
You should use invokeLater() to display the main JFrame of a desktop application (for example), instead of trying to do it in the current thread. It will also create the context for graceful closing of the application later.
That's about it for most applications.
Do I have to use each time I need to update the GUI components? What does it exactly do?
No. If you modify a GUI component, it will trigger an event which is registered for later dispatching by Swing. If there is a listener for this event, the EDT thread will call it somewhere down the road. You don't need to use invokeLater(), just set your listeners on components properly.
Keep in mind that this thread is the same thread drawing frames etc... on your screen. Hence, listeners should not perform complex/long/CPU intensive tasks, otherwise your screen will freeze.
Is there an alternative to it since it doesn't sound intuitive and adds seemingly unnecessary code?
You don't need to write more code than displaying your application with invokeLater() + listeners you are interested in on component. The rest is handled by Swing.
Most user-initiated events (clicks, keyboard) will already be on the EDT so you won't have to use SwingUtilities for that. That covers a lot of cases, except for your main() thread and worker threads that update the EDT.