Skip to main content

Platform and Equinox API

Platform Changes

JobManager implementation changes

Possible deadlock in IJobChangeListener

Attention: The JobManager implementation was changed! The old JobMangager implementation notified IJobChangeListener about various IJobChangeEvent without strict order in various threads. For example scheduled() was called in a thread that did call schedule() on a job while done() was normally called within a worker thread. In case of a repeated schedule() both notifications could run in parallel. That was a race condition. The listener could not deterministically know if the job was still scheduled or already done. As a consequence a join() could have returned too early or the Progress View did not show jobs that did still run. And probably many other things went wrong totally unnoticed. Even multiple notifications could have happened in parallel in various worker threads, as there is no guarantee that the next execution is done in the same worker.

To fix this indeterministic behavior all events for the same Job instance will now be sent one after the other. It is still not defined in which thread job events will be sent, but the new implementation will not call any IJobChangeListener until all pending events for the same job instance are processed by all registered IJobChangeListener. The new implementation will also wait with any job state change until all calls to IJobChangeListener for that job returned.

The IJobChangeListener javadoc clearly specifies "whether the state change occurs before, during, or after listeners are notified is unspecified." - and the implementation changed within that broad specification. Unfortunately some IJobChangeListener around rely on the old implementation. They may now deadlock. For example the following snippet can now deadlock:

 job.schedule(); // may result in done();
 synchronized (lock){
  boolean schedule = ...; // lock needed for reasons
  if (schedule ) job.schedule(); // schedule() will notify scheduled()
  // - which may not return before previous Notifications return!

 public void done(IJobChangeEvent event) {
  // can not enter while other Thread holds lock:
  synchronized (lock) {// possible deadlock

Instead use:

 boolean schedule;
 synchronized (lock) {
  schedule=...; // lock needed for reasons
 if (schedule) job.schedule();

 public void done(IJobChangeEvent event) {
  synchronized (lock) {// OK

The same problem may occur on all IJobChangeListener methods and all methods that result in IJobChangeEvent being sent: Job.schedule(), cancel(), wakeUp(), sleep() and JobManager shutdown. Make sure all IJobChangeListener implementations do not block and return promptly.

Due to the extreme risk the new implementation tries to identify non-conforming IJobChangeListener and do a fall back: when an IJobChangeEvent is not handled within 3 seconds a timeout error is logged with stacktraces of the competing threads and the JobManager will no longer wait - until JVM is restarted. Further calls to IJobChangeListener may occur in non deterministic order and JobManager.join(family) can return too soon. It is however possible, that there may also be some deadlocks in clients code due to the changed JobManager implementation that may be undetected by JobManager.

Also note that it is undefined in which thread IJobChangeListener methods are called. Clients may have relied on the old implementation which called done() in the UI (SWT) thread for UIJob - but that is not the case anymore - it may happen in a background thread.

It is recommended to check existing IJobChangeListener implementations for possible regressions if updating to the new target platform.
Static factories added for UIJob To the classes org.eclipse.ui.progress.UIJob and org.eclipse.e4.ui.progress.UIJob static factory methods have been added, that create and return UIJob-instance. Their signature is similar to those in the Job class:
  • public static UIJob create(String name, IJobFunction function)
  • public static UIJob create(String name, ICoreRunnable runnable)
Please beware that, if you used UIJob.create() before, which was discouraged, because you used to call a static method from the super-class, the result is now different.

SWT Changes

StyledText copy to clipboard now also adds HTML format StyledText widget now adds HTML format when copying to the clipboard, in addition to plain text and RTF.
Many web-based applications don't support RTF, so it was not possible to copy and paste styled text (and preserve fonts, colors, and so on).
By adding HTML to the clipboard this is now possible.
Integration of the Display with the Executor Framework The Display class of SWT now implements java.util.concurrent.Executor of the Java Executor Framework. Such an Executor executes the given runnable in the user-interface thread of the Display:
  • If the calling thread is the user-interface thread of this display it is executed immediately and the method returns after the command has run, as with the method Display#syncExec(Runnable).
  • In all other cases the run() method of the runnable is asynchronously executed as with the method Display#asyncExec(Runnable) at the next reasonable opportunity. The caller of this method continues to run in parallel, and is not notified when the runnable has completed.

This can be used in cases where one want to execute some piece of code that should be guaranteed to run in the user-interface thread regardless of the current thread, or for example together with the java.util.concurrent.CompletableFuture to write non-blocking code more easier.

General Updates

Migration to SLF4J 1.7.36 from Maven-Central The Eclipse Platform migrated to the SLF4J artifacts from Maven-Central in version 1.7.36. With this migration the Bundle-SymbolicName changed from org.slf4j.api to slf4j.api.

Furthermore the way how a SLF4J-binding Plugin is wired to the slf4j-api Plugin has changed. Previously with the artifacts provided by Eclipse Orbit, each binding had a separate fragment whose host was the org.slf4j.api Plugin and that required the binding Plugin. The slf4j.api Plugin from Maven-Central instead imports the package org.slf4j.impl, which is exported by each binding Plugin. Consequently, unlike before, slf4j.api does not resolve if no binding is present. If you want to disable logging with slf4j, you can add the slf4j-nop binding to your application or product.

Additionally the slf4j.api Plugin as well as org.apache.commons.logging have been removed from all Features of the Eclipse Platform to enable Application/Product builders to freely choose the logging-framework and bridging strategy eventually used in their product. If nothing is chosen explicitly P2 assembles a minimal result depending on the available Plugins.

Previous Up

Back to the top