Migration to Eclipse 3.6

This page aims to show some new features (among others) developers of the Rodin Platform might be interested in, and review the list of items that one should take into account during the migration of their plugins for compliance with Eclipse 3.6.

New Features

This non exhaustive list is an extract of eclipse developer guides provided at this address : http://help.eclipse.org/helios/index.jsp

From the Platform Plug-in Developer Guide

Reusable intro news reader

The EclipseRSSViewer class allows multiple RSS news readers to be easily added to an intro page.

Horizontal mouse wheel

New event constants have been added for horizontal mouse wheels.

See SWT.MouseHorizontalWheel and SWT.MouseVerticalWheel.

Variable tab stops in StyledText

New API in StyledText allows the application to specify a non-uniform sequence of tab stops.

StyledText: per line variable tab stops

Tab stop support in StyledText has been improved to allow each line to have its own sequence of tab stops.

XULRunner 1.9.2 support

The Browser widget now has full support for the recent release of XULRunner 1.9.2.

From Plugin Development Environment Guide

Console log

By popular demand, -consoleLog is added to new launch configuration program arguments by default.

Support software installation while running and debugging

Launched Eclipse Applications can now support software installation operations.

When the new option is checked (on the Configuration tab of Eclipse Applications), a p2 profile is generated when running or debugging.

The profile initially contains all bundles in the target and can be modified by software installation operations.

The profile is regenerated on each subsequent run or debug session, but is maintained across restart operations.

Export target content

It's now possible to export the contents of your current target platform into a destination directory via the export active target definition wizard.

In the list of export wizards (File -> Export...), you'll find the wizard available under Plug-in Development -> Target definition.

Note: This will copy all features and plug-ins that are part of your currently set target platform to the destination directory.

Migrating from 3.5 to 3.6

This part gives an exhaustive list of incompatibilities while migrating from Eclipse 3.5 to Eclipse 3.6. Direct link : http://help.eclipse.org/helios/index.jsp

From the JDT Developer Guide : Incompatibilities between Eclipse 3.5 and 3.6

SDK ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1)

What is affected: Clients that require the org.junit and don't include 4.x in their version bounds

Description: The SDK now ships 2 org.junit plug-ins (versions 3.8.2 and 4.8.1). Clients that want to run JUnit Plug-in Tests with a Java 5 or later VM and that require org.junit with a version bound that does not include 4.x need to update their version bound to include 4.x (e.g. change their Require-Bundle: header to org.junit;bundle-version="3.8.2"). If they don't update their bounds, both versions of org.junit are resolved at run time, which leads to errors when test classes are loaded.

For complete details on the steps required to transition to using JUnit4 or to continue using JUnit3, please see: http://wiki.eclipse.org/Eclipse/Testing/JUnit4_Changes. Action required: Clients that require org.junit should make sure they include 4.x in their required version bounds.

Source incompatibility for subclasses of AbstractTemplatesPage

What is affected: Subclasses of org.eclipse.ui.texteditor.templates.AbstractTemplatesPage.

Description: In order to provide new API we had to make two methods public. While this does not break binary compatibility it breaks source compatibility.

Action required: Change the visibility of getSelectedTemplates() and getTemplateStore() to public.

@SuppressWarnings("unchecked") does not ignore raw types warnings anymore

What is affected: Usage of @SuppressWarnings("unchecked").

Description: Up to Eclipse 3.5, @SuppressWarnings("unchecked") was used to suppress the unchecked and raw types warnings. This was not consistent with other compilers (e.g. javac). A new warning token "rawtypes" has been added to cover the case of raw type warnings exclusively. So in order to get rid of all warnings, in Eclipse 3.6, it might be required to add "rawtypes" in the warning token list.

If it is not possible to update the code, a system property (-DsuppressRawWhenUnchecked=true) can be added to the -vmargs list on startup. This preserves the old behavior. The projects need to be manually cleaned and rebuilt after toggling the property.

Action required: When new warnings that were previously ignored are now reported, add "rawtypes" to the list of warning tokens.

Before:

@SuppressWarnings("unchecked")
   void bar(List list) {
       List<String> ls2 = list;
   }
@SuppressWarnings("unchecked")
private List l;

After:

@SuppressWarnings({"unchecked", "rawtypes"})
   void bar(List list) {
       List<String> ls2 = list;
   }
@SuppressWarnings("rawtypes")
private List l;

Classpath containers have the choice to resolve the referenced libraries themselves

What is affected: Classpath containers that depended on JDT to resolve referenced libraries via JAR's MANIFEST.MF.

Description: In 3.5, classpath containers did not have full control over what JARs ended up on the classpath, since references in the Class-Path section of a JAR's MANIFEST.MF were automatically added. In 3.6, referenced JARs are not automatically added any more. However, a classpath container implementor can use JavaCore#getReferencedClasspathEntries() to resolve the referenced JARs and return them in the implementation of IClasspathContainer#getClasspathEntries().

Please refer to the documentation of these APIs:

   IClasspathContainer
   JavaCore#getReferencedClasspathEntries()

Action required: If the classpath container implementation cannot be changed to accommodate this, the 3.5 behavior can be retained by adding a system property (-DresolveReferencedLibrariesForContainers=true) to the -vmargs list on start-up.

From the Platform Developper Guide : Incompatibilities between Eclipse 3.5 and 3.6

DialogSettings.save(Writer writer) can throw an IOException

What is affected: Clients that call DialogSettings.save(Writer writer) in code that is compiled against release 3.5

Description: In release 3.4 and earlier, DialogSettings.save(Writer writer) was specified to throw an IOException. In release 3.5, the method signature was changed to not throw the exception. In release 3.6, the method is specified to throw the exception (restoring it to the release 3.4 and earlier specification). Clients that do not catch the IOException when calling DialogSettings.save(Writer writer) should update the code to catch the exception. Note that this source incompatibility only applies to clients who directly use DialogSettings, the default implementation class. The interface type, IDialogSettings, has remained consistent in throwing the IOException in the method signature, so clients using the interface type are not affected.

The TextCellEditor no longer sets a default width of 50

What is affected: Clients relying on the default value for the minimum width of a TextCellEditor.

Description: The javadoc for TextCellEditor#getLayoutData() states explicitly that there is no minimum width set but it was inheriting a default width of 50. Clients who were relying on the previous value of 50 should override the minimumWidth field of the cell's LayoutData explicitly.

The method FileSystem.fetchFileTree now throws CoreException

What is affected: Subclasses of org.eclipse.core.filesystem.provider.FileSystem that invoked super in their implementation of fetchFileTree(IFileStore, IProgressMonitor)

Description: This method previously did not declare a throws clause, even though the base interface IFileSystem method did. This prevented clients from ever throwing CoreException in their implementations of this method, so the method signature was changed to be consistent with the base interface. This is a binary compatible change, but results in a source incompatibility for clients originally implemented against Eclipse 3.5 or earlier.

The bundle org.eclipse.equinox.p2.exemplarysetup has been removed

What is affected: Applications or features including p2 or manually starting p2.

Description: The bundle org.eclipse.equinox.p2.exemplarysetup has been removed from the Eclipse platform in the 3.6 release. This bundle never contained any API, either real or provisional, and just contained some classes used to initialize p2 that are no longer needed. There are some client applications that may be affected:

If you have a custom product or feature that incorporates p2 bundles directly rather than through the org.eclipse.equinox.p2.user.ui feature provided by the platform, you will need to remove this extra bundle from your .product file or feature.xml.
Some advanced client applications were manually starting this bundle in order to ensure p2 was started. Manual initialization of p2 is no longer needed and any such code can be removed.

Object Contributions will not execute from a key binding

What is affected: Key bindings assigned to a command backed by an object contribution action.

Description: A fundamental flaw in the legacy action/command bridge was fixed in the 3.6 release. While command definitionIds have been allowed on objectContributions so they can display key bindings while the context menu is up, objectContributions do not support execution using key bindings and objectContributions cannot be handlers for commands. In 3.4 a leak was introduced that allowed some IResource based objectContributions to execute from a key binding. With this leak now fixed, plug-ins that wish to provide default behaviour for a key binding for their command must provide a handler. This does not affect ActionSets, which will continue to work with key bindings when active within a perspective. An example of writing a core expression that's similar to an objectContribution can be found at IFile objectContribution Example.

Spinner now allows setting equal minimum and maximum values

What is affected: Clients dependent on the setting of a Spinner control's valid range to a single value to fail.

Description: Prior to Eclipse 3.6 it was not possible to set a Spinner's range of valid integer values to a single value. This was done in order to be consistent with other range-based controls in SWT. However the case of specifying a single integer value as the valid range for a Spinner is valid, so this can now be done. Clients that were dependent on this case failing now need to check for this condition before setting a Spinner's maximum to a value that would match its minimum value (or vice versa), and not set the value in such cases.

Browser on OS X now returns "webkit" as its type

What is affected: Clients using the result of Browser.getBrowserType() on OS X.

Description: In Eclipse 3.5.x the Browser returned "safari" as its type on OS X. However this return value was not accurate since it is the WebKit framework that is embedded by the Browser control on OS X, not the Safari application, so it has been changed accordingly. Clients that were using this return value to detect the use of a WebKit-based native browser on OS X should now detect a return value of "webkit" from Browser.getBrowserType() and check SWT.getPlatform() for a return value of either "carbon" or "cocoa".