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