Incompatibilities Between Eclipse 4.6 and 4.7

Eclipse changed in incompatible ways between 4.6 and 4.7 in ways that affect plug-ins. The following entries describe the areas that changed and provide instructions for migrating 4.6 plug-ins to 4.7. Note that you only need to look here if you are experiencing problems running your 4.6 plug-in on 4.7.

See also the list of deprecated API removals for this release.

1. New calling convention for progress monitors

1. New Calling Convention for Progress Monitors

What is affected:

All methods which obtain their own top-level IProgressMonitor.

Description:

In order to reduce boilerplate code, Eclipse 4.7 has introduced a new calling convention for methods which receive an org.eclipse.core.runtime.IProgressMonitor as a parameter. In Eclipse 4.7 it is the caller's responsibility to invoke done() on IProgressMonitor rather than the receiver's. Callers can choose to use SubMonitor, which doesn't require the use of done(). This means that — in practice — most invocations of done() will be deleted along with their surrounding try/catch blocks.

This is not a breaking change for methods which receive a progress monitor as an argument, since they can tolerate callers whether or not the caller invokes done(). However, it may be a breaking change for methods that obtain their own top-level progress monitors.

Methods which obtain their own top-level progress monitors rather than receiving one as a parameter are now responsible for invoking done() on those monitors. Technically, they were always responsible for doing this, but some of them didn't do so because any method they passed it to would have invoked done() on their behalf. Now this will matter and the methods will need to be changed. For example:

// Before:
public void doSaveAs() {
  IProgressMonitor monitor= getProgressMonitor();
  performSaveAs(monitor);
}

// After:
public void doSaveAs() {
  IProgressMonitor monitor= getProgressMonitor();
    try {
      performSaveAs(monitor);
    } finally {
      monitor.done();
    }
}

Fortunately there are few of these methods and they are easy to find.

Action required:

• Open the Call Hierarchy on StatusLineManager#getProgressMonitor().
• Ensure that all callers of these methods contain a finally block that invokes done (as in the doSaveAs() example, above).
• Open the Type Hierarchy of IProgressMonitor. Look for progress monitors which do something in their done() method besides reporting work, setting a task name, or calling done on another monitor. SubMonitor can be ignored. Monitors which set a control's visibility or deallocate a resource in their done() method must not be ignored.
• Use the Call Hierarchy view to locate every place that instantiates or accesses an instance of one of those classes. Ensure that those access points contain a try/finally block that invokes done().

More Information:

See this article for more examples of how to use progress monitors with the new calling convention. Background and discussion about this change can be found here.

2. javax.xml Removed From org.eclipse.e4.rcp Feature

What is affected: Clients that refer to the javax.xml bundle and use the org.eclipse.e4.rcp feature for that dependency.

Description: The javax.xml plug-in has been removed from the org.eclipse.e4.rcp feature. The javax.xml package is provided by JavaSE 1.7 and the Eclipse Platform requires Java 1.8.