Typically this is performed by, in the code running in the background thread, creating a Runnable , object, and supplying it to the SwingUtilities or EventQueue class to be invoked as soon as possible:

// Note - EventQueue could also be replaced with 'SwingUtilities' in the example below.
// Code in background thread.
doSomeExpensiveProcessing();
EventQueue.invokeLater(new Runnable() {
 public void run() {
  someLabel.setText("Complete!");
 }
});

In addition, when you begin modularizing and breaking apart your code, a certain block of code may not be in a position to truly be aware if it is running on the event dispatch thread. If it is, it may be beneficial to execute the visual update immediately, rather than queueing it for later.

// Note - EventQueue could also be replaced with 'SwingUtilities' in the example below.
// Code in background thread.
doSomeExpensiveProcessing();
Runnable r = new Runnable() {
 public void run() {
  someLabel.setText("Complete!");
 }
};
if(EventQueue.isEventDispatchThread()) {
 r.run();
}
else {
 EventQueue.invokeLater(r);
}

Finally, if you need to ensure (in this background thread) that the UI was updated appropriately, you can ask Swing to let you wait until it is done invoking the runnable:

// Note - EventQueue could also be replaced with 'SwingUtilities' in the example below.
// Code in background thread.
doSomeExpensiveProcessing();
Runnable r = new Runnable() {
 public void run() {
  someLabel.setText("Complete!");
 }
};
if(EventQueue.isEventDispatchThread()) {
 r.run();
}
else {
 try {
  EventQueue.invokeAndWait(r);
 }
 catch(InterruptedException e) { /* handle */ }
 catch(InvocationTargetException e) { /* handle */ }
}

I'm not here to talk about Swing however. I'm here to talk about SWT. So why all the subterfuge? Well, the truth is, SWT is *also* essentially a single-threaded UI toolkit (it really does differ, but for the sake of a single display discussion, you can believe me and be happy). It suffers from the same effective problems inherent in Swing as seen above. In fact, most anyone who has done multi-threaded SWT programming, and was somewhat careless or forgetful at sometime, has probably seen this stack trace:

org.eclipse.swt.SWTException: Invalid thread access
at org.eclipse.swt.SWT.error(SWT.java:2691)
at org.eclipse.swt.SWT.error(SWT.java:2616)
at org.eclipse.swt.SWT.error(SWT.java:2587)
...

SWT does make a point to fail-fast when it comes to threading problems; so at least the typical problems don't go unnoticed until production. The question is, however, what do you do if you need to update a label/button/super-duper-control in SWT from a background thread? Well, it's surprisingly similar to Swing:

// Code in background thread.
doSomeExpensiveProcessing();
Display.getDefault().asyncExec(new Runnable() {
 public void run() {
  someSwtLabel.setText("Complete!");
 }
});

Note that Display objects are keyed by the thread they belong to - in a single display environment (most applications), you don't have to explicitly worry about dispatching your runnable to the *right* display object (the call to getDefault() ) will simply be correct. That being said, it is good to be aware of this detail.

You may notice, however, that there is no is...Thread method on the Display class to match our EventQueue.isEventDispatchThread() method. Thankfully there are plenty of ways to check this - here are a few:

경축! 아무것도 안하여 에스천사게임즈가 새로운 모습으로 재오픈 하였습니다.
어린이용이며, 설치가 필요없는 브라우저 게임입니다.
https://s1004games.com

boolean isDisplayThread1 = Display.getCurrent() != null; // current will be null if current thread doesn't belong to a display object
boolean isDisplayThread2 = Display.findDisplay(Thread.currentThread()) != null; // effectively the same as the call above.
boolean isDisplayThread3 = Display.getDefault().getThread() != Thread.currentThread(); // match the current thread with the default display thread.

There are more than likely other ways to do this, but as you can see, it isn't particularly complicated - each of these solutions is based in the world of checking the current thread, and seeing if there is a display object registered for it.

// Code in background thread.
doSomeExpensiveProcessing();
Runnable r = new Runnable() {
 public void run() {
  someSwtLabel.setText("Complete!");
 }
};
 
if(Display.getCurrent() != null) {
	r.run();
}
else {
	Display.getDefault().asyncExec(r);
}

Finally, the display class also supports synchronous execution:

// Code in background thread.
doSomeExpensiveProcessing();
Runnable r = new Runnable() {
 public void run() {
  someSwtLabel.setText("Complete!");
 }
};
 
if(Display.getCurrent() != null) {
	r.run();
}
else {
	Display.getDefault().syncExec(r); // notice SYNC exec
}

Finally, some things to note:

• the code I show here is not best-of-breed code for your infrastructure, it is simple to demonstrate the features in SWT.
• Synchronized dispatch ( invokeAndWait and syncExec ) often provide more options for ensuring code executes in the correct order, but also has the negative side effect of opening a world of possibilities for deadlocks. Take care when using these methods across broad infrastructures of code.
• As opposed to checking the thread that you are currently on to determine if it is best to execute the runnable directly, you *do* have the option of always simply passing the runnable to the dispatch thread in question. This can have an effect on the order of operations, however - by executing it directly, you know it is executing right away - if you queue it up using invokeLater or asyncExect however, it may be third, fourth, fifth, or seventy-ninth in line, and you have no guarantee of ordering.

Until next time,

R.J. Lorimer