Les modifications apportées à Eclipse rendent incompatibles les versions 3.0 et 3.1 au niveau des plug-ins. Les entrées ci-dessous décrivent les zones modifiées et mettent à disposition des instructions pour la migration des plug-ins 3.0 vers la version 3.1. Ne consultez cette page que si vous rencontrez des difficultés lors de l'exécution d'un plug-in 3.0 sous la version 3.1.
Objets affectés : les plug-ins qui initialisent leurs valeurs de préférences de plug-ins par défaut en chevauchant Plugin#initializeDefaultPreferences
ou utilisent des modules d'écoute de modifications des préférences.
Description : Dans Eclipse 3.1, l'objet org.eclipse.jface.preference.IPreferenceStore
obtenu à partir de org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore
a été déplacé en haut du nouveau cadre de travail de préférence Eclipse 3.0 fournit par le plug-in org.eclipse.core.runtime
.
Action requise : En conséquence, les clients utilisant les API de préférence doivent vérifier les deux questions suivantes :
chaîne
ou un objet typé. Ainsi, pour être un bon client, les programmes d'écoute de modification de préférence doivent être en mesure de traiter ces trois situations possibles.org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences
, alors vous devez vous assurer d'inclure le plug-in org.eclipse.core.runtime.compatibility
dans la liste des plug-ins requis puisque cette dépendance a été supprimée du plug-in org.eclipse.ui.workbench
.Reportez-vous à la documentation relative au magasin de préférences pour plus de détails.
Objets affectés : les plug-ins qui créent, manipulent ou stockent des objets IPath.
Description : dans Eclipse 3.0, IPath avait un nombre de restrictions sur les segments des chemins qui était plus restrictif que les restrictions du système d'exploitation sous-jacent. Cela comprenait :
Ces restrictions ont été supprimées dans Eclipse 3.1 lorsque l'emplacement (espace de travail) des données de la plateforme se situe sur un système de fichiers n'ayant pas ces restrictions.
Action requise : afin d'activer le traitement approprié de la plage étendue des chemins, l'utilisation complète de Path et IPath au sein des plug-ins doit être revue et mise à jour comme indiqué ci-dessous. La plupart des plug-ins non modifiés continueront à se comporter exactement comme dans la version 3.0 sur tous les chemins considérés comme légaux dans la version 3.0. Cependant, à moins que vous ayez effectué les modifications prescrites, elles sont susceptibles d'échouer dans les cas impliquant les chemins considérés comme légaux dans la version 3.1 et illégaux dans la version 3.0.
Les plug-ins qui stockent les représentations de chaîne des chemins dans un format nécessitant d'être lisible sur plusieurs plateformes doivent migrer vers la nouvelle méthode de fabrique Path.fromPortableString. Cette méthode génère une instance IPath à partir d'un format indépendant de la plateforme. Cette représentation de chaîne des chemins peut être créée à l'aide de la méthode IPath.toPortableString. Les exemples de fichiers de métadonnées qui sont affectés comprennent les fichiers qui sont stockés au sein des projets de l'espace de travail d'Eclipse (.project, .classpath, etc) et tous les chemins stockés dans le magasin des préférences (org.eclipse.core.runtime.preferences.IPreferencesService).
Remarque : fromPortableString lira correctement toutes les chaînes de chemin qui ont été créées via la méthode IPath.toString d'Eclipse 3.0 mais pas via la méthode toString d'Eclipse 3.1. Ainsi, dans la plupart des cas, aucun changement n'est requis pour les formats de fichiers de métadonnées existants excepté pour commencer l'écriture des chemins avec toPortableString et la lecture des chemins avec fromPortableString.
Les plug-ins qui créaient des chemins à partir de littéraux de chaîne codés en dur en supposant que ':' et '\' avait une signification précise sur toutes les plateformes devront être migrés. La solution la plus simple est de restreindre les littéraux de chemin de chaîne au sous-ensemble pris en charge sur toutes les plateformes (éviter les deux points et la barre oblique inversée). Les littéraux de chemin peuvent prendre en charge l'ensemble complet des chemins Unix valides en utilisant le format de chaîne de chemin transférable généré par Path.toPortableString. Ce format interprète le premier signe deux points (':') comme un séparateur d'unités, la barre oblique ('/') comme un séparateur de segments et le double deux points ("::") comme un signe deux points littéral. Par exemple, le code new Path("c:/temp") créera un chemin relatif avec deux segments sur des plateformes Unix. De manière similaire, new Path("a\\b") créera un chemin avec un segment unique sur des plateformes Unix et un chemin avec deux segments sous Windows.
Il est possible que les plug-ins, créant des chemins à l'aide de la méthode IPath.append(String) qui supposait que ':' et '\' avait une signification particulière sur toutes les plateformes, doivent mettre à jour leur code. Dans Eclipse 3.1, cette méthode utilise des délimiteurs de segment et d'unité spécifique de système d'exploitation pour interpréter la chaîne de chemin fournie. Par exemple, l'appel de append("a\\b") sur des plateformes Unix ajoutera désormais un seul segment alors qu'il continuera à en ajouter deux sous Windows.
Tous les fichiers de données lus et interprétés par la plate-forme ne traiteront plus les ':' et '\' comme des caractères spéciaux sur toutes les plate-formes. Tous les chemins stockés dans les fichiers de données qui peuvent être lus sur plusieurs plate-formes doivent être au format portable. Par exemple, les chemins des fichiers d'icônes et les autres chemins dans plugin.xml doivent utiliser uniquement '/' comme séparateur du segment du chemin.
Objets affectés : les plug-ins qui manipulent ou conservent des objets IExtensionPoint
,
IExtension
et IConfigurationElement
à partir du plug-in de la plateforme d'Eclipse ou du registre d'extension.
Description : avant la version 3.0, tous les objets obtenus à partir du registre d'extension (ou l'ancien registre du plug-in) étaient tout le temps bons. Des modifications ont été apportées dans Eclipse 3.0 permettant aux plug-ins d'être ajoutés ou supprimés de manière dynamique sans avoir à redémarrer Eclipse. Lorsqu'un plug-in est supprimé sans procéder à un redémarrage, ses entrées dans le registre d'extension seront nécessairement invalides. Cela signifie qu'un autre plug-in détenant un objet obtenu précédemment à partir d'une entrée du registre d'extension du plug-in supprimé serait laissé avec un objet invalide. La seule recommandation qu'un client pourrait obtenir proviendrait de IRegistryChangeEvent
.
Le problème existe depuis Eclipse 3.0 mais il est rarement rencontré dans la pratique puisqu'il est très rare pour un plug-in d'être supprimé sans redémarrer Eclipse.
Ce problème a été pris en compte dans la version 3.1 par :
IExtensionPoint
, IExtension
,
IConfigurationElement
spécifient désormais que InvalidRegistryObjectException
sera affiché lorsque l'objet est invalide. L'exception n'est pas activée de telle manière que les clients dynamiques qui ne sont pas au courant ne soient pas obligés de l'activer.isValid()
a été ajoutée à ces interfaces afin qu'un client puisse déterminer si un objet est toujours valide.Action requise : si votre plug-in nécessite une prise en compte dynamique (c'est-à-dire
la capacité à traiter immédiatement l'ajout ou la suppression de plug-ins), le code relatif à l'objet IExtensionPoint
, IExtension
et IConfigurationElement
provenant d'un autre plug-in doit être modifié pour intercepter IRegistryChangeEvent
,
exactement comme s'il s'agissait d'une exception vérifiée. L'interception d'exception (plutôt qu'une pré-vérification isValid()
) est le seul moyen efficace de traiter le cas où un plug-in est supprimé par une unité d'exécution concurrente (ce qui sera certainement le cas).
Objets affectés : les plug-ins qui accèdent par programmation aux options du module de formatage de code Java.
Description : Dans Eclipse 3.0, les valeurs de l'option du module de formatage de code
org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR
ne pouvaient être que TAB
ou SPACE
. La spécification n'expliquait pas clairement que le type de valeur était une énumération susceptible d'évoluer ultérieurement. Dans Eclipse 3.1, une troisième valeur possible, MIXED
,
a été ajoutée pour traiter ce problème 73104.
La spécification a été modifiée pour inclure cette nouvelle valeur et pour permettre l'ajout ultérieur de nouvelles valeurs.
Action requise : les clients lisant ou définissant par programmation cette option du module de formatage de code doivent vérifier leur code afin de prendre en compte cette nouvelle troisième valeur et de s'assurer qu'elle est écrite de manière robuste et qu'elle échouera si elle rencontre une valeur d'option non anticipée.
Objets affectés : les plug-ins qui sous-classent ou instancient org.eclipse.ant.core.AntCorePreferences
Description : dans Eclipse 3.0, il n'était pas indiqué que la classe org.eclipse.ant.core.AntCorePreferences
ne pouvait pas être instanciée ou sous-classée par les clients.
Il s'agissait d'un manque qui a été pris en compte dans Eclipse 3.1 avec le marquage de la classe comme ne pouvant pas être sous-classée ou instanciée.
Action requise : les clients créant par programmation une instance de org.eclipse.ant.core.AntCorePreferences
doivent migrer leur code pour récupérer les préférences en utilisant : org.eclipse.ant.core.AntCorePlugin.getPreferences()
.
Chaque sous-classe devra être rectifiée pour ne plus sous-classer org.eclipse.ant.core.AntCorePreferences
.
Objets affectés : les applications RCP qui remplacent le journal JFace défini par le plan de travail.
Description : dans Eclipse 3.0, le plan de travail définit le journal du plan de travail comme le journal à utiliser pour la journalisation des erreurs JFace, en transférant directement le journal du plug-in du plan de travail vers org.eclipse.jface.util.Policy.setLog(ILog)
. Dans la version 3.1, la dépendance sur ILog
a été supprimée de JFace afin d'activer des applications autonomes utilisant SWT et JFace en dehors de l'exécution d'Eclipse. Une nouvelle interface ILogger
a été mise en place pour répondre aux besoins de JFace. La plan de travail a été modifié pour fournir un ILogger
encapsulant le plan de travail ILog
. Pour plus de détails, reportez-vous au bogue 88608.
Action requise : la plupart des applications RCP ne nécessitent pas de remplacer le journal défini par le plan de travail, mais si elles ont précédemment appelé Policy.setLog(ILog)
, elles devront être modifiées pour transmettre un ILogger
à la place.
Objets affectés : les applications RCP qui attendent une perspective par défaut non-nulle.
Description : afin de permettre aux applications RCP de démarrer avec une fenêtre vide sans perspective ouverte (enrichissement71150),
WorkbenchAdvisor.getInitialWindowPerspectiveId()
et IPerspectiveRegistry.getDefaultPerspective()
ont été modifiés pour permettre le renvoi d'une valeur nulle. Dans l'IDE, il existe toujours une perspective par défaut, c'est pourquoi IPerspectiveRegistry.getDefaultPerspective()
ne renvoie pas de valeur nulle. De même, si une application RCP existante a renvoyé précédemment une valeur non-nulle à partir de WorkbenchAdvisor.getInitialWindowPerspectiveId()
,
alors IPerspectiveRegistry.getDefaultPerspective()
renverra toujours une valeur non-nulle.
Action requise : aucune action requise par les clients.
Objets affectés : les plug-ins qui implémentent org.eclipse.ui.IViewLayout.
Description : dans Eclipse 3.0, il n'était pas indiqué que la classe org.eclipse.ui.IViewLayout
pouvait ne pas être implémentée par les clients. Il s'agissait d'un oubli qui a été rectifié dans Eclipse 3.1 avec le marquage de la classe comme ne pouvant pas être implémentée par les clients.
Action requise : chaque classe d'implémentation devra être rectifiée pour ne plus implémenter org.eclipse.ui.IViewLayout
.
Objets affectés : les plug-ins qui implémentent org.eclipse.jdt.launching.IVMInstall.
Description : dans Eclipse 3.0, il n'était pas indiqué que la classe org.eclipse.jdt.launching.IVMInstall
ne pouvait pas être directement implémentée par les clients. Il s'agissait d'un oubli qui a été rectifié dans Eclipse 3.1 avec le marquage de la classe comme ne pouvant pas être directement implémentée par les clients. Pour maintenir une compatibilité binaire, nous autorisons les clients à implémenter directement l'interface, mais nous recommandons fortement que les clients sous-classent org.eclipse.jdt.launching.AbstractVMInstall
à la place. Les clients qui implémentent IVMInstall
doivent également implémenter la nouvelle interface en option org.eclipse.jdt.launching.IVMInstall2
,
qu'implémente désormais AbstractVMInstall
. Nous recommandons aux clients d'implémenter la nouvelle interface, IVMInstall2
, afin d'éviter le problème noté dans le bogue 73493. La migration recommandée est de sous-classer AbstractVMInstall
.
Action requise : Chaque classe d'implémentation qui ne sous-classe pas déjà org.eclipse.jdt.launching.AbstractVMInstall
devra être rectifiée pour sous-classer org.eclipse.jdt.launching.AbstractVMInstall.
Objets affectés : les plug-ins qui utilisent org.eclipse.ui.SelectionEnabler.SelectionClass.
Description : dans Eclipse 3.0, la classe d'implémentation imbriquée org.eclipse.ui.SelectionEnabler.SelectionClass
était publique sans restriction sur son utilisation. Il s'agissait d'un oubli qui a été rectifié dans Eclipse 3.1 avec la classe rendue visible par le package.
Action requise : chaque classe instanciant ou étendant org.eclipse.ui.SelectionEnabler.SelectionClass
devra être rectifiée pour ne plus faire référence à cette classe.
Objets affectés : les plug-ins qui appellent getParent()
sur une sous-classe de org.eclipse.jface.action.ContributionItem.
Description : dans Eclipse 3.0, la méthode org.eclipse.jface.action.ContributionItem.getParent()
ne spécifiait pas qu'elle pouvait renvoyer une valeur nulle. Il s'agissait d'un oubli qui a été rectifié dans Eclipse 3.1 avec Javadoc expliquant quand la méthode peut renvoyer une valeur nulle. Pour plus de détails, reportez-vous au bogue 92777.
Action requise : tout code appelant ContributionItem.getParent() doit s'assurer qu'il peut traiter un résultat nul.
Objets affectés : les plug-ins qui implémentent org.eclipse.ui.views.properties.IPropertySource
ou IPropertySource2.
Description : dans Eclipse 3.0, la spécification de la méthode org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean)
n'a pas été correctement modifiée pour spécifier que la valeur 'true' doit être renvoyée si la propriété spécifiée n'avait pas de valeur par défaut significative. Dans les versions précédentes, il était spécifié que la valeur 'false' devait être renvoyée dans ce cas. Il s'agissait d'une modification d'API faite par inadvertance, même si l'implémentation fonctionnait toujours comme auparavant si la source de propriété implémentait IPropertySource
et non IPropertySource2
.
Cela a été rectifié dans la version 3.1, avec IPropertySource.isPropertySet(boolean)
revenant à sa spécification antérieure (avec 'false' renvoyée dans ce cas) et IPropertySource2.isPropertySet(boolean) remplaçant ceci pour spécifier que 'true' doit être renvoyée dans ce cas. Pour plus de détails, reportez-vous au bogue
21756.
Action requise : toute classe implémentant IPropertySource ou IPropertySource2, lorsque certaines propriétés n'ont pas de valeurs par défaut significatives, doit être vérifiée afin de s'assurer qu'elle renvoie la valeur appropriée pour isPropertySource(boolean). Les clients doivent vérifier que le bouton Restaurer la valeur par défaut dans la vue Propriétés fonctionne comme prévu pour leur source de propriété.
Objets affectés : les plug-ins qui utilisaient l'élément expérimental
handlerSubmission
introduit dans le point d'extension
org.eclipse.ui.commands
Eclipse 3.0.
Description : Dans Eclipse 3.0, un élément expérimental a été introduit dans le point d'extension org.eclipse.ui.commands
. Cet élément était un moyen d'enregistrer les gestionnaires via XML. Alors, un mécanisme supérieur, le point d'extension org.eclipse.ui.handlers
, a été introduit. Etant donné que l'élément a été marqué comme expérimental, il a maintenant été supprimé.
Action requise : chaque plug-in définissant un élément
handlerSubmission
doit migrer vers le point d'extension org.eclipse.ui.commands
.
Objets affectés : les plug-ins qui ont défini le champ GLOBAL_IGNORES_CHANGED de TeamUI.
Description : Dans Eclipse 3.0, le champ GLOBAL_IGNORES_CHANGED a été ajouté à la classe TeamUI. Ce champ est une constante utilisée dans un événement de modifications des propriétés pour indiquer que la liste des ignorées globales maintenue par le plug-in Team a été modifiée. Ce champ n'est pas marqué comme final dans 3.0 mais aurait du l'être. Il est rendu final dans 3.1.
Action requise : chaque plug-in qui paramétrait le champ ci-dessus ne peut plus le faire.
Objets affectés : les plug-ins qui n'utilisent pas correctement FillLayout.
Description : Dans Eclipse 3.0, aucune données de disposition n'est associée au FillLayout et si une application a affectée des données de disposition à un enfant géré par un FillLayout, elles ont été ignorées. Dans Eclipse 3.1, le support a été ajouté à FillLayout pour masquer les informations de taille afin d'améliorer les performance de redimensionnement. Les données cachées sont stockées dans un objet FillData associé à chaque enfant géré par le FillLayout. Si une application n'a pas affecté correctement des données de disposition à un enfant, une ClassCastException sera envoyée lorsque computeSize est appelée sur le parent.
Action requise : Rechercher les enfants dans un FillLayout auxquels sont affectées des données de disposition et arrêter l'affectation des données de disposition.
Objets affectés : les plug-ins qui capturent des exceptions tout en créant des widgets.
Description : Dans Eclipse 3.0, si un widget a été créé avec un parent supprimé, aucune exception n'a été lancée et le code du widget a échoué à un point ultérieur ou une SWTException avec le texte "Widget Is Disposed" (Widget supprimé) a été lancée. Dans Eclipse 3.1, si un widget est créé avec un parent supprimé, le constructeur lancera une IllegalArgumentException avec le texte "Argument not valid" (Argument non valide).
Action requise :chaque code qui gère l'exception SWTException lors de la création d'un widget devra également gérer l'exception IllegalArgumentException.