Description Alex Blewitt 2014-08-16 05:34:37 EDT

SwingUtilites has an isEventDispatchThread method which can be used to determine if the current thread is the one used by the UI. This makes it very easy to implement logic to tell whether resource-intensive operations are being performed on the UI thread, using something like:

public void someRandomlyLongMethod() {
  if(SwingUtilities.isEventDispatchThread()) {
    logWarn("Running resource intensive method on UI thread");
  }
  ...
}

In addition, a breakpoint can be put inside the guarded block which will instantly show where the problems are occurring and allow the stack trace to be investigated.

This can be implemented in SWT today as follows:

public void someRandomlyLongMethod() {
  if(Thread.currentThread() == Display.getThread()) {
    logWarn("...")
  }
  ..
}

but having it in an internal method on Display would allow it to be optimised further (for example, avoiding the need for synchronized checking or device disposal).

In fact, this already exists in the Display class:

boolean isValidThread () {
	return thread == Thread.currentThread ();
}

The widgets also take advantage of this pattern in things like checkWidget(), although they use direct package access to obtain the field reference.

There are lots of places where this comparison occurs in Eclipse at present:

Accessible::isValidThread
Browser::checkParent
Clipboard::checkWidget
UILockListener::isUI
DecoratorManager::fireListenersInUIThread
ProgressManager::getDefaultMonitor
CommandContributionItem::updateCommandProperties
BasicSplashHandler::updateUI

In fact all of these methods are only accessing Thread to compare it against the currentThread. So by moving it into a common Display method it may allow the JIT to optimise it further. It will also have a more semantic meaning to code that's using it.

Let me know if you want me to provide a patch, and if so, how to go about changing it (whether I have to update it in many places for different OSes etc.)