### Eclipse Workspace Patch 1.0 #P org.eclipse.jdt.doc.isv Index: porting/3.3/incompatibilities.html =================================================================== RCS file: porting/3.3/incompatibilities.html diff -N porting/3.3/incompatibilities.html --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ porting/3.3/incompatibilities.html 1 Jan 1970 00:00:00 -0000 @@ -0,0 +1,40 @@ + + + +
+ + + + + + +Eclipse changed in incompatible ways between 3.2 and 3.3 in ways that affect + plug-ins. The following entries describe the areas that changed and provide + instructions for migrating 3.2 plug-ins to 3.3. Note that you only need to look + here if you are experiencing problems running your 3.2 plug-in on 3.3.
+ +What is affected: Clients that call IClassFile.getType()
.
Description: In Eclipse 3.2, the method org.eclipse.jdt.core.IClassFile.getType()
+ thrown a org.eclipse.jdt.core.JavaModelException
. This is no longer the case in Eclipse 3.3!
Action required: Clients calling IClassFile.getType()
+ will have to fix possible 'Unreachable catch block for JavaModelException' compiler errors
+ (only if method call is the only method throwing a JavaModelException
in the try block).
+ They also should verify for methods calling this API and throwing a JavaModelException
+ if they still need to throw this exception.
This section describes changes that are required if you are trying to change + your 3.2 plug-in to adopt the 3.3 mechanisms and APIs.
+ +This guide covers migrating Eclipse JDT 3.2 (or earlier) plug-ins to Eclipse JDT 3.3.
+One of the goals of Eclipse 3.3 was to move Eclipse forward while remaining compatible + with previous versions to the greatest extent possible. That is, plug-ins written + against the Eclipse 3.2 APIs should continue to work in 3.3 in spite of the + API changes.
+The key kinds of compatibility are API contract compatibility and binary compatibility. + API contract compatibility means that valid use of 3.2 APIs remains valid for + 3.3, so there is no need to revisit working code. Binary compatibility means + that the API method signatures, etc. did not change in ways that would cause + existing compiled ("binary") code to no longer link and run with the + new 3.3 libraries.
+While every effort way made to avoid breakage, there are a few areas of incompatibility. + This document describes the areas where Eclipse changed in incompatible ways + between 3.2 and 3.3, and provides instructions for migrating 3.2 plug-ins to + 3.3.
+