Why should I use a separate thread to show a GUI in JAVA

Question

This simple issue confuses me. You can display a JAVA GUI application by setting the frames' setVisible property true. But in almost all the examples I found on internet they use a separate thread to do the same thing.

They do something like this,

SwingUtilities.invokeLater(new Runnable() {

    @Override
    public void run() {
        new Frame().setvisible(true);  //just take the idea of this line
    }
});

I found no difference between the two methods. But there must be some special reason, that's why everyone is doing this.

Can someone explain it..thanks!

Rubie

Answer 1

The main reason for launching your application in this way is that Swing components are not thread-safe so you need to guarantee which thread your GUI will start from: the one called the Event Dispatching Thread (EDT). Without doing this, you can't be sure what thread it will start in, but as noted by several kind commentators, the main thread is guaranteed not to be the EDT.

You should only create, access, or modify UI components from within the EDT. Doing otherwise will result in unexpected behavior (if you're lucky) and/or dirty repaints.

Some resources I suggest you become familiar with:

• The Event Dispatch Thread
• Painting in AWT and Swing

You could also have a read of Why does my boilerplate Java desktop app JFrame use EventQueue.invokeLater in the main method?

UPDATE

This is the blog I've been trying to find :P

This basically explains why it's important to sync your main with the EDT before getting started, it also describes some of the details about why.

It also describes why many developers make this fundamental mistake when starting their applications (basically, we were told we could, but we never were really allowed to...bad us)

Carrycarryall

That's not the reason for having to use the EDT. – Hurds

how do you know that by this way? you haven't kept any reference?? BTW, why should I know that anyway (i mean for a simple app)... – Rubie

@Hurds what do you mean? – Carrycarryall

@Rubie kept a reference to what? The main reason for wrapping the call is to ensure that your UI code is executed in the EDT. – Carrycarryall

@Carrycarryall I haven't used Swing in a while, but iirc it generates its own thread in the standard implementation. That is, you're guaranteed that the thread where main lives is not the EDT. – Jacy

Now that makes sense. Thanks for the links.. (you should have posted this first hand) – Rubie

@Rubie Sorry, needed time to find the silly things - my bad :P – Carrycarryall

@Rubie IMHO As a OP you need to more patient. – Corporate

@AmitD No, IMO, I need to gather my resources BEFORE I post and not post half a*s answers :P - Thanks for the support, but this time, it was my fault (bad me) – Carrycarryall

@AmitD what did you mean?? man, I'm not responsible for any of those down-votes!!! I said so because otherwise he won't get them... – Rubie

@Rubie you should have read up on the basics before asking ;-) Two of the three links are referenced in the swing tag wiki, they is not much reason to repeat them over and over again .. – Crossstitch

Answer 2

Because every modification you do on the GUI should be done on the event dispatching thread. This is how AWT and SWING are meant to work.

This because the redraw is executed on a single thread, by using invokeLater you let that thread manage it without having potential issued by the lack of thread safety of Swing. Using that syntax you delegate that instructions to be executed on the appopriate thread, which is the one that manages the GUI elements.

Sillsby

Answer 3

Swing is not thread-safe and all components needs to be initialized in the EDT. This will prevent issues such as deadlocking.

Hurds

Answer 4

The Swing classes are not thread-safe; they get their thread correctness solely from the fact that all actions on them are executed on the same thread (the Event Dispatch Thread, or EDT). So any time you interact with a Swing object, it must be on the EDT -- and SwingUtilities.invokeLater is a good way to do that.

Without that call, if you just called setVisible(true) from any ol' thread, you wouldn't have any thread safety and the Frame might not even see the actions of that method. Worse yet, the Frame could see only some of the actions, breaking internal assumptions and invariants and causing odd behavior, crashes or deadlocks.

Jacy

Answer 5

Pretty much any operation that invokes Swing methods must be run on the Swing Event Dispatch thread. invokeLater() is the way to ensure that this invariant holds. Read more about this here.

Also note that the same is true about most other GUI toolkits, such as forms in .NET, MFC and others.

Heroics

Answer 6

Java gui framework is designed as a single thread to enforce thread safety: this technique is called thread confinement. Any gui operation e.g. components creation, model creation, event sent, etc must therefore execute in the Event Dispatch Thread (EDT). The way you describe is one way to queue the operation in the EDT.

Tinaret