Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Programming
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Databases
Mail Systems
openSolaris
Eclipse Documentation
Techotopia.com
Virtuatopia.com
Answertopia.com

How To Guides
Virtualization
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Windows
Problem Solutions
Privacy Policy

  




 

 

EclipseJDT Plug-in Developer Guide
Previous Page Home Next Page

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


 
 
  Published under the terms of the Eclipse Public License Version 1.0 ("EPL") Design by Interspire