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:

 job.schedule();
 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.

• public static UIJob create(String name, IJobFunction function)
• public static UIJob create(String name, ICoreRunnable runnable)

• 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.

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.