Eclipse changed in incompatible ways between 3.5 and 3.6 in ways that affect plug-ins. The following entries describe the areas that changed and provide instructions for migrating 3.5 plug-ins to 3.6. Note that you only need to look here if you are experiencing problems compiling or running your 3.5 plug-in on 3.6.
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.
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.
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.
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:
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.What is affected: Clients that expect setting a single value range on a Spinner control to be disallowed.
Description: Prior to Eclipse 3.6, attempts to set a Spinner's value range to a single value were not allowed. 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 a Spinner's value range is valid, so this is now allowed. Clients that were dependent on this case being disallowed must now 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.
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".