Eclipse 4 asynchronous processing and the event bus by Lars Vogel

Synchronizing yourself with the user interface thread in Eclipse 4 can be done with the getting an instance of UISynchronize injected and use this class to execute an Runnable in the user interface thread.

@Inject UISynchronize sync;

But Eclipse 4 provides an even simpler way.

Eclipse 4 provides the IEventBrooker which allows to send events. Your threads can use the IEventBrooker to send event data. Every listener will be automatically called and if you use the UIEventTopic annotation, this method is be automatically called in the user interface thread.

The following shows an example:

// Get the IEventBrooker via DI
IEventBroker brooker;

// Somewhere in you code you do something 
// performance intensive

button.addSelectionListener(new SelectionAdapter() {
      public void widgetSelected(SelectionEvent e) {
        Runnable runnable = new Runnable() {
          public void run() {
            for (int i = 0; i < 10; i++) {
              try {
              } catch (InterruptedException e) {
                // TODO Auto-generated catch block
              // Send out an event to update
              // the UI
              brooker.send("update";, i);
        new Thread(runnable).start();

// More code
// ....

// Get notified and sync automatically
// with the UI thread

@Inject @Optional
public void  getEvent(@UIEventTopic(&quot;update&quot;) int i) {
  // text1 is a SWT Text field

Have a look at Asynchronous processing in Eclipse 4 and the Eclipse 4 Eventbus for more details.

About Lars Vogel

Lars Vogel is the founder and CEO of the vogella GmbH and works as Eclipse and Android consultant, trainer and book author. He is a regular speaker at international conferences, He is the primary author of With more than one million visitors per month this website is one of the central sources for Java, Eclipse and Android programming information.
This entry was posted in Eclipse, Lars Vogel. Bookmark the permalink.

7 Responses to Eclipse 4 asynchronous processing and the event bus by Lars Vogel

  1. paul says:

    Thank you it will be very usefull

  2. Marco Descher says:

    Hy Lars,

    in bigger applications, do you prefer a generic event like the update event you described to request an UI refresh, or would you use more specific events denoting what happened and execute the UI refresh as a respective reaction to this event (e.g. Event.PERSON_ADDED leads to reaction on ListViewer update)?


  3. admin says:

    @Marco: if you send out frequently event I suggest to use more specific events.

  4. Anonymous says:

    bug in line 22

  5. Lars Vogel says:

    @Anonymous Thanks. Fixed.

  6. Tom Schindl says:

    @Marco: Always send out specific events but build up logic paths like “/model/modified/Person/added”, “/mode/modified/Person/changed/name”, … this way the subscriber can decide what he is interested in and e.g. subscribe to “/model/modified/*” or “/model/modified/Person/*”, …

  7. Marco Descher says:

    Thanks a lot guys! Thomas, that cleared it a lot 🙂

Comments are closed.