# Incompatibilities between Eclipse 3.3 and 3.4

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

1. FileEditorInput#getPath throws IllegalArgumentException for non local files
2. Changed scheduling rules for IProject#setDescription
3. `IWorkbenchActionConstants.MB_ADDITIONS` no longer supported in Marker views
4. org.eclipse.tomcat no longer included
5. Corrected API for tabbed properties view to not require the usage of internal types

## 1. FileEditorInput#getPath throws IllegalArgumentException for non local files

What is affected: Clients that call getPath() on FileEditorInput.

Description:In release 3.3 and earlier, `FileEditorInput#getPath` returned `null` when called on an input whose file was not in the local file system. This violated the contract of `IPathEditorInput#getPath` which did not allow a null result. The method now throws `IllegalArgumentException` in this case. The convenience method `FileEditorInput#isLocalFile` has been added so that callers who are unsure of the state of a supplied `IFile` can check before calling `#getPath`.

Action required: Clients that call `FileEditorInput#getPath` should check if they are calling it on an input that is not in the local file system, and react accordingly.

## 2. Changed scheduling rules for IProject#setDescription

What is affected: Clients that call `IProject#setDescription`.

Description: In the 3.3 release, all calls to `IProject#setDescription` required the caller to own `IResourceRuleFactory#modifyRule`, which was implemented with the `IWorkspaceRoot` scheduling rule. This was too restrictive in most cases, and unnecessarily prevented other threads from modifying other projects in the workspace while `modifyRule` was held. In the 3.4 release, the `IWorkspaceRoot` scheduling rule is now only needed when configuring project natures: clients calling `IProject#setDescription` without the `AVOID_NATURE_CONFIG` flag. `IResourceRuleFactory#modifyRule` now only locks the project resource by default, allowing more concurrency when opening or closing projects, or when setting the description but not configuring project natures.

Action required: Clients calling `IProject#setDescription` should ensure they own the correct scheduling rule. See the API javadoc for a description of what rules are required for this and other workspace operations.

## 3. Markers views no longer support additions entries

What is affected: Clients adding to the Problems, Tasks or Markers Views using `IWorkbenchActionConstants.MB_ADDITIONS`

Description: The Problems, Tasks or Markers Views no longer have an entry for `IWorkbenchActionConstants.MB_ADDITIONS` as the pop-up and view menus are now all commands based.

Action required: Additions to these views can be made using the `org.eclipse.ui.menus` extension point.

## 4. org.eclipse.tomcat no longer included

What is affected: Any RCP application with a dependency on the org.eclipse.tomcat plugin.

Description: Up to and including Eclipse 3.2 the help system used a Tomcat server and included the plug-in org.eclipse.tomcat. Since Eclipse 3.3 the help system no longer uses Tomcat and instead uses the Equinox web server. In Eclipse 3.4 org.eclipse.tomcat was removed from platform and sdk builds.

Action required: Remove any dependencies to org.eclipse.tomcat. If you need a web server use the Equinox server defined in org.eclipse.equinox.http.jetty.

## 5. Corrected API for tabbed properties view to not require the usage of internal types

What is affected: Clients calling `TabbedPropertySheetPage.getCurrentTab()`, overriding `TabbedPropertySheetPage.updateTabs()`, or implementing `ITabSelectionListener`.

Description: The above mentioned methods and types were not usable because they required clients to refer to internal, non-API types. To fix the leakage of internal types, methods were removed/renamed in a binary incompatible way. For details, please refer to bug 224390.

Action required: Clients who were referring to internal non-API types to make use of the mentioned methods and types will have to be updated to refer to the cleaned up API. Plug-ins that need to work against both versions 3.3 and 3.4 will have to use reflection to protect themselves from the binary incompatibilities.