swing - Java Event-Dispatching Thread explanation

itemprop="text">

I've recently started learning and
exploring the basics of GUI programming in
Java.

Having been programming for a while I have
only done backend work or work and as a result the closest I've gotten to user
interfaces is the command console (embarrassing I
know).

I'm using Swing and as far as
I can gather that means by extension I am also using
AWT.

My question is based on this piece of
code:

java.awt.EventQueue.invokeLater(new
            Runnable() {
 public void run() {
 new
            frame.setVisible(true);
 }
}
            );

I have
been researching this for a while as I wanted to fully understand this strange piece of
code and have come across the term 'Event-Dispatching Thread' multiple times. Correct me
if I'm wrong but as I understand it; it has to do with using multiple threads and how
Java Swing interprets those threads. I gather as well that the above code is used to
make sure all the threads are 'safe' before it creates the window, hence the
invokeLater?

I have read
that:

"You can
only call methods that operate on the frame from the Event-Dispatching
Thread"

and
that only under certain circumstances can you call methods that operate on the frame
from the main method.

Can
somebody please clarify to me what exactly the Event-Dispatching Thread
is?

How it relates
to multiple threads of execution and how those threads are not safe to be called from
the main method? Also why do we need this
invokeLater?

Can we
not just create the window as any other
object?

I've hit a bit of a road
block in my research as I'm not grasping these relations and
ideas.

A side note is that I like to
base my knowledge on in-depth understanding as I believe this leads to the best overall
outcome and as a result the best programs. If I understand in-depth how something works
then you can use the tips and tweaks effectively rather than just parroting them back in
to code, so please don't be afraid to give me some extra in-depth explanations and
broaden my knowledge.

Thank
you.

Answer

The href="https://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html"
rel="noreferrer">event dispatch thread is a special thread that is managed
by AWT. Basically, it is a thread that runs in an infinite loop, processing
events.

The href="https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/java/awt/EventQueue.html#invokeLater(java.lang.Runnable)"
rel="noreferrer">java.awt.EventQueue.invokeLater
and href="https://docs.oracle.com/en/java/javase/11/docs/api/java.desktop/javax/swing/SwingUtilities.html#invokeLater(java.lang.Runnable)"
rel="noreferrer">javax.swing.SwingUtilities.invokeLater
methods are a way to provide code that will run on the event queue. Writing a UI
framework that is safe in a multithreading environment is very difficult so the AWT
authors decided that they would only allow operations on GUI objects to occur on a
single special thread. All event handlers will execute on this thread and all code that
modifies the GUI should also operate on this
thread.

Now AWT does not usually check that you
are not issuing GUI commands from another thread (The WPF framework for C# does do
this), meaning it's possible to write a lot of code and be pretty much agnostic to this
and not run into any problems. But this can lead to undefined behavior, so the best
thing to do, is to always ensure that GUI code runs on the event dispatch thread.
invokeLater provides a mechanism to do
this.

A classic example is that you
need to run a long running operation like downloading a file. So you launch a thread to
perform this action then, when it is completed, you use
invokeLater to update the UI. If you didn't use
invokeLater and instead you just updated the UI directly, you
might have a race condition and undefined behavior could
occur.

href="http://en.wikipedia.org/wiki/Event_dispatching_thread"
rel="noreferrer">Wikipedia has more
information

Also, if you are curious
why the AWT authors don't just make the toolkit multithreaded, href="https://community.oracle.com/blogs/kgh/2004/10/19/multithreaded-toolkits-failed-dream"
rel="noreferrer">here is a good article.