This section describes changes that are required if you are trying to change your 3.1 plug-in to adopt the 3.2 mechanisms and APIs.
Eclipse 3.2 provides new infrastructure for associating launch configurations with resources. This mapping allows the platform to perform resource based filtering on launch configurations and allows the platform to optionally delete launch configurations when an associated project is deleted. The launch dialog has been enhanced to support a set of filters to optionally hide configurations associated with closed and deleted projects. As well, the launch dialog supports filtering based on selected working sets in the active workbench window, which can also be selected in the launch dialog.
It is a client responsibility to manage the resource mapping for launch configurations.
API has been added to ILaunchConfigurationWorkingCopy
to set the
resources associated with a configuration, and API has been added to ILaunchConfiguration
to get the resources associated with a configuration. For example, launch tabs,
launch shortcuts and refactoring participants should be considered when migrating.
Code that creates or modifies launch configurations should also update resource
mappings.
Eclipse 3.2 provides new infrastructure for migrating launch configurations
to be compatible with new tooling. For example, in Eclipse 3.2, support has
been added to perform resource based filter on launch configurations. Launch
configurations need to be upgraded to provide resource mappings to leverage
this new feature. Users can manually migrate launch configurations in their
workspace from the
Run/Debug > Launching > Launch Configurations
preference page, by pressing the Migrate button.
A new optional migration delegate attribute has been added to the launchConfigurationTypes
extension point, specifying a class that implements the new interface ILaunchConfigurationMigrationDelegate
.
A migration delegate is responsible for identifying migration candidates and
migrating them.
A new optional attribute has been added to the launchModes
extension
point to properly support the externalization of cascade launch menu action
labels. Clients that contribute launch modes should specify the proper label
to use for launch cascade menus such as "Run As". The new attribute
is named launchAsLabel
. Proper labels have been provided by the
platform for run, debug and profile launch modes. For backwards compatibility,
when the new attribute is unspecified for a launch mode, the cascade menu labels
are generated as before, via MessageFormat with "{0} As
".
See related bug 105235.
ICU4J is a set of Java libraries that provides more comprehensive support for Unicode, software globalization, and internationalization. In order to provide this functionality to the Eclipse community, ICU4J was added to the platform build for Eclipse 3.2. You will see it in the build as a plug-in named com.ibm.icu. The Eclipse platform will be utilizing ICU APIs in Eclipse 3.2.
Migration of application code can be done incrementally, meaning full adoption of all ICU4J function is not necessary to reap the benefits of using ICU4J. See the ICU4J page on the Eclipse wiki for more details on how to migrate your code to use ICU4J.
The addition of the ICU4J plug-in adds on the order of 3MB to the footprint. Some applications may not want to absorb ICU4J if application size takes precedence over adopting ICU4J function. If this is the case, a replacement plug-in (com.ibm.icu.base) is available from the Eclipse platform build page. Download the plug-in, remove the com.ibm.icu plug-in and its source counterpart from the /plugins directory, and drop in the replacement plug-in. This is required because the Eclipse platform adopted the ICU APIs for 3.2 so just removing the ICU plug-in will result in compilation errors in platform code. The replacement plug-in is about 100KB in size and simply calls through to the default JDK's implementation of the most commonly used classes and APIs in ICU4J. Again, you can read the ICU4J page on the Eclipse wiki for more details using the ICU replacement plug-in.
In order to support ICU4J in JFace, some creative API additions were required to prevent referencing ICU classes in API. This resulted in the addition of:
org.eclipse.jface.viewers.ViewerComparator
, of which org.eclipse.jface.viewers.ViewerSorter
is now a subclass.org.eclipse.jface.viewers.StructuredViewer
, to support the addition of org.eclipse.jface.viewers.ViewerComparator
.The ViewerSorter
class has a public method getCollator()
that returns a java.text.Collator
. Since this method is API it could not simply be changed to use an ICU Collator. Also, ICU classes cannot be part of the API (signatures) as a direct plug-in dependency on ICU would prevent JFace from being used standalone (with SWT). To accomodate these constraints, the ViewerComparator
class that uses a java.util.Comparator
, rather than an ICU Collator, was added. This was done because ICU's Collator class implements java.util.Comparator
, so any StructuredViewer
can now use ICU's Collator rather than java.text.Collator
, but JFace doesn't have to add a dependency on the ICU4J plug-in.
The two new methods added to StructuredViewer
support using ICU's Collator to sort the contents of the viewer via a ViewerComparator
, rather than a ViewerSorter
. It is recommended that any StructuredViewer
now use these methods to get/set the viewer's sorter (comparator), instead of the getSorter()
and setSorter(ViewerSorter)
methods.
public ViewerComparator getComparator()
public void setComparator(ViewerComparator comparator)
The org.eclipse.equinox.common bundle includes several new API classes (e.g., Assert
and
ListenerList
) that have common names. If your code has a class with the same name and uses import *
statements to import both the local class and classes from the runtime, you might get the following error message:
The type ABC is ambiguous
Organizing the imports and choosing the appropriate import source should resolve this problem.
As a result of the code being moved into new runtime plug-ins, custom scripts that explicitly references org.eclispe.core.runtime might need to add one or more of the following plug-ins: