I det här avsnittet beskrivs de ändringar som krävs när du ändrar ditt insticksprogram från version 2.1 till mekanismerna och API:erna i version 3.0.
Eclipse 3.0-runtimemodulen är helt annorlunda. Den underliggande implementeringen är baserad på OSGi-ramverksspecifikation. Eclipse 3.0-runtimemodulen inkluderar ett kompatibilitetslager (i insticksprogrammet org.eclipse.core.runtime.compatibility) som underhåller version 2.1 API:erna. De utvecklare av insticksprogram som vill förbättra prestanda och funktionalitet bör överväga att använda API:erna i version 3.0 och få bort beroendet av kompatibilitetslagret. Kompatibilitetskod syns på tre platser:
I texten nedan finns mer information om vilka klasser och metoder som finns i kompatibilitetssyfte och som ledning för hur du uppdaterar insticksprogrammet.
Eclipse runtimemodul har omfaktorerats i två delar: laddning av klasser och obligatorisk hantering samt utökning/utökningspunkthantering. Uppdelningen gör det möjligt med ett naturligt/smidigt införande av OSGi-ramverksspecifikation för laddning av klasser och obligatorisk hantering. Detta ger i sin tur en uppsättning nya möjligheter i runtimemodulen från dynamisk installation/uppdatering/avinstallation av insticksprogram till säkerhet och ökade konfigurationsmöjligheter.
Även om vi fortsätter att tala om insticksprogram, är ett insticksprogram i den nya runtimemodulen i själva verket ett samlingspaket med några utökningar och utökningspunkter. Termen samlingspaket definieras av OSGi:s ramverksspecifikation och hänvisar till en samling typer och resurser och associerad obligatorisk information mellan samlingspaket. Utökningsregistret är en ny form av insticksprogramregistret och innehåller endast information om utökningar och utökningspunkter. Generellt är utökningsregister-API:et samma som motsvarande insticksprogramregister-API (mer information finns i Register).
I Eclipse 2.x-runtimemodulen har insticksprogramobjektet ett antal roller och ansvarsområden:
I Eclipse 3.0-runtimebilden har dessa roller och ansvarsområden faktorerats till distinkta objekt.
Plugin-klassen implementerar även BundleActivator. Du behöver endast ha ett centralt objekt som representerar livscykeln och semantiken i ett insticksprogram. Observera att detta inte sanktionerar initieringen av datastrukturer, något som är vanligt i insticksprogram idag. Vi kan inte nog understryka att insticksprogram kan aktiveras på grund av att en perifer klass refererades vid klassverifiering i något annat insticksprogram. Bara för att ditt insticksprogram har aktiverats betyder det inte nödvändigtvis att dess funktion behövs. Du kan även definiera en annan BundleActivator-klass eller välja att inte ha någon aktiveringsnyckel alls.
Vilka steg som krävs för att porta en 2.x Plugin-klass till Eclipse 3.0 beror på vad klassen utför. Enligt ovan passar den största delen av livscykelarbetet vid start i en av följande kategorier:
I den nya runtimemodulen är det skillnad på den information och de strukturer som krävs för att ett insticksprogram ska kunna köras samt det som är relaterat till insticksprogrammets utökningar och utökningspunkter. Den förra definieras och hanteras av OSGi-ramverksspecifikationen. Den senare är Eclipse-specifika koncept och läggs till av Eclipse-runtimekod. Det ursprungliga insticksprogramregistret och relaterade objekt har alltså delats upp på OSGi-samlingspaket och Eclipse-utökningsregister.
De delar av IPluginRegistry som hanterar körningsspecifikation (till exempel IPluginDescriptor, ILibrary, IPrequisite) har utkommenterats och de resterande delarna som är relaterade till utökningar och utökningspunkter har flyttats till IExtensionRegistry. Dessutom har så kallade modellobjekt som är relaterade till insticksprogramregistret som helhet nu utkommenterats. Typerna presenterades och instantierades av runtimemodulen, framförallt för att kunna hantera verktyg, till exempel PDE. Tyvärr överskred informationsmängden runtimemodulens möjligheter (till exempel att hålla reda på radnummer för element i plugin.xml). I slutändan fick potentiella användare av runtimemodulens information upprätthålla sina egna strukturer ändå.
I den nya runtimemodulen har vi omvärderat de möjligheter som ges av runtimemodulen och erbjuder nu endast de som antingen krävs för runtimekörning eller som är svåra att utföra för andra. Enligt ovan har modellobjekten i insticksprogramregistret utkommenterats. Det har även insticksprogrammets tolk-API. Det nya utökningsregistret underhåller nödvändig utökningsrelaterad information. En ny tillståndsstruktur (se org.eclipse.osgi.service.resolver.State och väninsticksprogram) representerar och tillåter manipulationen av nödvändig körrelaterad information.
I Eclipse 3.0 har NL-fragmentstrukturen uppdaterats för bättre konsekvens. Tidigare antogs översättningar av filer, till exempel plugin.properties, göras i JAR-filer som tillhandahölls av fragment. Eftersom originalfilerna finns i roten hos motsvarande värdinsticksprogram blir konsekvensen större om de översatta filerna placeras i NL-fragmentets rot. Exempel:
org.eclipse.ui.workbench.nl/ fragment.xml plugin_fr.properties plugin_pt_BR.properties ... nl1.jar
Observera att filen nl1.jar tidigare innehöll översättningarna för plugin.properties. Dessa filer finns nu i fragmentets rot och JAR-filen innehåller översättningar av alla resurser som går att översätta (dvs. filer som läses in via klassinläsaren) i värdinsticksprogrammet.
Självklart stöds fortfarande NL-fragmentstrukturen i Eclipse 2.1 för 2.1-värdinsticksprogram som körs i Eclipse 3.0. Du kan däremot inte använda ett NL-fragment från version 2.1 i ett 3.0-insticksprogram. Fragmentet måste uppdateras till den nya strukturen.
Hela org.eclipse.core.boot-paketet har utkommenterats. BootLoader har slagits samman med org.eclipse.core.runtime.Platform eftersom det inte längre finns någon orsak att dela upp koden mellan start och runtime. Observera att insticksprogrammet org.eclipse.core.boot har delats upp och att all kod har flyttats till antingen den nya runtimemodulen eller till kompatibilitetslagret.
IPlatformConfiguration har alltid varit en typ som definierats av och för installations- och uppdateringskomponenten i Eclipse. I och med omorganisationen av runtimemodulen har vi haft möjlighet att flytta typen dit den hör hemma. Klassen är i stort oförändrad och har packats om som org.eclipse.update.configurator.IPlatformConfiguration.
IPlatformRunnable har flyttats till org.eclipse.core.runtime.IPlatformRunnable.
getDeclaringPlugin()
-metoden (i båda klasserna) ger en uppåtlänk till
insticksprogrammet som deklarerar utökningen eller utökningspunkten (var för sig).
Den nya registermodellen separerar körningsaspekterna i insticksprogrammet från
utöknings-/utökningspunktaspekterna och innehåller inte längre IPluginDescriptors.
De som använder detta API bör överväga att i stället använda den nya metoden getParentIdentifier(), som finns i både
IExtension och IExtensionPoint.
I den ursprungliga runtimemodulen underhöll insticksprogramregistret en fullständig bild av runtime-konfigurationen. I Eclipse 3.0 har denna bild delats upp mellan OSGi-ramverket och utökningsregistret. Därför har dessa klasser utkommenterats. I kommentaren finns information om hur du bör uppdatera koden.
I den nya runtimemodulen hanteras inte längre Plugin-objekt av runtimemodulen och kan därför inte accessas generellt via plattformen. På liknande sätt finns inte insticksprogramregistret eller så kan det inte ge access till insticksprogrambeskrivare. Det finns dock lämpliga ersättningsmetoder tillgängliga som beskrivs i Javadoc för de utkommenterade metoderna i dessa klasser.
Alla typer i detta paket har nu kommenterats ut. Mer information finns i avsnittet om register.
Klienter av IWorkspace.run(IWorkspaceRunnable,IProgressMonitor)-metoden bör omvärdera användningen av denna metod och överväga att använda den funktionsrikare metoden IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor). Den gamla IWorkspace.run-metoden låser hela arbetsytan under tiden IWorkspaceRunnable körs. Detta betyder att en åtgärd som utförs med denna metod aldrig kan köras samtidigt med andra åtgärder som ändrar arbetsytan. I Eclipse 3.0 har flera åtgärder som tar lång tid flyttats till bakgrundstrådar. Det innebär att risken för konflikter mellan åtgärderna har ökat. Om en modal förgrundsåtgärd blockeras av en bakgrundsåtgärd som tar lång tid, blir användargränssnittet blockerat tills bakgrundsåtgärden slutförs eller tills någon av åtgärderna avbryts.
Den rekommenderade lösningen är att ändra alla referenser till den gamla IWorkspace.run
så att de i stället använder den nya metoden, som har en parameter för schemareglering. Schemaregeln
bör vara den noggrannaste regeln som omfattar reglerna för alla ändringar av den åtgärden. Om åtgärden försöker modifiera resurser utanför omfånget hos schemaregeln returneras ett runtime-undantagsfel. Den exakta schemaregeln
som krävs av en åtgärd på arbetsytan anges inte och kan ändras beroende på
den installerade datalagerprovidern för ett visst projekt. Fabriken
IResourceRuleFactory
bör användas när du hämtar schemaregeln
för en åtgärd som ändrar resurser. Om det behövs kan du använda MultiRule och ange
flera resursregler. Använd MultiRule.combine-metoden
om du vill kombinera regler från olika åtgärder som ändrar resurser.
Om ingen låsning krävs kan du använda en schemaregel som är null. Detta tillåter koden som kör att modifiera alla resurser på arbetsytan, men förhindrar inte andra trådar från att modifiera arbetsytan samtidigt. För enkla ändringar av arbetsytan är detta oftast den enklaste och bästa lösningen.
filteredSelection
ur 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())); }
Det finns nu ett explicit begrepp av en anteckningstyp. Se Annotation.getType() och Annotation.setType(). Anteckningstypen kan ändras under dess livstid. En ny utökningspunkt har lagts till för deklarationen av anteckningstyper: org.eclipse.ui.editors.annotationTypes. En anteckningstyp har ett namn och kan deklareras som en undertyp till en annan deklarerad anteckningstyp. En deklaration av en anteckningstyp kan också använda attributen "markerType" och "markerSeverity" för att ange att markörer av en viss typ och angiven allvarlighetsnivå bör representeras i textredigerare som anteckningar av en viss anteckningstyp. Attributen "markerType" och "markerSeverity" i "org.eclipse.ui.editors.markerAnnotationSpecification" bör inte användas mer. Specifikationer av marköranteckningar blir på så vis oberoende från markörer och namnet är därför vilseledande. Namnet behålls dock för att bakåtkompatibiliteten ska garanteras.
Förekomster av underklasser till AbstractMarkerAnnotationModel upptäcker och anger automatiskt rätt anteckningstyper som de skapar från markörer. För att kunna hämta anteckningstypen i programkod för en angiven markör eller ett angivet markerType- och markerSeverity-par använder du org.eclipse.ui.texteditor.AnnotationTypeLookup.
Access till anteckningstypshierarkin tillhandahålls av IAnnotationAccessExtension. För en anteckningstyp kan du få en kedja med överordnade typer och kontrollera om en anteckningstyp är en undertyp till en annan anteckningstyp. DefaultMarkerAnnotationAccess implementerar detta gränssnitt.
Anteckningstypen är nyckeln som du använder när du söker efter den associerade specifikationen för marköranteckningen. Eftersom anteckningstyper kan utöka andra anteckningstyper finns det också ett tydligt samband mellan specifikationer för marköranteckningar. Därför är en sådan specifikation för en viss anteckningstyp avslutad med specifikationen för de överordnade typerna för den angivna anteckningstypen. Specifikationen för marköranteckningen måste inte vara komplett, vilket förut var fallet. Specifikationer för marköranteckningar hämtas av AnnotationPreferences. Genom att använda org.eclipse.ui.texteditor.AnnotationPreferenceLookup kan du hämta en anteckningsinställning för en angiven anteckningstyp som transparent utför slutförandet av inställningen efter anteckningens överordnade typkedja.
Specifikationer för marköranteckningar har utökats med tre attribut, vilket gör det möjligt att definiera anpassade utseenden för angivna anteckningstyper i den vertikala linjalen. Attributen är: "icon", "symbolicIcon" och "annotationImageProvider". Värdet på "icon" är sökvägen till en fil som innehåller ikonbilden. Värdet på "symbolicIcon" kan vara ett av "error", "warning", "info", "task" eller "bookmark". Attributet "symbolicIcon" talar om för plattformen att anteckningen ska avbildas med samma bild som används på plattformen för att representera fel, varningar, informationsmeddelanden, uppgifter och bokmärken. Värdet på "annotationImageProvider" är en klass som implementerar org.eclipse.ui.texteditor.IAnnotationImageProvider, som tillåter en fullständigt anpassad anteckningspresentation.
Den vertikala linjalen använder den associerade IAnnotationAccess/IAnnotationAccessExtension för att rita upp anteckningar. Den vertikala linjalen anropar inte Annotation.paint längre. I allmänhet förväntas inte anteckningarna rita upp sig själva. Metoderna "paint" och "getLayer" har utkommenterats för att göra anteckningarna användargränssnittsoberoende. DefaultMarkerAnnotationAccess fungerar som en standardimplementation av IAnnotationAccess/IAnnotationAccessExtension. DefaultMarkerAnnotationAccess implementerar följande strategi för ritning av anteckningar: Om en anteckning implementerar IAnnotationPresentation anropas IAnnotationPresentation.paint. I annat fall letas anteckningsbildprovidern upp i anteckningsinställningarna. Anteckningsbildprovidern är endast tillgänglig om den har angetts och om insticksprogrammet som definierar den omslutande marköranteckningsspecifikationen redan har lästs in. Om det finns en anteckningsbildprovider skickas anropet vidare dit. Om inte, letas den angivna "icon" upp. Attributet "symbolicIcon" används som den sista åtgärden. Vid ritning av anteckningar är presentationslagret för anteckningar relevant. DefaultMarkerAnnotationAccess söker efter presentationslagret med följande strategi: Om anteckningsinställningarna anger ett presentationslager används det angivna lagret. Om det inte finns något lager och anteckningen implementerar IAnnotationPresentation används IAnnotationPresentation.getLayer. I annat fall returneras standardpresentationslagret (vilket är 0).
Följande anteckningstyper deklareras av insticksprogrammet 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>
Den definierade utökningen markerAnnotationSpecification tillhandahåller inte längre attributen "markerType" och "markerSeverity". De definierar attributet "symbolicIcon" med motsvarande värde. Därför anropas inte MarkerAnnotation.paint och MarkerAnnotation.getLayer längre. Det innebär att inget händer om du försöker åsidosätta metoderna. Klienter som påverkas bör implementera IAnnotationPresentation.
I och med introduktionen av utökningsbara startlägen i version 3.0 kan det finnas fler än en
startdelegat för en startkonfigurationstyp. Äldre versioner än version 3.0 kunde endast
hantera en startdelegat per startkonfigurationstyp. Metoden ILaunchConfigurationType.getDelegate()
har nu utkommenterats. Metoden getDelegate(strängläge)
bör i stället
används när startdelegaten för ett visst startläge ska hämtas.
Den utkommenterade metoden har ändrats så att startdelegaten returneras för run
-läget.
För startflikgrupper och startflikar meddelas inte längre när en start
slutförs. Metoden launched(ILaunch)
i gränssnittet ILaunchConfigurationTab
och ILaunchConfigurationTabGroup
har utkommenterats och anropas inte längre. Att lita på denna metod som startfunktion har alltid varit problematiskt, eftersom flikar endast existerar när starten sker från startdialogrutan. I och med introduktionen av bakgrundsstarter kan inte denna metod anropas
eftersom startdialogrutan har stängts innan det resulterande startobjektet existerar.
Två metoder har lagts till i ILaunchConfigurationTab
-gränssnittet
- activated och deactivated. Dessa nya livscykelmetoder anropas
när fokus går in eller ur en flik. Befintliga implementeringar av ILaunchConfigurationTab
som skapar en underklass av den abstrakta klassen som tillhandahålls av insticksprogrammet för felsökning (AbstractLaunchConfigurationTab
)
är binärkompatibla eftersom metoderna implementeras i den abstrakta klassen.
I tidigare utgåvor skickades meddelandet initializeFrom
till en flik när den aktiverades och performApply
när den avaktiverades. På detta sätt upprätthöll ramverket för startkonfigurationsflikar en kommunikation mellan flikar
via en startkonfiguration (genom att uppdatera konfigurationen med
aktuella attributvärden när fokus lämnar fliken och uppdatera den flik som fokus går till). Eftersom många flikar inte upprätthåller någon kommunikation mellan sig kan detta vara
ineffektivt. Dessutom fanns det inget sätt att skilja mellan en flik som aktiverades och en flik som
visade en vald startkonfiguration för första gången. De nya metoderna tillåter flikar att skilja på aktivering och
initialisering, och att avaktivera och spara aktuella värden.
Standardimplementeringen av activated
, som tillhandahålls av abstraktfliken, anropar initializeFrom
. Standardimplementationen
av deactivated
anropar performApply
. Flikar som vill dra fördel av
det nya API:et bör åsidosätta dessa metoder när det behövs.
För flikar som inte kommunicerar med varandra
bör du återimplementera metoderna att inte göra något.
I tidigare utgåvor angavs perspektivväxling på en startkonfiguration via startkonfigurationens attribut ATTR_TARGET_DEBUG_PERSPECTIVE
och ATTR_TARGET_RUN_PERSPECTIVE
. I och med tillägget av
utökade startlägen i version 3.0 behövs inte detta längre. Perspektivväxling anges
numer på startkonfigurationstypbas per startläge som en
startkonfigurationstyp stöder. Ett API hat lagts till i DebugUITools
för att
ange och hämta perspektivet som är associerat till en startkonfigurationstyp för ett visst
startläge.
Ett extra, valfritt, launchMode
-element har lagts till
i utökningspunkten launchConfigurationTabGroup
, vilket tillåter att en
bidragande flikgrupp anger ett standardperspektiv för
startkonfigurationstyp och -läge.
I användargränssnittet i Eclipse kan användare redigera det perspektiv som är associerat till en startkonfigurationstyp genom att öppna dialogrutan för startkonfiguration och välja en startkonfigurationstypnod i trädet (i stället för en individuell konfiguration). En flik visas där användaren kan ange ett perspektiv med varje startläge som stöds.
Två metoder har lagts till i VMRunnerConfiguration
-klassen.
Tack vare dessa två metoder kan miljövariabler anges och hämtas. Implementeringsfunktioner i IVMRunner
bör anropa VMRunnerConfiguration.getEnvironment()
och skicka den
miljön till den JVM som körs. Klienter som använder DebugPlugin.exec(String[]
cmdLine, File workingDirectory)
kan göra detta genom att i stället anropa DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
. Det räcker att skicka
med resultatet från getEnvironment()
.
I tidigare versioner hade VMRunnerConfiguration
ett attribut som
beskrev boot-sökvägen. Attributet är en samling av strängar
som anges i argumentet -Xbootclasspath
. Tre nya
attribut har lagts till i VMRunnerConfiguration för att stödja JVM:er som
tillåter att information läggs till i slutet eller början av boot-sökvägen. De nya metoderna/attributen som lagts till är:
getPrependBootClassPath()
- returnerar en samling med poster
som läggs till i början av boot-sökvägen (argumentet -Xbootclasspath/p
)getMainBootClassPath()
- returnerar en samling med poster
som läggs till i boot-sökvägen (argumentet -Xbootclasspath
)getAppendBootClassPath()
- returnerar en samling med poster
som läggs till i slutet av boot-sökvägen (argumentet -Xbootclasspath/a
)Det gamla attributet getBootClassPath()
finns fortfarande och innehåller
en komplett sökväg som motsvarar de tre nya attributen. VMRunners
som stöder de nya boot-sökvägsalternativen bör dock använda de nya
attributen.
Java-modellens arbetskopia har arbetats om i version 3.0 för att öka funktionaliteten. I äldre versioner än 3.0 tillät Java-modellen att individuella arbetskopior av kompileringsenheter skapades. Ändringar kunde göras i arbetskopian och sedan bekräftas. Det fanns stöd för en begränsad analys av en arbetskopia i kontextet till resten av Java-modellen. Dessa analyser kunde dock inte analysera mer än en arbetskopia åt gången.
Tack vare ändringarna i version 3.0 kan uppsättningar av arbetskopior skapas och hanteras med kompileringsenheter. Alla arbetskopior i en uppsättning kan analyseras. Exempelvis kan en klient som JDT-omfakturering skapa arbetskopior för en eller flera kompileringsenheter som ska modifieras och sedan lösa typreferenser mellan arbetskopiorna. Förut var detta endast möjligt efter att ändringarna av kompileringsenhetens arbetskopior hade bekräftats.
Java-modellens API har ändrats på två sätt för det förbättrade stödet:
(1) Funktionerna som förut fanns i IWorkingCopy
och
som ärvdes av ICompilationUnit
har konsoliderats till ICompilationUnit
.
Gränssnittet IWorkingCopy
användes endast till detta och var
mycket mer allmänt än det behövde vara. Ändringen förenklar API:et. IWorkingCopy
har utkommenterats. Andra platser i API:et där IWorkingCopy
används
som en parameter eller resultattyp har också utkommenterats. Ersättningsmetoderna i API:et
nämns i ICompilationUnit
i stället för i IWorkingCopy
.
(2) Gränssnittet IBufferFactory
har ersatts av WorkingCopyOwner
.
Det förbättrade stödet för arbetskopior kräver att det finns ett objekt som äger
arbetskopiorna. Även om IBufferFactory
är på rätt ställe så
beskriver inte namnet tillräckligt väl hur den nya arbetskopiemekanismen fungerar. WorkingCopyOwner
är mycket mer beskrivande. Dessutom deklareras WorkingCopyOwner
som en abstrakt klass i stället för ett gränssnitt, vilket gör det möjligt för begreppet arbetskopieägare att utvecklas i framtiden. Den enda metoden i IBufferFactory
flyttas opåverkad till WorkingCopyOwner
. WorkingCopyOwner
implementerar inte IBufferFactory
. Orsaken är att det ska vara tydligt att IBufferFactory
hör till en tidigare version. IBufferFactory
har utkommenterats. Andra platser i
API:et där IBufferFactory
visas som en parameter eller
resultattyp har också utkommenterats. Ersättningsmetoderna i API:et nämns i WorkingCopyOwner
i stället för IBufferFactory
.
Ändringarna bryter inte den binära kompatibiliteten.
När du migrerar måste alla referenser till typen IWorkingCopy
i stället referera till
ICompilationUnit
. Den enda implementeringen av IWorkingCopy
implementerar också ICompilationUnit
. Detta innebär att objekt av typen IWorkingCopy
på ett säkert sätt kan typomvandlas till ICompilationUnit
.
En klass som implementerar IBufferFactory
måste ersättas med
en underklass till WorkingCopyOwner
. Även om WorkingCopyOwner
inte implementerar själva IBufferFactory
, är det möjligt att deklarera
underklassen till WorkingCopyOwner
som implementerar IBufferFactory
och på så vis skapa en brygga mellan den gamla och den nya (IBufferFactory
deklarerar createBuffer(IOpenable)
, där WorkingCopyOwner
deklarerar createBuffer(ICompilationUnit)
; ICompilationUnit
utökar IOpenable
).
Eftersom ändringarna som berör IWorkingCopy
och IBufferFactory
är sammankopplade rekommenderar vi att du hanterar båda samtidigt. Utkommenteringsdetaljerna är följande:
IWorkingCopy
(org.eclipse.jdt.core
-paketet)
public void commit(boolesk, IProgressMonitor)
har utkommenterats.
ICompilationUnit
direkt:
public void commitWorkingCopy(boolesk, IProgressMonitor)
wc.commit(b,monitor)
som ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
public void destroy()
har utkommenterats.
ICompilationUnit
direkt:
public void discardWorkingCopy(boolesk, IProgressMonitor)
wc.destroy()
som ((ICompilationUnit)
wc).discardWorkingCopy()
public IJavaElement findSharedWorkingCopy(IBufferFactory)
har utkommenterats.
ICompilationUnit
direkt:
public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
WorkingCopyOwner
ersätter IBufferFactory
.public IJavaElement getOriginal(IJavaElement)
har utkommenterats.
IJavaElement
:
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
som elt.getPrimaryElement()
IWorkingCopy.getOriginal
returnerar IJavaElement.getPrimaryElement
inte null
om mottagaren inte är en arbetskopia.public IJavaElement getOriginalElement()
har utkommenterats.
ICompilationUnit
direkt:
public ICompilationUnit getPrimary()
wc.getOriginalElement()
som ((ICompilationUnit)
wc).getPrimary()
IWorkingCopy.getOriginalElement
returnerar IWorkingCopy.getPrimary
inte null
om mottagaren inte är en arbetskopia.public IJavaElement[] findElements(IJavaElement)
har utkommenterats.
ICompilationUnit
direkt.wc.findElements(elts)
som ((ICompilationUnit)
wc).findElements(elts)
public IType findPrimaryType()
har utkommenterats.
ICompilationUnit
direkt.wc.findPrimaryType()
som ((ICompilationUnit)
wc).findPrimaryType()
public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
har utkommenterats.
ICompilationUnit
direkt:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
ersätter IBufferFactory.
public IJavaElement getWorkingCopy()
har utkommenterats.
ICompilationUnit
direkt:
public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
som ((ICompilationUnit)
wc).getWorkingCopy(null)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
har utkommenterats.
ICompilationUnit
direkt:
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
WorkingCopyOwner
ersätter IBufferFactory.
public boolean isBasedOn(IResource)
har utkommenterats.
ICompilationUnit
direkt:
public boolean hasResourceChanged()
wc.isBasesOn(res)
som ((ICompilationUnit)
wc).hasResourceChanged()
public boolean isWorkingCopy()
har utkommenterats.
ICompilationUnit
direkt.wc.isWorkingCopy()
som ((ICompilationUnit)
wc).isWorkingCopy()
public IMarker[] reconcile()
har utkommenterats.
ICompilationUnit
direkt:
public void reconcile(boolesk,IProgressMonitor)
wc.reconcile()
som ((ICompilationUnit)
wc).reconcile(false, null)
null
. Ersättningsmetoden returnerar inget resultat.public void reconcile(boolesk, IProgressMonitor)
har utkommenterats.
ICompilationUnit
direkt.wc.reconcile(b,monitor)
som ((ICompilationUnit)
wc).reconcile(b.monitor)
public void restore()
har utkommenterats.
ICompilationUnit
direkt.wc.restore()
som ((ICompilationUnit)
wc).restore()
IType
(org.eclipse.jdt.core
-paketet)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
har utkommenterats.
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
typomvandlas till ICompilationUnit[]
.public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
har utkommenterats.
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
typomvandlas till ICompilationUnit[]
.IClassFile
(org.eclipse.jdt.core
-paketet)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
har utkommenterats.
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
WorkingCopyOwner
ersätter IBufferFactory.
JavaCore
(org.eclipse.jdt.core
-paketet)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
har utkommenterats.
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
WorkingCopyOwner
ersätter IBufferFactory
.ICompilationUnit[]
typomvandlas till IWorkingCopy[]
.SearchEngine
(org.eclipse.jdt.core.search
-paketet)
public SearchEngine(IWorkingCopy[])
har utkommenterats.
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
typomvandlas till ICompilationUnit[]
.Insticksprogrammet org.eclipse.help som innehöll API:er och utökningspunkter som lade till och utökade hjälpsystemet och även visade hjälpen, innehåller nu endast API:er och utökningspunkter som lägger till och accessar hjälpresurser. En del av hjälpens standardimplementation av användargränssnittet som fanns i det insticksprogrammet har flyttats till ett nytt insticksprogram, org.eclipse.help.base, tillsammans med API:er för utökning av implementationen. API:erna och utökningspunkterna som lägger till användargränssnittet i hjälpen och visar hjälpen har flyttats till insticksprogrammet org.eclipse.ui. I och med denna omstrukturering får tillämpningarna större flexibilitet med hjälpsystemet. Den nya strukturen gör det möjligt för tillämpningar som är baserade på den allmänna arbetsytan att tillhandahålla sitt eget användargränssnitt för hjälpen och/eller hjälpimplementering eller utelämna hjälpsystemet helt och hållet.
Eftersom de påverkade utökningspunkterna och API-paketen endast ska användas till hjälpsystemet är det inte sannolikt att de befintliga insticksprogrammen påverkas av denna ändring. De finns med här för att dokumentationen ska vara fullständig:
Ett nytt API som implementerar anpassade sökningar har lagts till i version 3.0. Det ursprungliga API:et är utkommenterat i version 3.0 och vi rekommenderar att klienter portar till det nya API:et i paketen org.eclipse.search.ui och org.eclipse.search.ui.text.
Klienter måste skapa implementeringar av ISearchQuery
, ISearchResult
och ISearchResultPage
. ImplementeringenISearchResultPage
måste sedan tilldelas i den nya utökningspunkten org.eclipse.search.searchResultViewPages
.
Standardimplementeringar av ISearchResult
och ISearchResultPage
finns i paketet org.eclipse.search.ui.text
.
Om du anropade SWT:s DirectoryDialog.setMessage(String sträng) eller MessageBox.setMessage(String sträng) med ett null-värde på strängen i äldre versioner än 3.0, visades en dialogruta utan text i titeln. Beteendet var ospecificerat (att skicka null har aldrig varit tillåtet) och skapade problem med getMessage, som inte får returnera null. Om du skickar null i version 3.0 resulterar det i att undantaget IllegalArgumentException returneras. Specifikationerna har ändrats så att detta framgår, vilket ligger i linje med metoden i deras överordnade klass, Dialog.setMessage. Om du använder Dialog.setMessage måste du se till att den sträng som skickas aldrig är null. Om du vill ha en dialogruta utan text i titeln skickar du en tom sträng.
Om du vill stödja samtidiga åtgärder krävs det mer sofistikerade sätt att visa modala förlopp. Som en del av satsningen har vi implementerat ökat förloppsstöd i klassen IProgressService. Det nuvarande sättet att visa förlopp med ProgressMonitorDialog fungerar fortfarande. Om du vill förbättra slutanvändarens upplevelse rekommenderar vi dock att du migrerar till den nya IProgressService.
I dokumentet om om hur du visar modala förlopp i Eclipse 3.0 beskrivs hur du migrerar till den nya IProgressService.
Utökningspunkten för åtgärdsgruppen för felsökning (org.eclipse.debug.ui.debugActionGroups) har tagits bort. I arbetsmiljön i Eclipse 3.0 introducerades funktioner för aktiviteter via utökningspunkten org.eclipse.platform.ui.activities. Här finns allt som åtgärdsgrupperna för felsökning hade, men den är enklare att använda (den stöder mönster i stället för att ange alla åtgärder fullständigt) med ett programmerbart API som stöd. Det uppstår inga fel om du inte tar bort referenser till den gamla utökningspunkten. Referenser till utökningspunkten ignoreras. Produktleverantörer uppmuntras att använda arbetsytans stöd för aktiviteter när de associerar språkspecifika felsökningsåtgärder med språkspecifika aktiviteter (C++-felsökningsåtgärder kan till exempel associeras till en aktivitet som kallas "Utveckla C++").
IBreakpointManager definierar nu metoderna setEnabled(boolesk) och isEnabled(). När brytpunktshanteraren avaktiveras bör felsökarna ignorera alla registrerade brytpunkter. Felsökningsplattformen har också en ny lyssnarmekanism, IBreakpointManagerListener, som tillåter klienter att registrera sig hos brytpunktshanteraren så att de får meddelande om när deras aktivering ändras. Brytpunktsvyn anropar detta API från en ny åtgärd som ger användaren möjlighet att "Ignorera alla brytpunkter". Felsökare som inte följer brytpunktshanterarens aktivering kommer i så fall att verka felaktigt, om användaren försöker använda denna funktion.
Språk som ligger nära Java (till exempel JSP, SQLJ, JWS m.m.) bör kunna delta i Java-sökning. Särskilt bör implementeringsfunktioner av sådana språk kunna det:
En sådan implementeringsfunktion kallas för sökdeltagare. Den utökar SearchParticipant-klassen. Sökdeltagare skickas till sökfrågor (se SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor)).
För att antingen indexera eller hitta träffar måste en sökdeltagare definiera en underklass till SearchDocument som kan hämta innehållet i dokumentet genom att åsidosätta antingen getByteContents() eller getCharContents(). En förekomst av underklassen returneras i getDocument(sträng).
En sökdeltagare som vill indexera vissa dokument använder SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) för att schemalägga indexeringen i det angivna dokumentet i det angivna indexet. När dokumentet är klart att indexeras anropar det underliggande ramverket SearchParticipant.indexDocument(SearchDocument, IPath). Sökdeltagarna får därefter dokumentets innehåll, tolkar det och lägger till indexposter med SearchDocument.addIndexEntry(char[], char[]).
När indexeringen är klar kan man ställa frågor till indexet och söka efter träffar med SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor). Då efterfrågas först varje sökdeltagare efter indexen som behövs i frågan med SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope). För varje indexpost som matchar det angivna sökmönstret skapas ett sökdokument genom att sökdeltagarna tillfrågas (se getDocument(sträng)). Alla dessa dokument skickas till sökdeltagaren så att den kan söka efter träffar med locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor). Sökdeltagaren meddelar SearchRequestor sökträffarna med acceptSearchMatch(SearchMatch) och skickar en förekomst av en underklass till SearchMatch.
En sökdeltagare kan delegera en del av arbetet till Javas standardsökdeltagare. En förekomst av denna standarddeltagare medföljer med SearchEngine.getDefaultSearchParticipant(). När en sökdeltagare till exempel uppmanas att söka efter träffar kan en SQLJ-deltagare skapa .java-dokument från .sqlj-dokument och delegera arbetet till standarddeltagaren och skicka .java-dokumenten dit.