# 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. Library entries on the build path can now target external folders
2. Assumption that a ZIP archive extension was always .zip or .jar has been removed
3. Asking the qualified name of a binary type with a dot ('.') separator will now honor this separator

## 1. Library entries on the build path can now target external folders

What is affected: Clients that call `IJavaProject.getResolvedClasspath(boolean)`, `IJavaProject.getRawClasspath()`, or `IPackageFragmentRoot.getPath()`.

Description: In Eclipse 3.3, the class folders on a classpath could only be inside the workspace. In Eclipse 3.4, these class folders can also be outside the workspace. Note that this change has no impact on binary compatibility.

Action required: Clients retrieving the `IPath` from a class folder on the classpath should no longer assume that this path is internal to the workspace.

## 2. Assumption that a ZIP archive extension was always ".zip" or ".jar" has been removed

What is affected: Clients that call `IJavaProject.getResolvedClasspath(boolean)`, `IJavaProject.getRawClasspath()`, `IPackageFragmentRoot.getPath()`, or `JavaConventions.validateClasspath(IJavaProject, IClasspathEntry[], IPath)`.

Description: In Eclipse 3.3, the ZIP archives on a classpath could only have a ".zip" or a ".jar" extension. In Eclipse 3.4, these ZIP archives can have any extension. Thus the classpath validation will no longer report an error if a ZIP archive with an extension other than ".zip" or ".jar" is put on the classpath. Note that this change has no impact on binary compatibility.

Action required: Clients should no longer assume that the only valid extensions for ZIP archives on the classpath are ".zip" or ".jar".

## 3. Asking the qualified name of a binary type with a dot ('.') separator will now honor this separator

What is affected: Clients that call `IType.getTypeQualifiedName(char)`, or `IType.getFullyQualifiedName(char)` on a binary member type with a dot ('.') separator.

Description: In Eclipse 3.3, calling `IType.getTypeQualifiedName(char)`, or `IType.getFullyQualifiedName(char)` on a binary member type with a dot ('.') separator would return a qualified name where the member type name was separated from the enclosing type name with a dollar ('$'). In Eclipse 3.4, calling `IType.getTypeQualifiedName(char)`, or `IType.getFullyQualifiedName(char)` on a binary member type with a dot ('.') separator now correctly honor this separator. Note that this change has no impact on binary compatibility.

Action required: Clients should no longer assume that the member type separator in the qualified name of a binary type is always dollar ('$').