Incompatibilities between Eclipse 3.4 and 3.5
Eclipse changed in incompatible ways between 3.4 and 3.5 in ways that affect
plug-ins. The following entries describe the areas that changed and provide
instructions for migrating 3.4 plug-ins to 3.5. Note that you only need to look
here if you are experiencing problems running your 3.4 plug-in on 3.5.
-
ILaunchConfiguration.getLocation() can return null
-
CustomizableIntroPart no longer implements IIntroConstants
-
IResourceChangeEvent.getResource() may return null for PRE_REFRESH events
-
Methods and fields that leaks internal types are no longer accessible
-
CommonNavigator#IS_LINKING_ENABLED_PROPERTY has changed its value
-
CommonNavigator#getInitialInput() has changed its return type
What is affected: Clients that call ILaunchConfiguration.getLocation()
Description: In release 3.4 and earlier, ILaunchConfiguration.getLocation() was not specified
to return null. Since 3.5, launch configuration infrastructure has been enhanced to support storage
on external file systems (EFS). The #getLocation() method returns a location in the local file system - however, since
an external file system may not map to a local location, null can now be returned.
Action required: Clients that call ILaunchConfiguration.getLocation() should update
code to handle a null result. The #getLocation() method has been deprecated since the return
value is no longer reliable.
What is affected:Clients that reference constants from IIntroConstants via CustomizableIntroPart
Description: In release 3.4 and earlier, CustomizableIntroPart implemented the internal class IIntroConstants.
This had the side effect of accidentally exposing internal constants in an API class. Since Eclipse 3.5 this implements clause has been removed.
Action required:
Clients that reference any of these constants will see a compilation error in the source and will need to replace the reference
to the constant with a string literal of the same value. See
bug 251472 for more information
What is affected: Clients that use IResourceChangeListeners and listen on IResourceChangeEvent#PRE_REFRESH events
Description: In release 3.4, clients were notified with PRE_REFRESH events only during a single project
refresh. Since Eclipse 3.5, PRE_REFRESH events have been fired during every workspace refresh. For a workspace refresh
IResourceChangeEvent.getResource() returns null. To determine the scope of the refresh (a project or the workspace),
IResourceChangeEvent.getSource() should be used.
Action required:
Clients that listens on PRE_REFRESH events should use IResourceChangeEvent.getSource() instead of
IResourceChangeEvent.getResource() to determine the scope of the refresh. See
bug 255325 for more information.
What is affected: Clients that refer to ModelSynchronizeParticipant#refreshSchedule or call one of:
- ThreeWaySynchronizer#flush
- SubscriberParticipant#getRefreshSchedule
- SubscriberParticipant#setRefreshSchedule
- SubscriberParticipant#getSubscriberSyncInfoCollector
Description: In release 3.4 and earlier, ModelSynchronizeParticipant#refreshSchedule
and methods mentioned above were made accessible. #refreshSchedule is declared as an internal type
and referring it is illegal. Calling the methods was also illegal since attributes or returned parameters
were internal types. Since Eclipse 3.5, the field and methods are no longer accessible.
Action required:
Clients that illegally call the methods or refer ModelSynchronizeParticipant#refreshSchedule
will see a compilation error in the source and will need to remove all the calls and references.
What is affected: Clients that reference CommonNavigator#IS_LINKING_ENABLED_PROPERTY
Description: In release 3.4 and earlier, CommonNavigator#IS_LINKING_ENABLED_PROPERTY had
the value of 1. This value was the same as the IWorkbenchPartConstants#PROP_TITLE which caused confusion when
properties changed. Since Eclipse 3.5 the value of this property was changed to something that does
not conflict with other property values.
Action required:
Any code that refers to CommonNavigator#IS_LINKING_ENABLED_PROPERTY must be recompiled to get the correct value.
What is affected: Clients that illegally subclass CommonNavigator
Description: In release 3.4 and earlier, CommonNavigator#getInitialInput() returned a type of
IAdaptable, in release 3.5 this has been changed to by Object to allow greater flexibility. Subclassing
the CommonNavigator is supported only in the 3.5 release, however this note is included because we are aware
that many clients have subclassed CommonNavigator in prior releases.
Action required:
If you override CommonNavigator#getInitialInput(), you will need to fix and recompile your code to use the
new return type of Object.
See
bug 143430 for more information.
