Verplichte wijzigingen bij het toepassen van 3.0-methoden en -API's

Deze sectie bevat de wijzigingen die u moet doorvoeren voordat de 2.1-plugins geschikt zijn voor de 3.0-methoden en API's.

org.eclipse.core.runtime.compatibility niet langer gebruiken

De runtime van Eclipse 3.0 is aanzienlijk veranderd. De onderliggende implementatie is gebaseerd op de implementatie van het OSGi-framework. De runtime van Eclipse 3.0 bevat een compatibiliteitslaag (in de plugin org.eclipse.core.runtime.compatibility) voor het onderhouden van de 2.1-API's. Pluginontwikkelaars die hogere prestaties willen behalen en meer functionaliteit willen benutten, kunnen de 3.0-API's toepassen en de compatibiliteitslaag uitschakelen. De compatibiliteitscode komt op drie plaatsen voor:

In de onderstaande tekst worden de klassen en methoden besproken die omwille van de compatibiliteit beschikbaar zijn en wordt uitgelegd hoe u uw plugin kunt bijwerken.

Plugins en bundels

De Eclipse-runtime is opnieuw gestructureerd in twee delen: het beheren van laden van klassen en vereisten en het beheren van extensies/extensiepunten. Zo kan de specificatie van het OSGi-framework voor het beheren van het laden van klassen en vereisten probleemloos worden toegepast. Bovendien wordt zo een keur aan nieuwe voorzieningen beschikbaar in de runtime, uiteenlopend van het dynamisch installeren/bijwerken/deïnstalleren van plugins tot beveiliging en verbeterde configuratiemogelijkheden.

In de nieuwe runtime is een plugin in feite een bundel met enkele extensies en extensiepunten. De term bundel wordt door de specificatie van het OSGi-framework gedefinieerd en verwijst naar een verzameling van typen en resources en bijbehorende vereiste-gegevens tussen bundels. Het extensieregister is de nieuwe versie van het pluginregister en bevat alleen gegevens over extensies en extensiepunten. De API van het extensieregister is grotendeels gelijk aan de API van het relevante pluginregister. (Raadpleeg Registers) voor meer informatie).

In de runtime van Eclipse 2.x heeft het pluginobject een aantal rollen en verantwoordelijkheden:

In de runtime van Eclipse 3.0 zijn de rollen en verantwoordelijkheden onderverdeeld in afzonderlijke objecten.

Bundel
De bundel is de OSGI-eenheid van modulariteit. Elke bundel heeft één klassenlader en bovendien kunnen klassenlader-dependencygraphs van Eclipse tussen klassen worden geconstrueerd. Een bundel heeft een levenscyclus en de events van de bundel (zoals installeren, omzetten, starten, stoppen en deïnstalleren) worden door het OSGi-framework gedistribueerd. In tegenstelling tot de Plugin-klasse van Eclipse is de Bundle-klasse van OSGi niet uitbreidbaar. Dat wil zeggen dat ontwikkelaars niet zelf een bundelklasse kunnen definiëren.
BundleActivator
BundleActivator is een interface die door het OSGi-framework wordt gedefinieerd. Voor bundels kunnen activeringsklassen worden gedefinieerd, wat vergelijkbaar is met het definiëren van een Plugin-klasse voor plugins. De opgegeven klasse wordt geïnstantieerd door het framework en gebruikt om de methoden start() en stop() voor de levenscyclus van de bundel te implementeren. Er is één belangrijk verschil tussen de levenscycli van bundels en plugins. In Eclipse worden zowel initialisatie- als registratietaken door de Plugin-klasse uitgevoerd. Activators van OSGi zijn alleen geschikt voor registratietaken. Het uitvoeren van grootschalige initialisatietaken (of andere taken die veel rekenkracht vergen) in BundleActivator.start() kunnen de stabiliteit van het systeem nadelig beïnvloeden.
BundleContext
De bundelcontext is het OSGi-mechanisme voor het beschikbaar stellen van algemene systeemfuncties aan afzonderlijke bundels. Voor elke bundel wordt een unieke en besloten instance gemaakt van BundleContext, waarmee systeemfuncties kunnen worden gebruikt (zoals getBundles() voor het opvragen van alle bundels in het systeem).
Plugin
De nieuwe Plugin-klasse is zeer vergelijkbaar met de oorspronkelijke Plugin-klasse van Eclipse, behalve dat Plugin-objecten niet langer door de runtime vereist zijn of beheerd worden. Bovendien zijn diverse methoden gedeprecieerd. De klasse biedt gemakkelijk toegang tot een keur aan nuttige functies maar is niet langer absoluut noodzakelijk. De meeste functionaliteit van de klasse is ook beschikbaar in de Platform-klasse van de runtime.

Plugin implementeert ook BundleActivator. Zo beschikt u over één centraal object voor het aanduiden van de levenscyclus en de semantiek van plugins. Merk op dat dit niet bindend is voor de veelvuldige initialisatie van gegevensstructuren in de huidige plugintechnieken. Er kan niet vaak genoeg worden benadrukt dat een plugin bijvoorbeeld al kan worden geactiveerd doordat naar een randklasse wordt verwezen tijdens de verificatie van een klasse in een andere plugin. Dat wil zeggen dat een geactiveerde plugin niet per se benodigd is. U kunt ook een andere BundleActivator-klasse definiëren of zelfs helemaal weglaten.

Welke stappen u moet uitvoeren om een Plugin-klasse van versie 2.x naar Eclipse 3.0 te converteren, is afhankelijk van de functie van de klasse. Zoals hierboven al werd aangegeven, kunnen de meeste levencyclustaken tijdens starten in één van de volgende categorieën worden onderverdeeld:

Initialisatie
De initialisatie van gegevensstructuren en modellen wordt vaak uitgevoerd in Plugin.startup(). U zou de taken natuurlijk kunnen uitvoeren in BundleActivator.start(), zodat de functie in Plugin blijft. Deze werkwijze wordt ten zeerste afgeraden. Net als 2.x-plugins kunnen ook 3.0-plugins en -bundels om vele redenen in tal van situaties worden gestart.
Deze situatie kan worden geïllustreerd aan de hand van een bestaand voorbeeld uit Eclipse 2.0, waarbij een omvangrijk model met 11 MB code en talrijke megabytes gegevens werden geïnitialiseerd door een plugin. Vaak was het zo dat de plugin al geactiveerd bleek te zijn als een bepaalde markup moest worden toegepast op het projectpictogram in de navigator. De initialisatietaken van startup() waren hierbij volstrekt overbodig, maar er werd wel geheugen gereserveerd en de initialisatie vergde extra tijd.
U kunt de initialisatie ook op de klassieke 'luie' manier uitvoeren. Zo kunt u modellen bijvoorbeeld pas initialiseren zodra ze benodigd zijn (met een gecentraliseerde methode voor modeltoegang) en niet tijdens de activering van de plugin of bundel. Het tijdsverschil zal in veel gevallen vrijwel gelijk zijn, maar soms kan de initialisatie worden uitgesteld of worden tegengehouden. Het is raadzaam de initialisatiestrategie goed uit te werken voordat u 2.1-plugins gaat converteren.
Registratie
Het starten van een plugin is een geschikt moment voor het registreren van listeners en services en het starten van achtergrond-threads (zoals het opvangen van signalen op een socket). U kunt deze taak laten uitvoeren met Plugin.start(). Het is verder mogelijk de taken pas te laten uitvoeren zodra ze geïnitieerd worden (bijvoorbeeld bij het gebruiken van een bepaalde functie of een bepaald gegevenselement).
Globale plugingegevens
Deze gegevens zijn nog steeds geschikt voor de Plugin-klasse. Plugin-objecten zijn echter niet langer globaal toegankelijk via een door het systeem beheerde lijst. In Eclipse 2.x was het mogelijk het Plugin-object van een bepaalde plugin op te vragen via het pluginregister. Deze werkwijze is niet meer mogelijk, maar een dergelijk toegangstype is meestal echter evenmin nodig. Plugins die via het register worden opgevraagd, worden meestal als generieke plugins gebruikt en niet voor het aanroepen van domeinspecifieke methoden. U beschikt over dezelfde mogelijkheden als u de bijbehorende Bundle-objecten opvraagt en manipuleert.

Registers en het pluginmodel

In de nieuwe runtime wordt een onderscheid gemaakt tussen de gegevens en de structuren voor het uitvoeren van plugins en de gegevens en de structuren voor de extensies en extensiepunten van de plugins. De eerste categorie wordt gedefinieerd en beheerd door het OSGi-framework. De tweede categorie zijn specifiek voor Eclipse en worden toegevoegd door runtimecode van Eclipse. Het oorspronkelijke pluginregister en bijbehorende objecten zijn dan ook onderverdeeld in OSGi-bundels en het Eclipse-extensieregister.

De IPluginRegistry-delen met betrekking tot de uitvoeringsspecificatie (zoals IPluginDescriptor, ILibrary en IPrequisite) zijn gedeprecieerd. De overige onderdelen met betrekking tot extensies en extensiepunten zijn naar IExtensionRegistry verplaatst. Bovendien zijn de "modelobjecten" met betrekking tot het pluginregister in zijn geheel gedeprecieerd. Dergelijke typen werden door de runtime hoofdzakelijk geïnstantieerd ter ondersteuning van tools als PDE. Helaas overschreden de benodigde gegevensniveaus vaak de grenzen van de voorzieningen van de runtime (zoals het onthouden van regelnummers voor plugin.xml-elementen). Uiteindelijk moest iedere gegevensaanvrager toch zelf een eigen structuur bijhouden van de runtimegegevens.

De runtimefaciliteiten zijn opnieuw onder de loep genomen, zodat alleen de essentiële voorzieningen voor runtime-uitvoering en uitzonderlijk ingewikkelde voorzieningen worden geboden. Zoals eerder beschreven, zijn de modelobjecten voor het pluginregister en de ontledings-API voor plugins gedeprecieerd. De extensiegegevens worden bijgehouden door het nieuwe extensieregister. Aan de hand van een nieuwe status (zie onder meer org.eclipse.osgi.service.resolver.State) kunnen essentiële uitvoeringsgegevens worden aangeduid en gemanipuleerd.

NL-fragmentstructuur

In Eclipse 3.0 is de NL-fragmentstructuur bijgewerkt en meer consistent gemaakt. In het verleden werd aangenomen dat de vertaling van bestanden als plugin.properties zich in JAR-bestanden zou bevinden die door fragmenten zouden worden verstrekt. De oorspronkelijke bestanden bevinden zich in de hoofdmap van de relevante hostplugin en daarom zou het consistenter zijn de vertaalde bestanden in de hoofdmap van de NL-fragmenten te plaatsen. Bijvoorbeeld

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

De vertalingen van plugin.properties zouden eerst zijn opgenomen in het bestand nl1.jar. Deze bestanden bevinden zich nu vooraan in het fragment en het JAR-bestand bevat de vertalingen van alle vertaalbare resources (dus bestanden die via de klassenlader worden geladen) in de hostplugin.

Natuurlijk wordt de NL-fragmentstructuur van Eclipse 2.1 nog steeds ondersteund voor 2.1-hostplugins die met Eclipse 3.0 worden uitgevoerd. U kunt echter geen NL-fragmenten van 2.1 gebruiken met een 3.0-plugin. U moet de fragmenten dan bijwerken naar de nieuwe structuur.

Overzicht van API-wijzigingen

org.eclipse.core.boot (pakket org.eclipse.core.boot)

Het volledige pakket org.eclipse.core.boot is gedeprecieerd. BootLoader is samengevoegd met rg.eclipse.core.runtime.Platform, omdat het onderscheid tussen het starten en de runtime niet langer nodig is. In feite is de plugin org.eclipse.core.boot uitgesplitst over de nieuwe runtime en de compatibiliteitslaag.

IPlatformConfiguration is altijd een type geweest dat door en voor het installeer-/bijwerkonderdeel van Eclipse is gedefinieerd. Omdat de runtime opnieuw is georganiseerd, kan aan het type een juiste bestemming worden gegeven. De klasse is vrijwel ongewijzigd en is opnieuw ingepakt als org.eclipse.update.configurator.IPlatformConfiguration.

IPlatformRunnable is verplaatst naar org.eclipse.core.runtime.IPlatformRunnable.

IExtension en IExtensionPoint (pakket org.eclipse.core.runtime)

De methode getDeclaringPlugin() (in beide klassen) verstrekt een opwaartse link naar de plugin waarmee de extensie of het extensiepunt worden gedeclareerd. Het nieuwe registermodel scheidt de uitvoeringsaspecten van plugins van de extensie-/extensiepuntaspecten en de API IPluginDescriptors is geschrapt. Het alternatief voor deze API is de nieuwe methode getParentIdentifier(), die u kunt vinden in zowel IExtension als IExtensionPoint.

ILibrary, IPluginDescriptor, IPluginRegistry en IPrerequisite (pakket org.eclipse.core.runtime)

In de oorspronkelijke runtime werd een volledig overzicht van de runtimeconfiguratie bijgehouden door het pluginregister. In Eclipse 3.0 is het overzicht verdeeld over het OSGi-framework en het extensieregister. Deze klassen zijn dan ook gedeprecieerd. In de depreciëringsmededelingen kunt u lezen hoe u de code kunt bijwerken.

Platform en Plugin (pakket org.eclipse.core.runtime)

In de nieuwe runtime worden Plugin-objecten niet langer beheerd door de runtime en kunnen deze niet op generieke wijze worden opgevraagd via het platform. Ook het pluginregister bestaat niet meer en geeft geen toegang meer tot plugindescriptors. Er zijn echter geschikte vervangende methoden beschikbaar, die in de Javadoc van de gedeprecieerde methoden uit deze klassen worden beschreven.

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

Alle typen van dit pakket zijn gedeprecieerd. Raadpleeg registers voor meer informatie.

IWorkspaceRunnable en IWorkspace.run (pakket org.eclipse.core.resources)

Het is voor clients van de methode IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) wellicht raadzaam over te stappen naar de geavanceerdere methode IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). De verouderde methode IWorkspace.run vergrendelt het hele werkgebied zolang IWorkspaceRunnable actief is. Bewerkingen van deze methode kunnen dus nooit samenvallen met andere bewerkingen voor het wijzigen van het werkgebied. In Eclipse 3.0 zijn veel langdurige bewerkingen naar achtergrond-threads verplaatst en is er een veel grotere kans dat er conflicten tussen bewerkingen optreden. Als een modale voorgrondbewerking wordt geblokkeerd door een langdurige achtergrondbewerking, is de gebruikersinterface pas weer beschikbaar zodra de achtergrondbewerking voltooid is of een van de bewerkingen wordt geannuleerd.

U kunt alle verwijzingen naar de verouderde methode IWorkspace.run omzetten naar de nieuwe methode en een planningsregelparameter instellen. De planningsregel moet de meest verfijnde regel zijn die de regels voor alle wijzigingen van de bewerking bevat. Als de bewerking resources buiten het bereik van de planningsregel probeert te wijzigen, treedt een runtime-uitzondering op. De exacte planningsregel voor bepaalde werkgebiedsbewerkingen is niet opgegeven en kan variëren afhankelijk van de geïnstalleerde repositoryprovider van een bepaald project. U kunt de factory IResourceRuleFactory gebruiken om de planningsregel op te halen van een bewerking waarmee een resource wordt gewijzigd. Zo nodig kunt u met MultiRule meerdere resourceregels opgeven en kunt u de regels van diverse resourcebewerkingen combineren met de methode MultiRule.combine.

Als een vergrendeling niet nodig is, kunt u de planningsregel null gebruiken. Zo kunnen alle resources van het werkgebied worden gewijzigd en kan het werkgebied gelijktijdig worden gewijzigd door andere threads. Deze oplossing is vaak het geschiktst voor eenvoudige wijzigingen aan het werkgebied.

IWorkbenchPage (pakket org.eclipse.ui)

IEditorDescriptor (pakket org.eclipse.ui)

ISharedImages (pakket org.eclipse.ui)

IWorkbenchActionConstants (pakket org.eclipse.ui)

IWorkbenchPreferenceConstants (pakket org.eclipse.ui)

IExportWizard (pakket org.eclipse.ui)

IImportWizard (pakket org.eclipse.ui)

INewWizard (pakket org.eclipse.ui)

WorkbenchHelp (pakket org.eclipse.ui.help)

IHelp (pakket org.eclipse.help)

ITextEditorActionConstants (pakket org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (pakket org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (pakket org.eclipse.ui.texteditor)

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

Extensiepunt annotationTypes (plugin org.eclipse.ui.editors)

Er is nu een expliciete notie van een annotatietype. Raadpleeg Annotation.getType() en Annotation.setType(). Het type van een annotatie kan tussendoor worden gewijzigd. Er is een nieuw extensiepunt toegevoegd voor het declareren van annotatietypen: org.eclipse.ui.editors.annotationTypes. Een annotatietype heeft een naam en kan worden gedeclareerd als een subtype van een ander gedeclareerd annotatietype. De declaratie van een annotatietype kan ook de kenmerken markerType en markerSeverity gebruiken om aan te geven dat merktekens van een bepaald type en een bepaald severity in teksteditors moeten worden aangeduid als annotaties van een bepaald annotatietype. Vermijd voortaan het gebruik van de kenmerken markerType en markerSeverity in org.eclipse.ui.editors.markerAnnotationSpecification. Annotaties van merktekens worden dan onafhankelijk van merktekens en de naam wordt misleidend. Bij de naam wordt rekening gehouden met compatibiliteit met eerdere versies.

Instances van subklassen van AbstractMarkerAnnotationModel herkennen de juiste annotatietypen automatisch en stellen deze ook in voor annotaties die van merktekens worden gemaakt. U kunt het annotatietype van een bepaald merkteken of een bepaald paar markertype/markerSeverity programmatisch ophalen met org.eclipse.ui.texteditor.AnnotationTypeLookup.

De toegang tot de hiërarchie van annotatietypen wordt verleend door IAnnotationAccessExtension. U kunt de keten van supertypen voor een bepaald annotatietype ophalen en controleren of een annotatietype een subtype van een ander annotatietype is. DefaultMarkerAnnotationAccess implementeert deze interface.

Extensiepunt markerAnnotationSpecification (plugin org.eclipse.ui.editors)

Het annotatietype is de sleutel voor het opsporen van de gekoppelde merktekenannotatie. Annotatietypen kunnen andere annotatietypen uitbreiden en daarom is er ook een impliciete relatie tussen specificaties van merktekenannotaties. Een merktekenannotatie voor een bepaald annotatietype wordt daarom voltooid door de specificaties van de merktekenannotaties die worden opgegeven voor de supertypen van het annotatietype. De merktekenannotatie hoeft niet langer compleet te zijn. De specificaties van merktekenannotaties kunnen worden opgehaald met AnnotationPreferences. Gebruik org.eclipse.ui.texteditor.AnnotationPreferenceLookup om de annotatievoorkeur op te halen voor een bepaald annotatietype dat de aanvulling van de voorkeur in de keten met annotatiesupertypen transparant uitvoert.

De specificatie van merktekenannotaties is uitgebreid met drie aanvullende kenmerken, waarmee u aangepaste presentaties voor bepaalde annotatietypen op de verticale liniaal kunt definiëren. De kenmerken zijn icon, symbolicIcon en annotationImageProvider. Voor icon gebruikt u het pad naar een pictogramafbeelding. Voor symbolicIcon kunt u kiezen uit "error", "warning", "info", "task" en "bookmark". Het kenmerk symbolicIcon wordt gebruikt om dezelfde afbeeldingen voor annotaties te laten gebruiken door het platform die ook worden gebruikt voor het afbeelden van fouten, waarschuwingen, informatieberichten, taken en bladwijzers. De waarde van annotationImageProvider is een klasse die org.eclipse.ui.texteditor.IAnnotationImageProvider implementeert, waarmee een volledig aangepaste annotatiepresentatie kan worden gemaakt.

De annotaties worden op de verticale liniaal getekend met behulp van IAnnotationAccess/IAnnotationAccessExtension. De methode Annotation.paint wordt niet langer aangeroepen door de verticale liniaal. Van annotaties wordt niet langer verwacht dat ze zichzelf tekenen. De methoden paint en getLayer zijn gedeprecieerd, zodat annotaties uiteindelijk onafhankelijk van de gebruikersinterface kunnen worden. DefaultMarkerAnnotationAccess fungeert als standaardimplementatie van IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementeert de volgende strategie voor het opbouwen van annotaties: Als IAnnotationPresentation wordt geïmplementeerd door een annotatie, wordt IAnnotationPresentation.paint aangeroepen. Anders wordt de afbeeldingsprovider van de annotatie opgezocht in de annotatievoorkeur. De afbeeldingsprovider is alleen beschikbaar als deze is opgegeven en als de plugin met de specificatie van de insluitende merktekenannotatie al geladen is. Als er een afbeeldingsprovider is, wordt de aanroep ernaar doorgestuurd. Anders wordt het opgegeven pictogram opgezocht. symbolicIcon wordt uiteindelijk gebruikt als geen enkel kenmerk is opgegeven. Voor het opbouwen van annotaties is de presentatielaag relevant. DefaultMarkerAnnotationAccess zoekt de presentatielaag als volgt op: Als de in de annotatievoorkeur een presentatielaag is opgegeven, wordt deze gebruikt. Als er geen laag is opgegeven en de annotatie IAnnotationPresentation implementeert, wordt IAnnotationPresentation.getLayer gebruikt. Anders wordt de standaardpresentatielaag (0) toegepast.

Migreren naar het extensiepunt annotationTypes (plugin org.eclipse.ui.editors)

De volgende annotatietypen worden gedeclareerd door de plugin org.eclipse.ui.editors:

   <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>

De kenmerken markerType en markerSeverity worden niet langer verstrekt door de gedefinieerde extensie markerAnnotationSpecification. Het kenmerk symbolicIcon wordt gedefinieerd met de bijbehorende waarde. MarkerAnnotation.paint en MarkerAnnotation.getLayer worden dus niet langer aangeroepen. Het overschrijven van deze methoden heeft dan ook geen effect. Clients moeten IAnnotationPresentation implementeren.

ILaunchConfigurationType (pakket org.eclipse.debug.core)

Met de komst van uitbreidbare startwerkstanden in 3.0 kunt u meer dan één startgemachtigde definiëren voor een startconfiguratietype. Vóór 3.0 werd slechts één gemachtigde per type ondersteund. De methode ILaunchConfigurationType.getDelegate() is gedeprecieerd. Gebruikt voortaan de methode getDelegate(String mode) om de startgemachtigde van een bepaalde startwerkstand op te halen. De gedeprecieerde methode is gewijzigd en geeft nu de startgemachtigde van de werkstand run als resultaat.

ILaunchConfigurationTab en ILaunchConfigurationTabGroup (pakket org.eclipse.debug.ui)

Starttabgroepen en starttabs worden niet meer geïnitieerd wanneer een startbewerking voltooid is. De methode launched(ILaunch) in de interfaces ILaunchConfigurationTab en ILaunchConfigurationTabGroup is gedeprecieerd en wordt niet langer aangeroepen. Deze methode is altijd al onbetrouwbaar geweest, omdat tabs alleen bestaan wanneer een startbewerking vanuit het startdialoogvenster wordt uitgevoerd. Bovendien kan deze methode met de komst van starten op de achtergrond niet langer worden aangeroepen, omdat het startdialoogvenster wordt gesloten voordat het resulterende startobject is gemaakt.

ILaunchConfigurationTab en AbstractLaunchConfigurationTab (pakket org.eclipse.debug.ui)

Er zijn twee methoden toegevoegd aan de interface ILaunchConfigurationTab voor activering en deactivering. De nieuwe levenscyclusmethoden worden aangeroepen zodra een tab wordt geopend en verlaten. Bestaande implementaties van ILaunchConfigurationTab waarmee de abstracte klasse uit de foutopsporingsplugin (AbstractLaunchConfigurationTab) als subklasse wordt gebruikt, zijn binair compatible omdat de methoden in de abstracte klasse zijn geïmplementeerd.

In eerdere releases werd het bericht initializeFrom naar een tab gestuurd bij activering en performApply bij deactivering. Zo was communicatie tussen tabs mogelijk via een startconfiguratie (door de configuratie bij te werken met de huidige kenmerkwaarden bij het verlaten van een tab en de nieuw geopende tab bij te werken). Deze techniek kan inefficiënt zijn omdat veel tabs geen onderlinge communicatie hanteren. Bovendien kan niet worden vastgesteld welke tab wordt geactiveerd en welke tab een geselecteerde startconfiguratie voor het eerst afbeeldt. De toegevoegde methoden maken het voor tabs mogelijk een onderscheid te maken tussen activering en initialisatie en deactivering en het opslaan van waarden.

De standaardimplementatie van activated, die verstrekt wordt door de abstracte tab, roept initializeFrom aan. De standaardimplementatie van deactivated roept performApply aan. Tabs die de nieuwe API willen benutten, kunnen de methoden zo nodig vervangen. Over het algemeen kunt u voor tabs zonder onderlinge communicatie de methoden zodanig opnieuw implementeren dat ze geen actie uitvoeren.

Extensiepunt launchConfigurationTabGroup (pakket org.eclipse.debug.ui)

In eerdere releases werd perspectiefomschakeling opgegeven voor een startconfiguratie met behulp van de startconfiguratiekenmerken ATTR_TARGET_DEBUG_PERSPECTIVE en ATTR_TARGET_RUN_PERSPECTIVE. Met Met de komst van uitbreidbare startwerkstanden in 3.0 is deze aanpak niet langer gepast. U kunt perspectieven nu opgeven per startconfiguratietype, per startwerkstand die door het type wordt ondersteund. Er is API toegevoegd aan DebugUITools voor het instellen en ophalen van het perspectief dat aan het startconfiguratietype van een bepaalde startwerkstand is gekoppeld.

Het aanvullende, optionele, element launchMode is ook beschikbaar in het extensiepunt launchConfigurationTabGroup, zodat u voor een aangeleverde tabgroep een standaardperspectief kunt opgeven voor een startconfiguratietype en startwerkstand.

Vanuit de Eclipse-gebruikersinterface kan het aan een startconfiguratietype gekoppelde perspectief worden bewerkt door het dialoogvenster met startconfiguraties te openen en het knooppunt (geen afzonderlijke configuratie) te selecteren in de lijst. Er wordt een tab afgebeeld waarmee een perspectief kan worden ingesteld voor elke ondersteunde startwerkstand.

[Alleen JDT] IVMRunner (pakket org.eclipse.jdt.launching)

Er zijn twee methoden toegevoegd aan de klasse VMRunnerConfiguration voor het instellen en ophalen van omgevingsvariabelen. Implementors van IVMRunner moeten VMRunnerConfiguration.getEnvironment() aanroepen en de omgeving doorgeven aan de uitgevoerde JVM. Clients die DebugPlugin.exec(String[] cmdLine, File workingDirectory) gebruiken, kunnen hiervoor DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) aanroepen. Het volstaat om alleen het resultaat van getEnvironment() door te geven.

[Alleen JDT] Klassen VMRunnerConfiguration en Bootstrap (pakket org.eclipse.jdt.launching)

In eerder releases werd het opstartpad van VMRunnerConfiguration met slechts één kenmerk beschreven. Het kenmerk is een verzameling Strings die kunnen worden opgegeven met de parameter -Xbootclasspath. Er zijn drie nieuwe kenmerken toegevoegd aan VMRunnerConfiguration, zodat ook ondersteuning wordt geboden voor JVM's die kunnen omgaan met opstartpaden met pre- of suffixen. De nieuwe methoden/kenmerken zijn:

Het verouderde kenmerk getBootClassPath() bestaat nog steeds en bevat het volledige pad dat gelijk is aan het pad van de drie nieuwe kenmerken. VMRunners die de nieuwe opstartpadopties ondersteunen, kunnen deze extra functionaliteit benutten.

[Alleen JDT] Verbeterde ondersteuning voor werkende exemplaren (pakket org.eclipse.jdt.core)

De voorziening voor werkende exemplaren van het Java-model is gereviseerd in 3.0 voor sterk verbeterde functionaliteit. Vóór 3.0 konden in het Java-model alleen afzonderlijke werkende exemplaren van compilatie-eenheden worden gemaakt. Wijzigingen konden worden aangebracht en vervolgens worden vastgelegd. Er waren beperkte analysemogelijkheden voor werkende exemplaren in de context van de rest van het Java-model. Het analyseren van meerdere werkende exemplaren tegelijk was echter niet mogelijk.

De wijzigingen in 3.0 maken het mogelijk sets werkende exemplaren van compilatie-eenheden te maken en te beheren en alle werkende exemplaren uit de set te analyseren. U kunt nu bijvoorbeeld werkende exemplaren maken voor een of meer compilatie-eenheden die gewijzigd worden en vervolgens typeverwijzingen omzetten tussen de werkende exemplaren. In het verleden was dit alleen mogelijk nadat de wijzigingen aan de werkende exemplaren van de compilatie-eenheden waren vastgelegd.

De API van het Java-model is op twee manieren gewijzigd om deze verbeterde ondersteuning te kunnen toepassen:

(1) De functionaliteit die vroeger was opgenomen in IWorkingCopy en overgenomen werd door ICompilationUnit is samengevoegd in ICompilationUnit. De interface IWorkingCopy werd alleen hier gebruikt en was van algemenere aard dan nodig. De API is door de wijziging vereenvoudigd. IWorkingCopy is gedeprecieerd. Andere plekken in de API waar IWorkingCopy als parameter of resultaattype werd gebruikt, zijn ook gedeprecieerd. De vervangende API-methoden hebben betrekking op ICompilationUnit en niet op IWorkingCopy.

(2) De interface IBufferFactory is vervangen door WorkingCopyOwner. De verbeterde ondersteuning voor werkende exemplaren vereist één object voor het beheren van de exemplaren. Aan de naam van IBufferFactory valt niet echt af te leiden hoe het mechanisme van werkende exemplaren functioneert. WorkingCopyOwner is wellicht duidelijker. Bovendien wordt WorkingCopyOwner gedeclareerd als abstracte klasse en niet als interface, zodat de beheerder van het werkende exemplaar kan worden doorontwikkeld. De methode van IBufferFactory is onveranderd naar WorkingCopyOwner verplaatst. WorkingCopyOwner implementeert IBufferFactory niet om aan te duiden dat IBufferFactory verouderd is. IBufferFactory is gedeprecieerd. Andere plekken in de API waar IBufferFactory als parameter of resultaattype werd gebruikt, zijn ook gedeprecieerd. De vervangende API-methoden hebben betrekking op WorkingCopyOwner en niet op IBufferFactory.

De binaire compatibiliteit wordt niet beïnvloed door de wijzigingen.

Zorg ervoor dat alle verwijzingen naar het type IWorkingCopy bij het migreren naar ICompilationUnit verwijzen. De enige implementatie van IWorkingCopy implementeert ICompilationUnit ook, zodat objecten van het type IWorkingCopy probleemloos kunnen worden omgezet in ICompilationUnit.

Klassen die IBufferFactory implementeren, moeten worden vervangen door subklassen van WorkingCopyOwner. Hoewel WorkingCopyOwner niet IBufferFactory implementeert, kan de subklasse van WorkingCopyOwner ter implementatie van IBufferFactory worden gedeclareerd. Zo wordt een brug gemaakt tussen de oude en de nieuwe interface. (IBufferFactory declareert createBuffer(IOpenable) terwijl WorkingCopyOwner createBuffer(ICompilationUnit) declareert; ICompilationUnit breidt IOpenable uit.)

Omdat de wijzigingen met betrekking tot IWorkingCopy en IBufferFactory met elkaar in verband staan, is het raadzaam beide tegelijk te verwerken. De gegevens van de depreciëringen luiden als volgt:

Herstructurering van plugin org.eclipse.help

De plugin org.eclipse.help, waarin eerder API's en extensiepunten waren opgenomen voor het aanleveren aan en het uitbreiden van het Help-systeem en het afbeelden van Help, bevat nu uitsluitend API's en extensiepunten voor het aanleveren aan en opvragen van Help-resources. Een gedeelte van de standaardimplementatie van de Help-gebruikersinterface uit de plugin is verplaatst naar de nieuwe plugin org.eclipse.help.base, samen met API's voor het uitbreiden van de implementatie. De API's en extensiepunten voor het aanleveren van de Help-gebruikersinterface en het afbeelden van Help zijn verplaatst naar de plugin org.eclipse.ui. Deze herstructurering geeft toepassingen meer flexibiliteit op het gebied van het Help-systeem. Door de nieuwe structuur kunnen toepassingen die gebaseerd zijn op de generieke workbench zelf Help-gebruikersinterface en/of Help-implementatie aanleveren of het Help-systeem volledig overslaan.

Omdat de extensiepunten en API-pakketten alleen voor gebruik door het Help-systeem zelf zijn bestemd, is het onwaarschijnlijk dat bestaande plugins worden beïnvloed door de wijziging. Ze worden hier alleen vermeld voor de volledigheid:

Nieuwe API voor zoekgebruikersinterface

In 3.0 is een nieuwe API toegevoegd voor het implementeren van aangepaste zoekopdrachten. De oorspronkelijke API is gedeprecieerd in 3.0 en conversie naar de nieuwe API in de pakketten org.eclipse.search.ui en org.eclipse.search.ui.text wordt aanbevolen.

Door clients moeten implementaties worden gemaakt van ISearchQuery, ISearchResult en ISearchResultPage. De implementatie van ISearchResultPage moet vervolgens worden aangeleverd voor het nieuwe extensiepunt org.eclipse.search.searchResultViewPages.

De standaardimplementaties van ISearchResult en ISearchResultPage worden verstrekt in het pakket org.eclipse.search.ui.text.

null-berichten in MessageBox en DirectoryDialog (pakket org.eclipse.swt.widgets)

Vóór 3.0 werd een dialoogvenster met een tekstloze titel afgebeeld wanneer DirectoryDialog.setMessage(String string) of MessageBox.setMessage(String string) van SWT werd aangeroepen met een null-waarde voor de string-parameter. Dit gedrag was niet-gespecificeerd (het doorgeven van null is nooit toegestaan) en levert problemen op met getMessage, omdat deze methode niet null als resultaat mag geven. In 3.0 wordt de uitzondering llegalArgumentException verworpen wanneer null wordt doorgegeven. In de specificaties wordt hier eveneens rekening mee gehouden en is de methode op één lijn met de methode van de superklasse Dialog.setMessage. Gebruikt u Dialog.setMessage, denk er dan aan dat de doorgegeven tekenreeks niet null mag zijn. Geef een lege tekenreeks door als u een dialoogvenster zonder titel wilt afbeelden.

Verbeterde modale voortgangsfeedback

Voor het ondersteunen van gelijktijdige bewerkingen zijn meer geavanceerde manieren voor het afbeelden van modale voortgang nodig. In de klasse IProgressService is aanvullende voortgangsondersteuning geïmplementeerd. De bestaande manier voor het afbeelden van voortgang met ProgressMonitorDialog is nog steeds beschikbaar. Voor een verbeterde gebruikerservaring is het wellicht een goed idee over te stappen naar IProgressService.

In het document Showing Modal Progress in Eclipse 3.0 vindt u meer uitleg over het migreren naar IProgressService.

Foutopsporingsactiegroepen verwijderd

Het extensiepunt org.eclipse.debug.ui.debugActionGroups is verwijderd. In Eclipse 3.0 is workbenchondersteuning voor activiteiten toegevoegd via het extensiepunt org.eclipse.platform.ui.activities. Dit ondersteuning biedt dezelfde functionaliteit en is eenvoudiger in het gebruik. (U kunt patronen opgeven in plaats van losse acties). Bovendien biedt het extensiepunt programmatische API. Er treden geen fouten op als verwijzingen naar het extensiepunt niet worden verwijderd. De verwijzingen worden simpelweg genegeerd. Productverkopers wordt aangeraden de workbenchondersteuning voor activiteiten te benutten, zodat taalspecifieke foutopsporingsacties aan taalspecifieke activiteiten kunnen worden gekoppeld. (U kunt foutopsporingsacties van C++ wellicht koppelen aan de activiteit "C++ ontwikkelen".)

Mogelijkheid tot uitschakelen van BreakpointManager

Aan IBreakpointManager zijn de methoden setEnabled(boolean) en isEnabled() toegevoegd. Alle geregistreerde onderbrekingspunten worden door foutopsporingsprogramma's genegeerd wanneer de onderbrekingspuntmanager is uitgeschakeld. Bovendien levert het foutopsporingsplatform een nieuw listener-mechanisme, IBreakpointManagerListener, waarmee clients met de onderbrekingspuntmanager kunnen worden geregistreerd om te reageren op de status van de manager. De view Onderbrekingspunten roept deze API aan met een nieuwe afwisselend activeerbare actie: "Alle onderbrekingspunten overslaan". De foutopsporingsprogramma's die de status van de onderbrekingspuntmanager niet in acht nemen, kunnen problemen geven als de feature wordt opgevraagd.

[Alleen JDT] Java-zoekdeelnemers (pakket org.eclipse.jdt.core.search)

Aan Java verwante talen (zoals JSP, SQLJ, JWS, enz.) moeten ook beschikbaar kunnen zijn voor Java-zoekopdrachten. Voor de implementors van de talen geldt vooral het volgende:

Een dergelijke implementor wordt een zoekdeelnemer genoemd. De klasse SearchParticipant wordt ermee uitgebreid. Zoekdeelnemers worden doorgegeven aan zoekquery's (zie SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).

Voor het indexeren of opsporen van overeenkomsten moeten zoekdeelnemers een subklasse definiëren van SearchDocument, waarmee de inhoud van het document kan worden opgehaald door getByteContents() of getCharContents() te vervangen. Een instance van deze subklasse wordt als resultaat gegeven in getDocument(String).

Zoekdeelnemers kunnen het indexeren van het opgegeven document in de opgegeven index plannen met SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath). Zodra het document gereed is voor indexering, wordt SearchParticipant.indexDocument(SearchDocument, IPath) aangeroepen door het onderliggende framework. De zoekdeelnemer haalt vervolgens de inhoud van het document op, ontleedt deze en voegt indexvermeldingen toe met behulp van SearchDocument.addIndexEntry(char[], char[]).

Nadat het indexeren is voltooid, kunnen query's worden uitgevoerd op de indexen en kunnen overeenkomsten worden opgespoord met behulp van SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Eerst wordt elke zoekdeelnemer naar de benodigde indexen gevraagd via SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). Voor elke indexvermelding die met het opgegeven patroon overeenkomt, wordt een zoekdocument gemaakt door de zoekdeelnemer te ondervragen (zie getDocument(String)). Alle documenten worden doorgegeven aan de zoekdeelnemer, zodat overeenkomsten kunnen worden opgespoord via locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). De zoekdeelnemer initieert SearchRequestor door acceptSearchMatch(SearchMatch) te gebruiken en een instance van een subklasse van SearchMatch door te geven.

Een zoekdeelnemer kan een gedeelte van de taken delegeren aan de standaard Java-zoekdeelnemer. Een instance van deze standaarddeelnemer kan worden opgehaald via SearchEngine.getDefaultSearchParticipant(). Als een SQLJ-deelnemer bijvoorbeeld wordt gevraagd overeenkomsten op te sporen, kan deze JAVA-documenten maken van de SQLJ-documenten en de taken delegeren aan de standaarddeelnemer met doorgifte van de JAVA-documenten.