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.
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 ('$').