Erforderliche Änderungen bei der Übernahme der 3.0-Mechanismen und -APIs

In diesem Abschnitt werden die Änderungen beschrieben, die erforderlich sind, wenn Sie versuchen, Ihre 2.1-Plug-ins für die Übernahme von 3.0-Mechanismen und -APIs zu verändern.

org.eclipse.core.runtime.compatibility entfernen

Die Eclipse 3.0-Laufzeit ist erheblich anders. Die zugrunde liegende Implementierung basiert auf der OSGi-Gerüstspezifikation. Die Eclipse 3.0-Laufzeit umfasst eine Kompatibilitätsebene (im Plug-in org.eclipse.core.runtime.compatibility), die die 2.1-APIs verwaltet. Plug-in-Entwickler, die an einer zusätzlichen Leistung und Funktion interessiert sind, sollten die Übernahme der 3.0-APIs und das Entfernen ihrer Abhängigkeit von der Kompatibilitätsebene in Erwägung ziehen. Der Kompatibilitätscode weist drei Positionen auf:

Der nachstehende Text enthält detaillierte Informationen darüber, welche Klassen und Methoden für Kompatibilitätszwecke vorhanden sind, sowie Hinweise zur Aktualisierung eines Plug-ins.

Plug-ins und Produktpakete

Die Eclipse-Laufzeit wurde in zwei Teile aufgeteilt; die Klassenladefunktion und das Vorbedingungsmanagement sowie das Erweiterungs-/Erweiterungspunktmanagement. Diese Aufteilung ermöglicht eine natürliche/reibungslose Übernahme der OSGi-Gerüstspezifikation für die Klassenladefunktion und das Vorbedingungsmanagement. Dadurch wiederum wird eine Reihe von neuen Funktionalitäten aus dem dynamischen Plug-in installieren/aktualisieren/deinstallieren und eine bessere Konfigurierbarkeit ermöglicht.

Während wir weiterhin von Plug-ins sprechen, ist in der neuen Laufzeit ein Plug-in in Wirklichkeit ein Produktpaket zuzüglich einiger Erweiterungen und Erweiterungspunkte. Der Begriff Produktpaket ist nach der OSGi-Gerüstspezifikation definiert und bezieht sich auf eine Sammlung von Typen und Ressourcen; ferner steht er mit produktpaketübergreifenden Vorbedingungsinformationen in Zusammenhang. Die Erweiterungsregistrierung ist die neue Form der Plug-in-Registrierung und enthält auschließlich detaillierte Angaben zu Erweiterungen und Erweiterungspunkten. Im Großen und Ganzen besteht kein erheblicher Unterschied zwischen der Erweiterungsregistrierungs-API und der entsprechenden Plug-In-Registrierungs-API (weitere Informationen finden Sie unter Registrierungen).

In der Eclipse 2.x-Laufzeit hat das Plug-in-Objekt zahlreiche Funktionen und Verantwortlichkeiten:

In der Eclipse 3.0-Laufzeit sind diese Funktionen und Verantwortlichkeiten auf verschiedene Objekte aufgeteilt.

Produktpaket
Das Produktpaket ist die OSGi-Modularitätseinheit. Es ist ein Klassenladeprogramm je Produktpaket vorhanden und es können Eclipse-ähnliche, produktpaketübergreifende Abhängigkeitsdiagramme der Klassenladeprogramme erstellt werden. Produktpakete verfügen über eine Gültigkeitsdauer für den Start und die Beendigung und das OSGi-Gerüst überträgt mit Produktpaketen in Zusammenhang stehende Ereignisse (z.B. installieren, auflösen, starten, stoppen, deinstallieren, ...) an die betreffenden Komponenten. Im Gegensatz zu der Eclipse Plug-in-Klasse ist die OSGi-Produktpaket-Klasse nicht erweiterbar, d. h. die Entwickler können nicht ihre eigene Produktpaketklasse definieren.
BundleActivator
Der BundleActivator ist eine Schnittstelle, die von dem OSGi-Gerüst definiert wird. Jedes Produktpaket kann eine Klasse für die Aktivierungsfunktion des Produktpakets definieren, ähnlich wie ein Plug-in seine Plug-in-Klasse definiert. Die angegebene Klasse wird von dem Gerüst als Exemplar erstellt und verwendet, um die Verarbeitung der Gültigkeitsdauer Starten() und Stoppen() zu implementieren. Es besteht jedoch ein erheblicher Unterschied in der Art der Verarbeitung der Gültigkeitsdauer. In Eclipse ist es üblich (wenn auch nicht empfohlen), dass die Plug-in-Klassen die Initialisierung und die Registrierung ausführen. In OSGi dürfen die Aktivierungsfunktionen nur von der Registrierung ausgeführt werden. Die Durchführung einer umfangreichen Initialisierung (oder anderer Aktivitäten) in BundleActivator.start() gefährdet die Flexiblität des Systems.
BundleContext
BundleContexts sind die OSGi-Mechanismen für die Offenlegung der allgemeinen Systemfunktion für einzelne Produktpakete. Jedes Produktpaket hat ein eindeutiges und privates Exemplar des BundleContext, das es für den Zugriff auf Systemfunktionen (z. B. getBundles() zur Feststellung aller Produktpakete des Systems) verwenden kann.
Plug-in
Das neue Plug-in hat große Ähnlichkeit mit der ursprünglichen Eclipse Plug-in-Klasse, wobei die folgenden Ausnahmen festzustellen sind: Plug-in-Objekte werden nicht mehr von der Laufzeit benötigt oder von ihr verwaltet und verschiedene Methoden sind veraltet. Es handelt sich im Wesentlichen um einen vereinfachten Mechanismus, der eine Menge nützlicher Funktionen und Mechanismen enthält, jedoch nicht mehr unbedingt benötigt wird. Viele der bereitgestellten Funktionen sind auch über die Plattform-Klasse in der Laufzeit verfügbar.

Das Plug-in implementiert auch BundleActivator. Damit wird berücksichtigt, dass mit einem zentralen Objekt, das die Gültigkeitsdauer und Semantik eines Plug-ins darstellt, Vorgänge vereinfacht werden. Beachten Sie, dass damit jedoch nicht der schnellen Initialisierung von Datenstrukturen, die bei den Plug-ins heute üblich ist, zugestimmt wird. Wir können nicht genug betonen, dass Plug-ins aktiviert werden können, weil auf eine etwas periphere Klasse während der Prüfung einer Klasse in einem anderen Plug-in verwiesen wurde, d. h. die Tatsache, dass Ihr Plug-in aktiviert wird, bedeutet nicht, dass seine Funktion unbedingt benötigt wird. Beachten Sie, dass Sie eine andere BundleActivator-Klasse definieren können oder überhaupt keine Aktivierungsfunktion für das Produktpaket haben müssen.

Die für das Portieren einer 2.x Plug-in-Klasse zu Eclipse 3.0 erforderlichen Schritte hängen davon ab, welche Funktionen die Klasse ausübt. Wie vorstehend erläutert, fällt die meiste Gültigkeitsdauerarbeit für das Starten in einer der folgenden Kategorien an:

Initialisierung
Die Initialisierung von Datenstrukturen und Modellen erfolgt häufig über Plugin.startup(). Auf den ersten Blick würde man diese Aktivität in einem BundleActivator.start() ausführen, d. h. die Funktion im Plug-in belassen. Davon wird nachdrücklich abgeraten. Wie die 2.x-Plug-ins können die 3.0-Plug-ins/Produktpakete aus zahlreichen Gründen unter verschiedenen Umständen gestartet werden.
Ein reales Beispiel aus den Tagen von Eclipse 2.0 erläutert diesen Fall. Es war ein Plug-in vorhanden, das in einem großen Modell initialisiert wurde, für das das Laden einiger 11 MB für den Code und viele Megabytes von Daten erforderlich war. Es gab einige relativ häufige Anwendungsfälle, in denen dieses Plug-in aktiviert wurde, wenn das im Navigator angezeigte Projektsymbol mit einem bestimmten Formatierungssteuerzeichen als Dekorator versehen werden sollte. Dieser Test erforderte keine Initialisierung von Starten(), doch alle Benutzer mussten in allen Anwendungsfällen Speicher und Zeit für diese schnelle Initialisierung opfern.
Die alternative Strategie besteht darin, diese Initialisierung auf die klassische, langsame Art durchzuführen. Anstatt Modelle bei der Aktivierung des Plug-ins/Produktpakets zu initialisieren, kann diese beispielsweise nur ausgeführt werden, wenn sie wirklich erforderlich ist (z. B. mit einer zentralisierten Modellzugriffsmethode). In zahlreichen Anwendungsfällen ist dafür derselbe Zeitaufwand erforderlich, in anderen Szenarien wird dieser Ansatz jedoch die Initialisierung (möglicherweise auf unbestimmte Zeit) zurückstellen. Wir empfehlen, sich während des Portierens von 2.1-Plug-ins die Zeit zu nehmen, die angewandte Initialisierungsstrategie zu überdenken.
Registrierung
Der Start eines Plug-ins ist der geeignete Zeitpunkt, um Listenerfunktionen, Services, etc. zu registrieren und Hintergrundverarbeitungsthreads zu starten (z. B. empfangsbereit an einem Socket). Plugin.start() kann ein angemessener Ort für die Durchführung dieser Aktivitäten sein. Es kann auch sinnvoll sein, diese bis zu einem anderen Auslöser zu verschieben (z.B. die Verwendung einer bestimmten Funktion oder eines Datenelements).
Globale Plug-in-Daten
Ihre Plug-in-Klasse kann diese Funktion weiter ausführen. Das Hauptproblem stellt dar, dass Plug-in-Objekte nicht mehr umfassend über eine vom System verwaltete Liste zugänglich sind. In Eclipse 2.x konnten Sie jedes Plug-in-Objekt des Plug-ins über die Plug-in-Registrierungsdatenbank ermitteln. Dies ist jetzt nicht mehr möglich. In den meisten Fällen ist diese Art des Zugriffs nicht erforderlich. Plug-ins, auf die über die Registrierung zugegriffen wird, werden häufiger verwendet als generische Plug-ins und der Aufruf domänenspezifischer Methoden. Eine äquivalente Funktionalitätsebene kann über den Zugriff und die Bearbeitung der entsprechenden Produktpaketobjekte erreicht werden.

Registrierungen und das Plug-in-Modell

In der neuen Laufzeit besteht eine Trennung zwischen der Information und den Strukturen, die für die Ausführung eines Plug-ins und die entsprechenden Erweiterungen und Erweiterungspunkte erforderlich sind. Der erste Punkt wird von der OSGi-Gerüstspezifikation definiert und verwaltet. Der zweite Punkt sind Eclipse-spezifische Konzepte und sie werden von dem Eclipse-Laufzeitcode hinzugefügt. Entsprechend wurde die ursprüngliche Plug-in-Registrierung und die entsprechenden Objekte in OSGi-Produktpakete und die Eclipse Erweiterungsregistrierung aufgeteilt.

Die Teile von IPluginRegistry, die mit der Erweiterungsspezifikation zusammenhängen (z.B. IPluginDescriptor, ILibrary, IPrequisite), sind veraltet und die übrigen Teile, die zu den Erweiterungen und Erweiterungspunkten gehören, wurden nach IExtensionRegistry versetzt. Ferner sind die so genannten Modellobjekte, die zu der Plug-in-Registrierung insgesamt gehören, jetzt veraltet. Diese Typen wurden von der Laufzeit hauptsächlich zur Unterstützung von Tools wie PDE dargestellt und als Exemplar erstellt. Leider war es oft der Fall, dass die benötigten Informationen die Funktionalität oder Kapazitäten der Laufzeit überstiegen (z. B. Erinnerungszeilennummern für plugin.xml-Elemente), und schließlich mussten die potenziellen Nutzer der Laufzeitinformationen ohnehin ihre eigenen Strukturen verwalten.

Für die neue Laufzeit haben wir die von der Laufzeit bereitgestellten Funktionen neu bewertet. Sie enthält jetzt nur noch die Funktionen, die für die Ausführung der Laufzeit wesentlich sind oder deren Ausführung anderweitig äußerst schwierig ist. Wie vorstehend erwähnt, sind die Modellobjekte der Plug-in-Registrierung sowie die Plug-in-Parsing-API jetzt veraltet. Die neue Erweiterungsregistrierung verwaltet die wesentlichen erweiterungsbezogenen Informationen. Eine neue Status-Struktur (siehe org.eclipse.osgi.service.resolver.State und Entsprechendes) ermöglicht die Bearbeitung der wesentlichen, ausführungsbezogenen Informationen.

NL-Fragmentstruktur

In Eclipse 3.0 wurde die NL-Fragmentstruktur aktualisiert, um eine größere Konsistenz zu erreichen. Vorher wurde davon ausgegangen, dass die Konvertierungen für Dateien wie z. B. plugin.properties sich innerhalb der von den Fragmenten bereitgestellten JARs befinden. Da sich die ursprünglichen Dateien im Stamm des entsprechenden Host-Plug-ins befinden, würde eine Position der konvertierten Dateien im Stamm der NL-Fragemente eine konsistentere Position darstellen. Zum Beispiel:

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

Beachten Sie, dass die Datei nl1.jar früher die Konvertierungen für plugin.properties enthalten hätte. Diese Dateien befinden sich nun im Stamm des Fragments und die JAR enthält Konvertierungen aller konvertierbaren Ressourcen (d. h. Dateien, die über das Klassenladeprogramm geladen werden) des Host-Plug-ins.

Natürlich wird die Eclipse 2.1 NL-Fragmentstruktur weiterhin für ein 2.1-Host-Plug-in, das auf Eclipse 3.0 läuft, unterstützt. Sie können jedoch ein 2.1-NL-Fragment nicht in einem 3.0-Plug-in verwenden. Das Fragment muss für die neue Struktur aktualisiert werden.

Überblick über Änderungen der API

org.eclipse.core.boot (Paket org.eclipse.core.boot)

Das gesamte Paket org.eclipse.core.boot ist veraltet. Der BootLoader wurde mit org.eclipse.core.runtime.Platform zusammengefügt, da es nicht mehr sinnvoll ist, zwischen Boot und Laufzeit zu trennen. Beachten Sie, das das Plug-in org.eclipse.core.boot in Wirklichkeit unterbrochen wurde und der gesamte Code entweder in die neue Laufzeit oder die Kompatibilitätsebene versetzt wurde.

IPlatformConfiguration war immer ein Typ, der von und für die Eclipse-Komponente Installieren/Aktualisieren definiert wurde. Mit der Umstrukturierung der Laufzeit können wir diesen Typ wieder an seine angemessene Position versetzen. Diese Klasse bleibt im Wesentlichen unverändert und wurde als org.eclipse.update.configurator.IPlatformConfiguration wieder verpackt.

IPlatformRunnable wurde nach rg.eclipse.core.runtime.IPlatformRunnable versetzt.

IExtension und IExtensionPoint (Paket org.eclipse.core.runtime)

Die Methode getDeclaringPlugin() (für beide Klassen) übergibt dem Plug-in eine Aufwärtsverbindung, die die Erweiterung bzw. den Erweiterungspunkt angibt. Das neue Registrierungsmodell trennt die Ausführungsaspekte des Plug-ins von den Aspekten der Erweiterung/Erweiterungspunkte und enthält nicht mehr IPluginDescriptors. Benutzer dieser API sollten die neue Methode getParentIdentifier(), die für IExtension und IExtensionPoint angegeben ist, in Erwägung ziehen.

ILibrary, IPluginDescriptor, IPluginRegistry und IPrerequisite (Paket org.eclipse.core.runtime)

In der ursprünglichen Laufzeit verwaltete die Plug-in-Registrierung die gesamte Laufzeitkonfiguration. In Eclipse 3.0 ist dies nun zwischen dem OSGi-Gerüst und der Erweiterungsregistrierung aufgeteilt. Daher sind diese Klassen nun veraltet. Die Hinweise zur Veraltung enthalten genaue Angaben darüber, wie der Code aktualisiert werden sollte.

Plattform und Plug-in (Paket org.eclipse.core.runtime)

In der neuen Laufzeit werden Plug-in-Objekte nicht mehr von der Laufzeit verwaltet und somit kann nicht mehr generisch über die Plattform auf sie zugegriffen werden. Entsprechend ist auch die Plug-in-Registrierung nicht mehr vorhanden bzw. ermöglicht keinen Zugriff mehr auf Plug-in-Deskriptoren. Es stehen jedoch geeignete Ersatzmethoden zur Verfügung und werden in der Javadoc der veralteten Methoden in diesen Klassen genau erläutert.

org.eclipse.core.runtime.model (Paket org.eclipse.core.runtime.model)

Alle Typen in diesem Paket sind nun veraltet. Weitere Informationen finden Sie in der Erläuterung über Registrierungen.

IWorkspaceRunnable und IWorkspace.run (Paket org.eclipse.core.resources)

Für Clients der IWorkspace.run(IWorkspaceRunnable,IProgressMonitor)-Methode sollte die Verwendung dieser Methode überdacht und die Verwendung der ausgefeilten Methode IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) in Erwägung gezogen werden. Die alte IWorkspace.run-Methode ermöglicht für die Dauer der IWorkspaceRunnable einen Blick auf den gesamten Arbeitsbereich. Dies bedeutet, dass eine mit dieser Methode ausgeführte Operation niemals gleichzeitig mit anderen Operationen ausgeführt werden, kann, die den Arbeitsbereich verändern. In Eclipse 3.0 wurden viele lang andauernde Operationen in die Hintergrundthreads versetzt, sodass die Wahrscheinlichkeit von Konflikten zwischen Operationen stark gestiegen ist. Falls eine modale Vordergrundoperation durch eine lang andauernde Hintergrundoperation blockiert wird, wird die Benutzerschnittstelle blockiert, bis die Hintergrundoperation abgeschlossen ist oder eine der beiden Operationen abgebrochen wird.

Es wird empfohlen, alle Verweise auf die alte IWorkspace.run auf die Verwendung der neuen Methode mit einem Regelparameter zur Zeitplanung umzustellen. Die Regel zur Zeitplanung sollte so ausgeklügelt sein, dass sie alle Änderungen durch diese Operation umfasst. Falls die Operation versucht, Ressourcen außerhalb des Geltungsbereichs der Regel der Zeitplanung zu verändern, tritt eine Laufzeitausnahmebedingung auf. Die genaue Regel zur Zeitplanung, die für eine bestimmte Operation des Arbeitsbereichs erforderlich ist, ist nicht angegeben und kann unterschiedlich sein, je nach installiertem Repository-Provider für ein bestimmtes Projekt. Das Factory IResourceRuleFactory sollte verwendet werden, um die Regel zur Zeitplanung für eine ressourcenverändernde Operation zu erhalten. Falls gewünscht, kann eine MultiRule zur Angabe mehrerer Ressourcenregeln verwendet werden. Die Komfortmethode MultiRule.combine kann verwendet werden, um die Regeln verschiedener ressourcenverändernder Operationen zu kombinieren.

Falls keine Sperrung erforderlich ist, kann eine Regel zu Zeitplanung von Null verwendet werden. Dies ermöglicht der Ausführungsklasse, alle Ressourcen des Arbeitsbereichs zu verändern, verhindert jedoch, dass andere Threads den Arbeitsbereich gleichzeitig verändern. Bei einfachen Änderungen des Arbeitsbereichs stellt dies die einfachste und häufigste Lösung dar.

IWorkbenchPage (Paket org.eclipse.ui)

IEditorDescriptor (Paket org.eclipse.ui)

ISharedImages (Paket org.eclipse.ui)

IWorkbenchActionConstants (Paket org.eclipse.ui)

IWorkbenchPreferenceConstants (Paket org.eclipse.ui)

IExportWizard (Paket org.eclipse.ui)

IImportWizard (Paket org.eclipse.ui)

INewWizard (Paket org.eclipse.ui)

WorkbenchHelp (Paket org.eclipse.ui.help)

IHelp (Paket org.eclipse.help)

ITextEditorActionConstants (Paket org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (Paket org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (Paket org.eclipse.ui.texteditor)

TextEditorActionContributor (Paket org.eclipse.ui.editors.text)

Erweiterungspunkt annotationTypes (Plug-in org.eclipse.ui.editors)

Es ist nun das explizite Konzept von Anmerkungstypen vorhanden, siehe Annotation.getType() und Annotation.setType(). Der Typ einer Anmerkung kann sich während seiner Gültigkeitsdauer ändern. Für die Deklaration von Anmerkungstypen wurde ein neuer Erweiterungspunkt hinzugefügt: "org.eclipse.ui.editors.annotationTypes". Ein Erweiterungstyp hat einen Namen und kann als Subtyp eines anderen deklarierten Anmerkungstyps deklariert werden. Bei der Deklaration eines Anmerkungstyps können auch die Attribute "markerType" und "markerSeverity" verwendet werden, um anzugeben, dass die Markierungen eines bestimmten Typs und einer bestimmten Wertigkeit in den Texteditoren als Anmerkungen eines bestimmten Anmerkungstypen dargestellt werden sollen. Die Attribute "markerType" und "markerSeverity" in "org.eclipse.ui.editors.markerAnnotationSpecification" sollten nicht mehr verwendet werden. Die Spezifikationen für Markierungsanmerkungen sind daher unabhängig von den Markierungen und der Name ist folglich irreführend. Der Name wird jedoch beibehalten, um die Abwärtskompatibilität sicherzustellen.

Exemplare von Unterklassen von AbstractMarkerAnnotationModel stellen die korrekten Anmerkungstypen für Anmerkungen, die sie von Markierungen erstellen, automatisch fest und richten sie ein. Um den Anmerkungstyp zu einer bestimmten Markierung oder einem Paar von markerType und markerSeverity über das Programm abzurufen, verwenden Sie org.eclipse.ui.texteditor.AnnotationTypeLookup.

Der Zugang zu den Anmerkungstypen wird von IAnnotationAccessExtension bereitgestellt. Für einen bestimmten Anmerkungstpy können Sie die Kette der Supertypen erhalten und prüfen, ob der Anmerkungstyp ein Subtyp eines anderen Anmerkungstyps ist. DefaultMarkerAnnotationAccess implementiert diese Schnittstelle.

Erweiterungspunkt markerAnnotationSpecification (org.eclipse.ui.editors Plug-in)

Der Anmerkungstyp ist der Schlüssel, mit dem die zugehörige Spezifikation für die Markierungsanmerkung gefunden wird. Da Anmerkungstypen erweitert werden können, besteht auch zwischen den Spezifikationen für Markierungsanmerkungen eine implizite Beziehung. Daher wird eine Spezifikation für eine Markierungsanmerkung für einen bestimmten Anmerkungstyp durch die Spezifikationen für die Markierungsanmerkung für den Supertypen des bestimmten Anmerkungstypen abgeschlossen. Aus diesem Grund müssen Spezifikationen für Markierungsanmerkungen nicht mehr abgeschlossen werden, wie dies vorher erforderlich war. Die Spezifikationen für Markierungsanmerkungen werden von AnnotationPreferences abgerufen. Mit org.eclipse.ui.texteditor.AnnotationPreferenceLookup können Sie Spezifikationen für Markierungsanmerkungen für einen bestimmten Anmerkungstypen abrufen, der transparent den Abschluss der Benutzervorgabe gemäß der Anmerkungskette des Supertypen durchführt.

Die Spezifikation für Markierungsanmerkungen wurde durch drei zusätzliche Attribute erweitert, um die Definition von angepassten Darstellungen eines bestimmten Anmerkungstypen in der vertikalen Skala zu ermöglichen. Diese Attribute sind: "icon", "symbolicIcon" und "annotationImageProvider". Der Wert für "icon" ist der Pfad zu einer Datei, die die Abbildung des Symbols enthält. Der Wert von "symbolicIcon" kann "Fehler", "Warnung", "Info", "Task" oder "Lesezeichen" sein. Das Attribut "symbolicIcon" wird verwendet, um der Plattform mitzuteilen, dass die Anmerkung mit denselben Abbildungen dargestellt werden sollte, die von der Plattform für die Darstellung von Fehlern, Warnungen, Infos, Tasks bzw. Lesezeichen verwendet wird. Der Wert von "annotationImageProvider" ist eine Klasse, die org.eclipse.ui.texteditor.IAnnotationImageProvider implementiert, sodass eine vollständig angepasste Darstellung der Anmerkung möglich ist.

Die vertikale Skala verwendet ihre zugehörigen IAnnotationAccess/IAnnotationAccessExtension, um die Anmerkungen darzustellen. Die vertikale Skala ruft nicht mehr Annotation.paint auf. Im Allgemeinen wird nicht mehr davon ausgegangen, dass sich Anmerkungen selbst darstellen. Die Methoden "paint" und "getLayer" sind veraltet, um die Anmerkung endlich unabhängig von der Benutzerschnittstelle zu machen. DefaultMarkerAnnotationAccess dient als Standardimplementierung von IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementiert die folgende Strategie für das Ausfüllen von Anmerkungen: Falls eine Anmerkung IAnnotationPresentation implementiert, wird IAnnotationPresentation.paint aufgerufen. Falls nicht, wird der Image-Provider für Anmerkungen in den Benutzervorgaben für Anmerkungen nachgesehen. Der Image-Provider für Anmerkungen ist nur verfügbar, wenn er angegeben ist und wenn das Plug-in, das die umschließende Spezifikation für die Markierungsanmerkung definiert, bereits geladen wurde. Falls kein Image-Provider für Anmerkungen vorhanden ist, wird der Aufruf weitergeleitet. Ansonsten wird das angegebene "Symbol" nachgesehen. "symbolicIcon" wird für das letzte Zurücksetzen verwendet. Für die Darstellung von Anmerkungen ist die Anmerkungsdarstellungschicht relevant. DefaultMarkerAnnotationAccess sucht nach der Darstellungsschicht mithilfe der folgenden Strategie: Falls die Benutzervorgabe für die Anmerkung eine Darstellungsschicht angibt, wird die angegebene Schicht verwendet. Falls keine Schicht vorhanden ist und die Anmerkung IAnnotationPresentation implementiert und IAnnotationPresentation.getLayer anderweitig verwendet wird, wird die Standarddarstellungsschicht (die 0 ist) zurückgegeben.

Migration auf Erweiterungspunkt annotationTypes (Plug-in org.eclipse.ui.editors)

Die folgenden Anmerkungstypen werden von dem Plug-in org.eclipse.ui.editors deklariert:

   <extension point="org.eclipse.ui.editors.annotationTypes">
      <type
         name="org.eclipse.ui.workbench.texteditor.error"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="2">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.warning"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="1">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.info"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="0">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.task"
         markerType="org.eclipse.core.resources.taskmarker">
      </type>
      <type
         name="org.eclipse.ui.workbench.texteditor.bookmark"
         markerType="org.eclipse.core.resources.bookmark">
      </type>
   </extension>

Die definierte markerAnnotationSpecification-Erweiterung stellt nicht mehr die Attribute "markerType" und "markerSeverity" bereit. Diese definieren das Attribut "symbolicIcon" mit dem entsprechenden Wert. Deshalb werden MarkerAnnotation.paint und MarkerAnnotation.getLayer nicht mehr aufgerufen, d. h. das Überschreiben dieser Methoden hat keine Auswirkungen. Die betroffenen Clients sollten IAnnotationPresentation implementieren.

ILaunchConfigurationType (Paket org.eclipse.debug.core)

Mit der Einführung von erweiterbaren Startmodi in 3.0 kann mehr als ein Startstellvertreter für einen Startkonfigurationstyp vorhanden sein. Versionen vor 3.0 unterstützten nur einen Startstellvertreter je Startkonfigurationstyp. Die Methode ILaunchConfigurationType.getDelegate() ist jetzt veraltet. Die Methode getDelegate(String mode) sollte an ihrer Stelle verwendet werden, um den Startstellvertreter für einen bestimmten Startmodus abzurufen. Die veraltete Methode wurde so geändert, dass der Startstellvertreter für den Ausführungsmodus zurückgegeben wird.

ILaunchConfigurationTab und ILaunchConfigurationTabGroup (Paket org.eclipse.debug.ui)

Startregisterkartengruppen und Startregisterkarten werden nicht mehr benachrichtigt, wenn ein Startvorgang abgeschlossen ist. Die Methode launched(ILaunch) in den Schnittstellen ILaunchConfigurationTab und ILaunchConfigurationTabGroup ist veraltet und wird nicht mehr aufgerufen. Wenn sich die Startfunktion auf diese Methode gestützt hat, war dies immer problematisch, da Registerkarten nur vorhanden sind, wenn der Startvorgang von dem Startdialog ausgeführt wird. Mit der Einführung des Startvorgangs im Hintergrund wird diese Methode nicht mehr aufgerufen, da der Startdialog geschlossen wird, bevor das resultierende Startobjekt vorhanden ist.

ILaunchConfigurationTab und AbstractLaunchConfigurationTab (Paket org.eclipse.debug.ui)

Es wurden zwei Methoden zu der Schnittstelle ILaunchConfigurationTab hinzugefügt - aktiviert und deaktiviert. Diese neuen Methoden für die Gültigkeitsdauer werden aufgerufen, wenn eine Registerkarte geöffnet bzw. verlassen wird. Vorhandene Implementierungen von ILaunchConfigurationTab, mit denen die von dem Debug-Plug-in (AbstractLaunchConfigurationTab) bereitgestellte abstrakte Klasse in Unterklassen aufgeteilt werden, sind binär kompatibel, da die Methoden in der abstrakten Klasse implementiert werden.

In früheren Versionen wurde einer Registerkarte die Mitteilung initializeFrom, wenn sie aktiviert war, und performApply, wenn sie deaktiviert war, gesendet. Auf diese Weise stellte das Registerkartengerüst der Startkonfiguration eine registerkartenübergreifende Kommunikation über eine Startkonfiguration her (durch das Aktualisieren der Konfiguration mit den aktuellen Attributwerten, wenn eine Registerkarte verlassen wurde, und die Aktualisierung der neu geöffneten Registerkarte). Da jedoch viele Registerkarten keine registerkartenübergreifende Kommunikation durchführen, kann dies unzureichend sein. Außerdem gibt es keine Möglichkeit, zwischen einer aktivierten Registerkarte und einer Registerkarte, die eine ausgewählte Startkonfiguration zum ersten Mal anzeigt, zu unterscheiden. Die neu hinzugefügten Methoden ermöglichen es Registerkarten, zwischen Aktivierung und Initialisierung und zwischen Deaktivierung und Speichern aktueller Werte zu unterscheiden.

Die von der abstrakten Registerkarte bereitgestellte Standardimplementierung von aktiviert ruft initializeFrom auf. Und die Standardimplementierung von deaktiviert ruft performApply auf. Registerkarten, für die die Vorteile der neuen API genutzt werden sollen, sollten diese Methoden, wenn erforderlich, überschreiben. Im Allgemeinen stellt die empfohlene Strategie für Registerkarten, die keine registerkartenübergreifende Kommunikation durchführen, die erneute Implementierung dieser Methoden, sodass sie nichts ausführen, dar.

Erweiterungspunkttyp launchConfigurationTabGroup (Paket org.eclipse.debug.ui)

In früheren Versionen wurde das Wechseln der Perspektive in der Startkonfiguration über die Startkonfigurationsattribute ATTR_TARGET_DEBUG_PERSPECTIVE und ATTR_TARGET_RUN_PERSPECTIVE angegeben. Mit dem Zusatz von erweiterbaren Startmodi in 3.0 ist dieser Ansatz nicht mehr ausreichend. Das Wechseln der Perspektive wird jetzt in der Startkonfigurationstypbasis für jeden von einem Startkonfigurationstyp unterstützten Startmodus angegeben. Es wurde zu DebugUITools eine API hinzugefügt, um die einem Startkonfigurationstyp zugeordnete Perspektive für einen besonderen Startmodus einzurichten und zu nutzen.

Ein zusätzliches, optionales launchMode-Element wurde zu dem Erweiterungspunkt launchConfigurationTabGroup hinzugefügt, wodurch es einer bereitgestellten Registerkartengruppe möglich ist, die Standardperspektive für einen Startkonfigurationstyp und -modus anzugeben.

Von der Eclipse-Benutzerschnittstelle können die Benutzer die einem Startkonfigurationstyp zugeordnete Perspektive bearbeiten, indem der Startkonfigurationsdialog geöffnet und ein Startkonfigurationstypknoten in der Struktur (und nicht eine einzelne Konfiguration) ausgewählt wird. Eine Registerkarte wird angezeigt, die es dem Benutzer ermöglicht, eine Perspektive mit dem jeweiligen unterstützten Startmodus einzurichten.

[nur JDT] IVMRunner (Paket org.eclipse.jdt.launching)

Der Klasse VMRunnerConfiguration wurden zwei Methoden hinzugefügt, um das Einrichten und Abrufen von Umgebungsvariablen zu unterstützen. Implementierungselemente von IVMRunner sollten VMRunnerConfiguration.getEnvironment() aufrufen und die Umgebung an die ausgeführte JVM weitergeben. Clients, die DebugPlugin.exec(String[] cmdLine, File workingDirectory) verwenden, können dies ausführen, indem sie DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) aufrufen. Die einfache Weitergabe in dem Ergebnis von getEnvironment() ist ausreichend.

[nur JDT] VMRunnerConfiguration und Bootstrap-Klassen (Paket org.eclipse.jdt.launching)

In früheren Versionen hatte die VMRunnerConfiguration ein Attribut, um den Bootpfad zu beschreiben. Das Attribut ist eine Sammlung von Zeichenfolgen, die in dem Argument -Xbootclasspath angegeben sind. Drei neue Attribute wurden der VMRunnerConfiguration zur Unterstützung von JVMs hinzugefügt, die das Hinzufügen an den Bootpfad ermöglichen. Die neu hinzugefügten Methoden/Attribute sind die Folgenden:

Das alte Attribut getBootClassPath() ist nach wie vor vorhanden und enthält einen komplett äquivalenten Pfad zu dem der drei neuen Attribute. VMRunners, die die neuen Bootpfadoptionen unterstützen, sollten die neuen Attribute jedoch nutzen.

[nur JDT] Verbesserte Unterstützung für Arbeitskopien (Paket org.eclipse.jdt.core)

Die Arbeitskopiefunktion des Java-Modells wurde in 3.0 überarbeitet, um eine wesentlich erweiterte Funktionalität bereitzustellen. Vor 3.0 ermöglichte das Java-Modell das Erstellen von einzelnen Arbeitskopien von Kompiliereinheiten. Die Arbeitskopien können geändert und später festgeschrieben werden. Eine eingeschränkte Analyse der Arbeitskopie im Kontext des übrigen Java-Modells wurde unterstützt. Es gab jedoch keine Möglichkeit, dass diese Analysen in mehr als einer Arbeitskopie gleichzeitig berücksichtigt wurden.

Die Änderungen in 3.0 ermöglichen das Erstellen und Verwalten einer Reihe von Arbeitskopien von Kompiliereinheiten und das Durchführen von Analysen bei Vorhandensein aller Arbeitskopien einer Reihe. Beispielsweise ist es jetzt für einen Client wie die JDT-Refactoringfunktion möglich, Arbeitskopien für eine oder mehrere Kompiliereinheiten zu erstellen, deren Änderung erwogen wird, und anschließend Typverweise zwischen den Arbeitskopien aufzulösen. Früher war dies nur möglich, nachdem die Änderungen an den Arbeitskopien der Kompiliereinheit festgeschrieben worden waren.

Die Java-Modell-API wird auf zweierlei Weise verändert, um diese verbesserte Unterstützung hinzuzufügen:

(1) Die früher unter IWorkingCopy zu findende und von ICompilationUnit übernommene Funktionalität wurde in ICompilationUnit zusammengefügt. Die Schnittstelle IWorkingCopy wurde nur an dieser Stelle genutzt und war ohne Grund allgemeiner als sie sein musste. Mit dieser Änderung wird die API vereinfacht. IWorkingCopy ist veraltet. Andere Stellen der API, an denen IWorkingCopy als ein Parameter oder Ergebnistyp verwendet wird, sind ebenfalls veraltet; die Ersatz-API-Methoden erwähnen ICompilationUnit anstelle von IWorkingCopy.

(2) Die Schnittstelle IBufferFactory wurde durch WorkingCopyOwner ersetzt. Die verbesserte Unterstützung für Arbeitskopien macht erforderlich, dass ein Objekt vorhanden ist, das der Eigentümer der Arbeitskopien ist. Obwohl IBufferFactory an der richtigen Stelle ist, vermittelt der Name nicht angemessen, wie der neue Arbeitskopiemechanismus funktioniert. WorkingCopyOwner ist sehr viel suggestiver. Zusätzlich ist WorkingCopyOwner als eine abstrakte Klasse und nicht als Schnittstelle deklariert, um die zukünftige Weiterentwicklung des Konzepts des Arbeitskopieeigentümers zu ermöglichen. Die einzige Methode von IBufferFactory wird ohne Auswirkungen nach WorkingCopyOwner versetzt. WorkingCopyOwner implementiert nicht IBufferFactory, um eindeutig darzustellen, dass IBufferFactory der Vergangenheit angehört. IBufferFactory ist veraltet. Andere Stellen der API, an denen IBufferFactory als ein Parameter oder ein Ergebnistyp erscheint, sind ebenfalls veraltet; die Ersatz-API-Methoden erwähnen WorkingCopyOwner anstelle von IBufferFactory.

Diese Änderungen unterbrechen die Binärkompatibilität nicht.

Bei der Migration sollten alle Verweise auf den Typ IWorkingCopy in Verweise auf ICompilationUnit geändert werden. Die Implementierung von IWorkingCopy implementiert ebenfalls ICompilationUnit, was bedeutet, dass Objekte des Typs IWorkingCopy sicher in ICompilationUnit umgesetzt werden können.

Eine Klasse, die IBufferFactory implementiert, muss durch eine Unterklasse von WorkingCopyOwner ersetzt werden. Obwohl WorkingCopyOwner nicht IBufferFactory selbst implementiert, könnte die Unterklasse von WorkingCopyOwner, die IBufferFactory implementiert und dabei eine Brücke zwischen dem alten und neuen (IBufferFactory erstellt als createBuffer(IOpenable) deklariert werden, wobei WorkingCopyOwner createBuffer(ICompilationUnit) deklariert; ICompilationUnit erweitert IOpenable).

Da die Änderungen, die IWorkingCopy und IBufferFactory betreffen, miteinander verflochten sind, empfehlen wir die gleichzeitige Bearbeitung von beiden. Im Folgenden sind die Einzelheiten der Veraltungen dargestellt:

Umstrukturierung des Plug-ins org.eclipse.help

Das Plug-in org.eclipse.help, das früher die APIs und Erweiterungspunkte für die Bereitstellung und Erweiterung des Hilfesystems sowie die Darstellung der Hilfe enthalten hat, enthält jetzt nur noch APIs und Erweiterungspunkte für die Bereitstellung und den Zugriff auf Hilferessourcen. Einen Teil der Benutzerschnittstelleimplementierung der Standardhilfe, die in diesem Plug-in enthalten war, wurde zusammen mit den APIs für die Erweiterung der Implementierung in ein neues Plug-in org.eclipse.help.base versetzt. Die APIs und der Erweiterungspunkt für die Bereitstellung der Benutzerschnittstellenhilfe sowie die Anzeige der Hilfe wurden in das Plug-in org.eclipse.ui versetzt. Diese Umstrukturierung ermöglicht Anwendungen eine größere Flexibilität im Hinblick auf das Hilfesystem; die neue Struktur ermöglicht es Anwendungen, die auf der generischen Workbench basieren, ihre eigene Hilfebenutzerschnittstelle und/oder Hilfeimplementierung bereitzustellen oder das Hilfesystem vollständig auszulassen.

Da die betroffenen Erweiterungspunkte und API-Pakete nur von dem Hilfesystem selbst genutzt werden sollten, ist es unwahrscheinlich, dass vorhandene Plug-ins von dieser Änderung betroffen sind. Sie werden hier lediglich der Vollständigkeit halber aufgenommen:

Neue Benutzerschnittstellen-API für Suchvorgänge

In 3.0 wurde eine neue API für die Implementierung von angepassten Suchvorgängen hinzugefügt. Die ursprüngliche API ist in 3.0 veraltet und wir empfehlen, Clients zu der neuen API in den Paketen org.eclipse.search.ui and org.eclipse.search.ui.text zu portierten.

Clients müssen Implementierungen von ISearchQuery, ISearchResult und ISearchResultPage erstellen. Die ISearchResultPage-Implementierung muss anschließend in dem neuen Erweiterungspunkt org.eclipse.search.searchResultViewPages bereitgestellt werden.

Standardimplementierungen für ISearchResult und ISearchResultPage werden in dem Paket org.eclipse.search.ui.text bereitgestellt.

Null-Mitteilungen in MessageBox und DirectoryDialog (Paket org.eclipse.swt.widgets)

Vor 3.0 führte der Aufruf von DirectoryDialog.setMessage(String-Zeichenfolge) oder MessageBox.setMessage(String string) von SWT mit einem Wert von Null für die Zeichenfolge zu einem Dialog ohne Text im Titel. Dieses Verhalten war nicht spezifiziert (die Weitergabe von Null war nie zulässig) und führt zu Problemen mit getMessage, für das eine Rückgabe von Null nicht zulässig ist. In 3.0 führt die Weitergabe von Null jetzt zu der Ausgabe einer Ausnahmebedingung IllegalArgumentException und die Spezifikationen wurden geändert, um dies wiederzugeben, sodass die Methode mit ihrer Superklasse Dialog.setMessage in Einklang steht. Stellen Sie bei der Verwendung von Dialog.setMessage sicher, dass die weitergegebene Zeichenfolge niemals Null ist. Geben Sie einfach eine leere Zeichenfolge weiter, wenn Sie einen Dialog ohne Text im Titel möchten.

Modales Fortschrittsfeedback verbessern

Die Unterstützung gleichzeitiger Operationen erfordert ausgereifterte Arten für das Anzeigen des modalen Fortschritts. Als Teil der Flexibilitätsbemühungen wurde eine zusätzliche Fortschrittsunterstützung in der Klasse IProgressService implementiert. Die bisherige Art zum Anzeigen des Fortschritts mit dem ProgressMonitorDialog funktioniert weiterhin. Um die Benutzererfahrung zu verbessern, empfehlen wir jedoch die Migration auf den neuen IProgressService.

Das Dokument Modalen Fortschritt in Eclipse 3.0 anzeigen enthält Informationen über die Migration auf den neuen IProgressService.

Debug-Aktionsgruppen entfernt

Der Erweiterungspunkt der Debug-Aktionsgruppen wurde entfernt (org.eclipse.debug.ui.debugActionGroups). In Eclipse 3.0 wurde die Unterstützung der Workbench für Aktivitäten über den Erweiterungspunkt org.eclipse.platform.ui.activities eingeführt. Diese Unterstützung stellt alles bereit, was die Debug-Aktionsgruppen bereitgestellt haben, ist einfacher zu verwenden (sie unterstützt Muster anstatt einer ausführlichen Angabe aller Aktionen) und verfügt über eine programmatische API zur Unterstützung. Wenn Verweise auf die alten Erweiterungspunkte nicht entfernt werden, führt dies zu keinen Störungen. Verweise auf den Erweiterungspunkt werden einfach ignoriert. Softwareanbieter werden dazu aufgefordert, die Workbench-Aktivitätenunterstützung zu nutzen, um sprachspezifische Debuggeraktionen sprachspezifischen Aktivitäten zuzuordnen (z. B. können C++ Debugaktionen möglicherweise einer Aktivität mit dem Namen "Developing C++" zugeordnet werden).

BreakpointManager kann deaktiviert werden.

IBreakpointManager definiert jetzt die Methoden setEnabled(boolean) und isEnabled(). Wenn der Ünterbrechungspunktmanager deaktiviert ist, sollten Debugger alle registrierten Unterbrechungspunkte ignorieren. Die Debug-Plattform stellt auch einen neuen Mechanismus für die Listenerfunktion, IBreakpointManagerListener, zur Verfügung, der es Clients ermöglicht, sich beim Unterbrechungspunktmanager zu registrieren, um benachrichtigt zu werden, wenn sich seine Aktivierung ändert. Die Sicht 'Unterbrechungspunkte' ruft diese API von einer neuen Umschaltaktion auf, die den Benutzern die Auswahl "Alle Unterbrechungspunkte überspringen" ermöglicht. Debugger, die die Aktivierung des Unterbrechungspunktmanagers nicht berücksichtigen, werden daher als unterbrochen angezeigt, wenn der Benutzer versucht, dieses Feature zu verwenden.

[nur JDT] Java-Suchteilnehmer (Paket org.eclipse.jdt.core.search)

Mit Java verwandte Sprachen (wie z. B. JSP, SQLJ, JWS, etc.) sollten in der Lage sein, an Java-Suchvorgängen teilzunehmen. Insbesondere sollten Implementierungselemente dieser Sprachen in der Lage sein, Folgendes auszuführen:

Ein solches Implementierungselement wird als Suchteilnehmer bezeichnet. Es erweitert die Klasse SearchParticipant. Suchteilnehmer werden an Suchabfragen übergeben (siehe SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

Für das Indexieren oder Suchen von Übereinstimmungen muss ein Suchteilnehmer eine Unterklasse von SearchDocument definieren, die die Inhalte des Dokuments durch Überschreiben von entweder getByteContents() oder getCharContents() abrufen kann. Ein Exemplar dieser Unterklasse wird an getDocument(Zeichenfolge) zurückgegeben.

Ein Suchteilnehmer, der ein Dokument indexieren möchte, verwendet SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath), um das Indexieren eines bestimmten Dokuments in dem Index zu terminieren. Sobald das Dokument für das Indexieren bereit ist, ruft das zugrunde liegende Gerüst SearchParticipant.indexDocument(SearchDocument, IPath) auf. Der Suchteilnehmer erhält dann den Inhalt des Dokuments, wertet es aus und fügt mithilfe von SearchDocument.addIndexEntry(char[], char[]) Indexeinträge hinzu.

Nach dem Indexieren können die Indizes abgefragt und Übereinstimmungen mithilfe von SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) gefunden werden. Zunächst wird der Suchteilnehmer mithilfe von SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) nach den für diese Abfrage benötigten Indizes gefragt. Für jeden Indexeintrag, für den eine Übereinstimmung mit dem angegebenen Muster festgestellt wird, wird durch das Abfragen des Suchteilnehmers (siehe getDocument(Zeichenfolge)) ein Suchdokument erstellt. Alle diese Dokumente werden an den Suchteilnehmer weitergegeben, sodass die Übereinstimmungen mithilfe von locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) gefunden werden können. Der Suchteilnehmer benachrichtigt den SearchRequestor mithilfe des acceptSearchMatch(SearchMatch) über die Übereinstimmungen der Suche und die Weitergabe eines Exemplars an eine Unterklasse von SearchMatch.

Ein Suchteilnehmer kann einen Teil seiner Arbeit an den Standard-Java-Suchteilnehmer delegieren. Ein Exemplar dieses Standardteilnehmers wir mithilfe von SearchEngine.getDefaultSearchParticipant() empfangen. Wenn ein SQLJ-Teilnehmer dazu aufgefordert wird, Übereinstimmungen zu finden, kann er .java-Dokumente aus seinen .sqlj-Dokumenten erstellen und die Arbeit mit der Weitergabe der .java-Dokumente an den Standardteilnehmer delegieren.