Deze sectie bevat de wijzigingen die u moet doorvoeren voordat de 2.1-plugins geschikt zijn voor de 3.0-methoden en API's.
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.
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.
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:
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.
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.
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.
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.
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.
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.
Alle typen van dit pakket zijn gedeprecieerd. Raadpleeg registers voor meer informatie.
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.
filteredSelection
op te halen uit selection
: IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
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.
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.
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.
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.
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.
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.
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.
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.
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:
getPrependBootClassPath()
- geeft een verzameling ingangen voor toevoeging vóór het opstartpad (parameter -Xbootclasspath/p
) getMainBootClassPath()
- geeft een verzameling ingangen voor plaatsing in het opstartpad (parameter -Xbootclasspath
) getAppendBootClassPath()
- geeft een verzameling ingangen voor toevoeging achter het opstartpad (parameter -Xbootclasspath/a
) 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.
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:
IWorkingCopy
(pakket org.eclipse.jdt.core
) public void commit(boolean, IProgressMonitor)
is gedeprecieerd. ICompilationUnit
:
public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
als ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
. public void destroy()
is gedeprecieerd. ICompilationUnit
:
public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
als ((ICompilationUnit)
wc).discardWorkingCopy()
. public IJavaElement findSharedWorkingCopy(IBufferFactory)
is gedeprecieerd. ICompilationUnit
:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
vervangt IBufferFactory
. public IJavaElement getOriginal(IJavaElement)
is gedeprecieerd. IJavaElement
: public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
als elt.getPrimaryElement()
. IWorkingCopy.getOriginal
geeft IJavaElement.getPrimaryElement
niet null
als resultaat wanneer de ontvanger geen werkend exemplaar is. public IJavaElement getOriginalElement()
is gedeprecieerd. ICompilationUnit
:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
als ((ICompilationUnit)
wc).getPrimary()
. IWorkingCopy.getOriginalElement
geeft IWorkingCopy.getPrimary
niet null
als resultaat wanneer de ontvanger geen werkend exemplaar is. public IJavaElement[] findElements(IJavaElement)
is gedeprecieerd. ICompilationUnit
. wc.findElements(elts)
als ((ICompilationUnit)
wc).findElements(elts)
. public IType findPrimaryType()
is gedeprecieerd. ICompilationUnit
. wc.findPrimaryType()
als ((ICompilationUnit)
wc).findPrimaryType()
. public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
is gedeprecieerd. ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
vervangt IBufferFactory
. public IJavaElement getWorkingCopy()
is gedeprecieerd. ICompilationUnit
:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
als ((ICompilationUnit)
wc).getWorkingCopy(null)
. public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
is gedeprecieerd. ICompilationUnit
:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
vervangt IBufferFactory
. public boolean isBasedOn(IResource)
is gedeprecieerd. ICompilationUnit
:
public boolean hasResourceChanged()
wc.isBasesOn(res)
als ((ICompilationUnit)
wc).hasResourceChanged()
. public boolean isWorkingCopy()
is gedeprecieerd. ICompilationUnit
. wc.isWorkingCopy()
als ((ICompilationUnit)
wc).isWorkingCopy()
. public IMarker[] reconcile()
is gedeprecieerd. ICompilationUnit
:
public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
als ((ICompilationUnit)
wc).reconcile(false, null)
. null
; de vervangende methode geeft geen resultaat. public void reconcile(boolean, IProgressMonitor)
is gedeprecieerd. ICompilationUnit
. wc.reconcile(b,monitor)
als ((ICompilationUnit)
wc).reconcile(b.monitor)
. public void restore()
is gedeprecieerd.
ICompilationUnit
. wc.restore()
als ((ICompilationUnit)
wc).restore()
. IType
(pakket org.eclipse.jdt.core
) public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
is gedeprecieerd. public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
wordt omgezet in ICompilationUnit[]
. public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
is gedeprecieerd. public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
wordt omgezet in ICompilationUnit[]
. IClassFile
(pakket org.eclipse.jdt.core
) public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
is gedeprecieerd. public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
vervangt IBufferFactory
. JavaCore
(pakket org.eclipse.jdt.core
) public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
is gedeprecieerd. public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
vervangt IBufferFactory
. ICompilationUnit[]
wordt omgezet in IWorkingCopy[]
. SearchEngine
(pakket org.eclipse.jdt.core.search
) public SearchEngine(IWorkingCopy[])
is gedeprecieerd. public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
wordt omgezet in ICompilationUnit[]
. 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:
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
.
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.
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.
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".)
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.
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.