Eclipse har ändrats på ett inkompatibelt sätt mellan version 3.0 och 3.1, på ett sätt som påverkar insticksprogram. Under följande rubriker beskrivs de olika områdena som har ändrats. Texten innehåller även instruktioner för hur du migrerar 3.0-insticksprogram till version 3.1. Du behöver endast läsa detta om det uppstår problem när du ska köra 3.0-insticksprogrammet i version 3.1.
Vad som påverkas: Insticksprogram som initierar sina standardvärden genom att åsidosättaPlugin#initializeDefaultPreferences
eller
använder lyssnare för inställningsändringar.
Beskrivning: I Eclipse 3.1 migrerades objektet org.eclipse.jface.preference.IPreferenceStore
som kom från org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore
,
för att det ska ligga ovanför det nya inställningsramverket i Eclipse 3.0 som finns i insticksprogrammet org.eclipse.core.runtime
.
Åtgärd som krävs:Därför bör klienter som använder inställnings-API:erna kontrollera två potentiella problem:
sträng
eller ett typdefinierat objekt. För att vara en
god klient bör inställningsändringslyssnarna kunna hantera dessa tre situationer.org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences
måste du inkludera insticksprogrammet org.eclipse.core.runtime.compatibility
i listan över de insticksprogram
som krävs, eftersom sambandet har tagits bort från insticksprogrammet org.eclipse.ui.workbench
.Se även stycket om JFace-inställningslagret i avsnittet om rekommenderade ändringar i den här handboken.
Vad som påverkas: Insticksprogram som skapar, manipulerar eller lagrar IPath-objekt.
Beskrivning: I Eclipse 3.0 hade IPath-objekt ett antal begränsningar på sökvägssegment som var mer restriktiva än de i det underliggande operativsystemet. Dessa restriktioner är följande:
Dessa restriktioner har tagits bort i Eclipse 3.1 om plattformens dataplats (arbetsyta) finns i ett filsystem som inte har dessa restriktioner.
Åtgärd som krävs: För att kunna använda de utökade sökvägarna bör alla användning av Path och IPath i insticksprogram granskas och uppdateras enligt beskrivningen nedan. De flesta oförändrade insticksprogram kommer att fungera precis som i version 3.0, förutsatt att sökvägarna r giltiga i version 3.0. Insticksprogrammen fungerar troligtvis inte om du låter bli att utföra de föreskrivna ändringarna om insticksprogrammen innehåller sökvägar som är giltiga i version 3.1 men var ogiltiga i version 3.0.
Insticksprogram som lagrar strängrepresentationer av sökvägar i ett format som kan läsas på olika plattformar bör migreras till den nya fabriksmetoden Path.fromPortableString. Metoden skapar en IPath-instans från ett plattformsoberoende format. Strängrepresentationen av sökvägar kan skapas med metoden IPath.toPortableString. Exempel på metadatafiler som påverkas är bland annat filer som lagras i Eclipse-arbetsmiljöprojekt (.project, .classpath m.m.) och alla sökvägar som lagras i inställningslagret (org.eclipse.core.runtime.preferences.IPreferencesService).
Obs! fromPortableString läser alla sökvägssträngar som skapades under Eclipse 3.0 med IPath.toString-metoden korrekt, men inte med Eclipse 3.1 toString-metoden. I de flesta fall behövs därför ingen ändring av befintliga metadatafilformat, såvida du inte börjar skriva sökvägar med toPortableString och läsa sökvägar med fromPortableString.
Insticksprogram som skapade sökvägar från hårdkodade strängkonstanter och antog att ":" och "\" hade olika betydelser på olika plattformar måste migreras. Den enklaste lösningen är att begränsa strängkonstanter i sökvägar till den delmängd som stöds av alla plattformar (undvik kolon och bakstreck). Sökvägskonstanter kan hantera hela uppsättningen av giltiga Unix-sökvägar genom att använda det portabla sökvägssträngformatet som skapas av Path.toPortableString. Formatet tolkar det första fristående kolonet (":") som enhetsseparator, snedstreck ("/") som segmentseparator och dubbelt kolon ("::") som ett riktigt kolontecken. Exempelvis skapar koden new Path("c:/temp") nu en relativ sökväg utan segment på Unix-plattformar. På liknande sätt kommer koden new Path("a\\b") att skapa en sökväg med ett segment på Unix-plattformar och en sökväg med två segment i Windows.
Insticksprogram som skapar sökvägar med IPath.append(String)-metoden och antar att ":" och "\" har en speciell betydelse på alla plattformar måste kanske uppdateras. I Eclipse 3.1 använder metoden operativsystemspecifika enhets- och segmentavgränsare för att tolka sökvägssträngen. Om du till exempel anropar append("a\\b") på Unix-plattformar, läggs ett segment till. I Windows kommer fortfarande två segment att läggas till.
Alla datafiler som läses och tolkas av plattformen kommer inte längre att behandla ":" och "\" som specialtecken på alla plattformar. Alla sökvägar som lagras i datafiler som kan läsas på flera plattformar måste var i ett portabelt format. Exempelvis får sökvägar till ikonfiler och andra sökvägar i plugin.xml endast använda "/" som segmentsavgränsare i sökvägar.
Vad som påverkas: Insticksprogram som manipulerar eller bevarar IExtensionPoint
-,
IExtension
- och IConfigurationElement
-objekt från
Eclipse-plattformens insticksprogram eller utökningsregister.
Beskrivning: I äldre versioner än 3.0 var alla objekt som hämtades från utökningsregistret
(i det tidigare insticksprogramregistret) alltid giltiga. I
Eclipse 3.0 gjordes ändringar som tillät att insticksprogram dynamiskt kunde läggas till och tas bort utan att Eclipse behövde startas om. När ett insticksprogram tas bort utan omstart blir posterna om insticksprogrammet i
utökningsregistret ogiltiga. Detta betyder att andra insticksprogram som
håller kvar ett objekt som kommer från det borttagna insticksprogrammets post i utökningsregistret
skulle hålla kvar ett ogiltigt objekt. Det enda tips en klient kunde få var att
lyssna efter IRegistryChangeEvent
.
Problemet har funnits sedan Eclipse 3.0 men uppstår sällan eftersom
det är mycket ovanligt att insticksprogram tas bort utan att
Eclipse startas om.
Problemet har åtgärdats i version 3.1:
IExtensionPoint
, IExtension
och IConfigurationElement
specificerar nu att InvalidRegistryObjectException
returneras när objektet är ogiltigt. Undantaget är okontrollerat och därför behöver inte
dynamiskt omedvetna klienter kontrollera det.isValid()
-metod har lagts till i dessa gränssnitt så att en klient kan
avgöra om ett objekt fortfarande är giltigt.Åtgärd som krävs: Om insticksprogrammet måste vara dynamiskt medvetet (dvs.
kunna hantera tillägg och borttagning av insticksprogram dynamiskt) måste koden som hanterar
IExtensionPoint
-, IExtension
- och IConfigurationElement
-objekt
som hämtats från andra insticksprogram ändras så att den fångar upp IRegistryChangeEvent
på samma sätt som ett kontrollerat undantag. Att fånga upp undantag (i stället för att förkontrollera isValid()
) är det enda säkra sättet att hantera
insticksprogram som tas bort i en samtidig tråd (vilket, om det inträffar, med största sannolikhet kommer att vara):
Vad som påverkas: Insticksprogram som i programkod accessar Java-kodformateraralternativ.
Beskrivning: I Eclipse 3.0 kan endast värdena för kodformateraralternativen
org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR
vara TAB
eller SPACE
. I specifikationerna finns inget uttryckligt
omnämnande om att värdetypen är en uppräkning som kan växa i framtida utgåvor. I Eclipse 3.1 lades ett tredje möjligt värde till, MIXED
, som åtgärdar felet 73104.
Specifikationen har ändrats och inkluderar nu det nya värdet samt tillåter fler nya värden i framtiden.
Åtgärd som krävs: Klienter som i programkod läser eller anger detta kodformateraralternativ bör kontrollera sin kod så att de tar med det nya tredje värdet. Koden ska också vara skriven på ett robust sätt som misslyckas på ett säkert sätt, om koden stöter på ett värde som inte kan förutses.
Vad som påverkas: Insticksprogram som använder underklasser eller skapar förekomster av org.eclipse.ant.core.AntCorePreferences
Beskrivning: I Eclipse 3.0 markerades inte klassen org.eclipse.ant.core.AntCorePreferences
på ett sätt som visade att den inte fick användas som underklass eller instantieras. Detta var ett misstag som rättats till i Eclipse 3.1. Numera är klassen uppmärkt på ett sätt som visar ett den inte ska användas som underklass eller instantieras.
Åtgärd som krävs: Klienter som programmatiskt skapar en förekomst av org.eclipse.ant.core.AntCorePreferences
bör migrera koden så att inställningarna hämtas med org.eclipse.ant.core.AntCorePlugin.getPreferences()
.
Alla underklasser måste omarbetas så att de inte använder org.eclipse.ant.core.AntCorePreferences
som en underklass.
Vad som påverkas: RCP-tillämpningar som åsidosätter JFace-loggen som anges i arbetsmiljön.
Beskrivning: I Eclipse 3.0 angav arbetsmiljön arbetsmiljöns logg som den logg som skulle användas för loggning av JFace-fel, genom att skicka loggen direkt till
org.eclipse.jface.util.Policy.setLog(ILog)
. I version 3.1 har beroendet på ILog
tagits bort från JFace, vilket aktiverar fristående tillämpningar som använder SWT och JFace utanför Eclipse runtimemodulen. Ett nytt gränssnitt, ILogger
, som uppfyller behoven i JFace har introducerats för att. Arbetsmiljön har ändrats och tillhandahåller en ILogger
som paketerar arbetsmiljöns ILog
. Mer detaljer finns i For fel 88608.
Åtgärd som krävs: De flesta RCP-tillämpningar behöver inte åsidosätta loggen som anges av arbetsmiljön, men om de tidigare anropade Policy.setLog(ILog)
måste de ändras så att de skickar en ILogger
i stället.
Vad som påverkas: RCP-tillämpningar som förväntar sig ett standardperspektiv som inte är null.
Beskrivning: För att RCP-tillämpningar ska kunna starta med ett tomt fönster
utan öppna perspektiv (förbättring 71150), har
WorkbenchAdvisor.getInitialWindowPerspectiveId()
och IPerspectiveRegistry.getDefaultPerspective()
ändrats så att null är ett tillåtet returvärde. I IDE finns det alltid ett standardperspektiv, därför returnerar inte
IPerspectiveRegistry.getDefaultPerspective()
null. Om en befintlig RCP-tillämpning tidigare returnerade ett värde som inte var null från WorkbenchAdvisor.getInitialWindowPerspectiveId()
, kommer
IPerspectiveRegistry.getDefaultPerspective()
fortfarande att returnera ett värde som inte är null.
Åtgärd som krävs: Ingen åtgärd krävs av klienterna.
Vad som påverkas: Insticksprogram som implementerar org.eclipse.ui.IViewLayout.
Beskrivning: I Eclipse 3.0 markerades inte klassen org.eclipse.ui.IViewLayout
på ett sätt som visade att den inte fick implementeras. Detta var ett misstag som har rättats till i Eclipse 3.1. Numera är klassen uppmärkt på ett sätt som visar ett den inte ska implementeras.
Åtgärd som krävs: Alla implementerande klasser måste arbetas om så att de inte längre
implementerar org.eclipse.ui.IViewLayout
.
Vad som påverkas: Insticksprogram som implementerar org.eclipse.jdt.launching.IVMInstall
.
Beskrivning: I Eclipse 3.0 markerades inte klassen org.eclipse.jdt.launching.IVMInstall
på ett sätt som visade att den inte fick implementeras direkt. Detta var ett misstag som har rättats till i Eclipse 3.1. Numera är klassen uppmärkt på ett sätt som visar ett den inte ska implementeras. För att behålla den binära kompatibiliteten tillåter vi fortfarande klienter att implementera gränssnittet direkt. Vi rekommenderar dock att
klienterna i stället använder underklasser av org.eclipse.jdt.launching.AbstractVMInstall
. Klienter som implementerar IVMInstall
bör även implementera det nya valfria gränssnittet org.eclipse.jdt.launching.IVMInstall2
som
AbstractVMInstall
nu implementerar. Vi rekommenderar att klienter implementerar det nya gränssnittet, IVMInstall2
, för att undvika de problem som finns i fel 73493. Den rekommenderade migrationen är att använda underklasser av AbstractVMInstall
.
Åtgärd som krävs: Alla implementerande klasser som inte redan använder underklasser av
org.eclipse.jdt.launching.AbstractVMInstall
bör arbetas om
så att de använder underklasser av org.eclipse.jdt.launching.AbstractVMInstall.
Vad som påverkas: Insticksprogram som använder org.eclipse.ui.SelectionEnabler.SelectionClass
.
Beskrivning: I Eclipse 3.0 var den nästlade implementeringsklassenorg.eclipse.ui.SelectionEnabler.SelectionClass
"public" utan användarrestriktioner. Detta var ett misstag som har rättats till i Eclipse 3.1. Numera är klassen paketsynlig.
Åtgärd som krävs: Alla klasser som skapar förekomster av eller utökar org.eclipse.ui.SelectionEnabler.SelectionClass
måste arbetas om så att de inte längre hänvisar till klassen.
Vad som påverkas: Insticksprogram som anropar getParent()
på en underklass till org.eclipse.jface.action.ContributionItem
.
Beskrivning: I Eclipse 3.0 angav inte metoden org.eclipse.jface.action.ContributionItem.getParent()
att den kunde returnera null. Detta var ett misstag som rättats till i Eclipse 3.1. I Javadoc är det nu beskrivet när metoden kan returnera null. Mer detaljer finns i fel 92777.
Åtgärd som krävs: All kod som anropar ContributionItem.getParent() måste se till att den kan hantera ett null-resultat.
Vad som påverkas: Insticksprogram som implementerar org.eclipse.ui.views.properties.IPropertySource
eller IPropertySource2
.
Beskrivning: I Eclipse 3.0 ändrades specifikationen för metoden org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolesk)
felaktigt så att true (sant) skulle returneras om den angivna egenskapen
inte hade ett meningsfullt standardvärde. I tidigare versioner angavs att false (falskt) skulle returneras
i det fallet. Detta var en oavsiktlig API-ändring även om implementeringen fungerade på samma sätt som förut om egenskapskällan
implementerade IPropertySource
och inte IPropertySource2
.
Detta har rättats till i version 3.1 genom att IPropertySource.isPropertySet(boolesk)
har återställts till den tidigare specifikationen (att false (falskt) returneras i det här fallet)
och IPropertySource2.isPropertySet(boolesk) åsidosätter detta genom att returnera true (sant) i det här fallet. Mer detaljer finns i fel 21756.
Åtgärd som krävs: Alla klasser som implementerar IPropertySource eller IPropertySource2 där vissa av egenskaperna inte har meningsfulla värden, bör kontrolleras så att de returnerar rätt värde för isPropertySource(boolesk). Klienter bör kontrollera att knappen Återställ standardvärde i egenskapsvyn fungerar enligt förväntan för egenskapskällan.
Vad som påverkas: Insticksprogram som använde experimentelementet
handlerSubmission
som introducerades i utökningspunkten
org.eclipse.ui.commands
i Eclipse 3.0.
Beskrivning: I Eclipse 3.0 introducerades ett experimentelement i utökningspunkten
org.eclipse.ui.commands
. Elementet syfte var att registrera
hanterare via XML. Efter det har en bättre mekanism, utökningspunkten
org.eclipse.ui.handlers
, introducerats. Eftersom elementet var markerat som experimentellt har det nu tagits bort.
Åtgärd som krävs: Alla insticksprogram som definierar ett
handlerSubmission
-element bör migrera till utökningspunkten
org.eclipse.ui.commands
.
Vad som påverkas: Insticksprogram som anger fältet GLOBAL_IGNORES_CHANGED i TeamUI.
Beskrivning: I Eclipse 3.0 lades fältet GLOBAL_IGNORES_CHANGED till i TeamUI-klassen. Fältet är en konstant som används i en egenskapsändringshändelse för att visa att listan över globala ignoreringar som underhålls av insticksprogrammet Team här ändrats. Fältet var inte markerat som klart i version 3.0, men borde ha varit det. I version 3.1 är det markerat som klart.
Åtgärd som krävs: Alla insticksprogram som angav ovanstående fält kan inte längre göra det.
Vad som påverkas: Insticksprogram som använder FillLayout på ett felaktigt sätt.
Beskrivning: I Eclipse 3.0 associerades inga layoutdata med FillLayout och om en tillämpning tilldelade layoutdata till en underordnad som hanterades av FillLayout, ignorerades den. I Eclipse 3.1 finns nu stöd för FillLayout så att storleksinformation kan mellanlagras, för prestanda för storleksändringar ska bli bättre. Den mellanlagrade informationen lagras i ett FillData-objekt som är associerat till varje underordnad som hanteras av FillLayout. Om en tillämpning felaktigt har tilldelat layoutdata till en underordnad, returneras ett ClassCastException när computeSize anropas på den överordnade.
Åtgärd som krävs: Hitta alla underordnade i en FillLayout som har tilldelats layoutdata och upphöra med tilldelningen av layoutdata.
Vad som påverkas: Insticksprogram som fångar upp undantag när gränssnittskontroller skapas.
Beskrivning: I Eclipse 3.0 returnerades inga undantag om en gränssnittsskontroll skapades med en borttagen överordnad och gränssnittskontrollkoden misslyckades vid ett senare tillfälle eller så returnerades ett SWTException med ett meddelande om att gränssnittskontrollen är borttagen. I Eclipse 3.1 returnerar konstruktorn ett IllegalArgumentException med ett meddelande om att argumentet inte är giltigt om en gränssnittskontroll skapades med en borttagen överordnad.
Åtgärd som krävs:All kod som hanterar SWTException när en gränssnittskontroll skapas måste nu även hantera IllegalArgumentException.