Ändringar som krävs när du inför 3.0-mekanismer och -API:er

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.

Sluta att använda org.eclipse.core.runtime.compatibility

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.

Insticksprogram och samlingspaket

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.

Samlingspaket
Samlingspaket är OSGi-enheten för modularitet. Det finns en klassinläsare per samlingspaket och Eclipse-liknande diagram kan skapas över klassinläsningsberoenden mellan olika samlingspaket. Samlingspaket har livscykel för start och stopp och OSGi-ramverket sänder ut samlingspaketrelaterade händelser (till exempel install, resolve, start, stop, uninstall ...) till intresserade parter. Till skillnad från Plugin-klassen i Eclipse kan inte Bundle-klassen i OSGi utökas. Detta betyder att utvecklare inte kan definiera sin egen samlingspaketklass.
BundleActivator
BundleActivator är ett gränssnitt som definieras av OSGi-ramverket. Varje samlingspaket kan definiera en aktiveringsnyckelklass för samlingspaket på ungefär samma sätt som ett insticksprogram kan definiera sin Plugin-klass. Den angivna klassen instantieras av ramverket och används för implementering av livscykelbearbetningen start() och stop(). Det är dock en betydande skillnad i denna typ av livscykelbearbetning. I Eclipse är det vanligt (även om det inte rekommenderas) att Plugin-klasserna utför både initiering och registrering. I OSGi får endast aktiveringsnycklar utföra registreringen. Vid stora mängder av initieringar (eller annat arbete) i BundleActivator.start() hotas systemet.
BundleContext
BundleContext är OSGi-mekanismen som exponerar allmänna systemfunktioner för enskilda samlingspaket. Varje samlingspaket har en unik och privat förekomst av BundleContext som de kan använda när de använder systemfunktioner (till exempel getBundles() för att upptäcka alla samlingspaket i systemet).
Plugin
Den nya Plugin-klassen liknar mycket den gamla Plugin-klassen i Eclipse med följande undantag: Plugin-objekt krävs eller hanteras inte längre av runtimemodulen. Olika metoder har utkommenterats. Det är i huvudsak en mekanism som underlättar när du ger en värd användbara funktioner och mekanismer, även om den inte är absolut nödvändig. Mycket av funktionaliteten som ges där finns även i Platform-klassen i runtimemodulen.

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:

Initialisering
Datastruktur- och modellinitiering görs ofta i Plugin.startup(). Det naturlig/uppenbara skulle vara att göra detta arbetet i en BundleActivator.start()-funktion, dvs. att låta funktionen vara kvar i Plugin-klassen. Detta rekommenderas inte. Liksom 2.x-insticksprogram kan även 3.0-insticksprogram/samlingspaket startas av många olika skäl under många olika omständigheter.
Ett praktiskt exempel från Eclipse 2.0 belyser detta. Ett insticksprogram initierade en stor modell, vilket krävde att 11 MB kod och flera megabyte data lästes in. Detta var en vanlig företeelse då detta insticksprogram aktiverades för att upptäcka om projektikonen som presenterades i navigeringsvyn skulle dekoreras med ett visst märkord. För det här testet behövdes inte den initiering som gjordes i startup(). Nackdelen var att denna initiering krävde mycket minne och stora tidsförluster.
Det alternativa tillvägagångssättet är att göra en sådan initiering på ett "snålt" vis. I stället för att till exempel initiera modeller när insticksprogrammet/samlingspaketet aktiveras kan du göra det när de behövs (till exempel i en centraliserad modellaccessmetod). Ofta tar detta nästan lika mycket tid, men i andra scenarier kan den här metoden skjuta upp initieringen (kanske på obestämd tid). Vi rekommenderar att du din tid när du portar 2.1-insticksprogram och funderar över vilken initieringsstrategi som ska användas.
Registrering
När du startar insticksprogram är det praktiskt att samtidigt registrera lyssnare, tjänster m.m. och starta bakgrundsprocesstrådar (till exempel socketavlyssning). Plugin.start() kan vara en bra plats för detta arbete. Det kan också vara klokt att vänta på någon annan utlösare (användningen av till exempel en viss funktion eller dataelement).
Globala data i insticksprogrammet
Plugin-klassen kan fortsätta spela denna roll. Det viktigaste är att Plugin-objekt inte längre är globalt tillgängliga via en lista som hanteras av systemet. I Eclipse 2.x kunde du upptäcka alla Plugin-objekt i ett insticksprogram via insticksprogramregistret. Detta är inte möjligt nu. I de flesta fall krävs inte denna typ av access. Plugin-objekt som hämtas via registret används normalt som mer allmänna Plugin-objekt i stället för att de anropar domänspecifika metoder. Du får samma möjlighet genom att accessa och manipulera motsvarande Bundle-objekt.

Register och insticksprogrammodellen

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.

NL-fragmentstruktur

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.

Översikt över API-ändringar

org.eclipse.core.boot (org.eclipse.core.boot-paketet)

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.

IExtension och IExtensionPoint (org.eclipse.core.runtime-paketet)

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.

ILibrary, IPluginDescriptor, IPluginRegistry och IPrerequisite (org.eclipse.core.runtime-paketet)

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.

Plattform och Plugin (org.eclipse.core.runtime-paketet)

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.

org.eclipse.core.runtime.model (org.eclipse.core.runtime.model-paketet)

Alla typer i detta paket har nu kommenterats ut. Mer information finns i avsnittet om register.

IWorkspaceRunnable och IWorkspace.run (org.eclipse.core.resources-paketet)

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.

IWorkbenchPage (rg.eclipse.ui-paketet)

IEditorDescriptor (org.eclipse.ui-paketet)

ISharedImages (org.eclipse.ui-paketet)

IWorkbenchActionConstants (org.eclipse.ui-paketet)

IWorkbenchPreferenceConstants (org.eclipse.ui-paketet)

IExportWizard (org.eclipse.ui-paketet)

IImportWizard (org.eclipse.ui-paketet)

INewWizard (org.eclipse.ui-paketet)

WorkbenchHelp (org.eclipse.ui.help-paketet)

IHelp (org.eclipse.help-paketet)

ITextEditorActionConstants (org.eclipse.ui.texteditor-paketet)

IAbstractTextEditorHelpContextIds (org.eclipse.ui.texteditor-paketet)

BasicTextEditorActionContributor (org.eclipse.ui.texteditor-paketet)

TextEditorActionContributor (org.eclipse.ui.editors.text-paketet)

Utökningspunkten annotationTypes (insticksprogrammet org.eclipse.ui.editors)

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.

Utökningspunkten markerAnnotationSpecification (insticksprogrammet org.eclipse.ui.editors)

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

Migrering till utökningspunkten annotationTypes (insticksprogram org.eclipse.ui.editors)

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.

ILaunchConfigurationType (org.eclipse.debug.core-paketet)

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.

ILaunchConfigurationTab och ILaunchConfigurationTabGroup (org.eclipse.debug.ui-paketet)

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.

ILaunchConfigurationTab och AbstractLaunchConfigurationTab (org.eclipse.debug.ui-paketet)

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.

Utökningspunkttyp launchConfigurationTabGroup (org.eclipse.debug.ui-paketet)

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.

[Endast JDT] IVMRunner (org.eclipse.jdt.launching-paketet)

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().

[Endast JDT] VMRunnerConfiguration och Bootstrap-klasser (org.eclipse.jdt.launching-paketet)

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:

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.

[Endast JDT] Förbättrat stöd för arbetskopior (org.eclipse.jdt.core-paketet)

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:

Omstrukturering av insticksprogrammet org.eclipse.help

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:

Nytt API för användargränssnittet för sökning

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.

null-meddelanden i MessageBox och DirectoryDialog (org.eclipse.swt.widgets-paketet)

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.

Förbättra modal progress feedback

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.

Åtgärdsgruppen för felsökning har tagits bort

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++").

BreakpointManager kan avaktiveras

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.

[Endast JDT] Java-sökdeltagare (org.eclipse.jdt.core.search-paketet)

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.