Inkompatibilitet mellan Eclipse 3.0 och 3.1

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.

  1. Inställningar för insticksprogram
  2. Ändringar av IPath-begränsningar
  3. Utökningsregister
  4. Kodformateraralternativ
  5. API-kontraktsändringar av AntCorePreferences
  6. API-kontraktsändringar av Policy-klassen i JFace
  7. API-kontraktsändringar som tillåter null som standardperspektiv
  8. API-kontraktsändringar av IViewLayout
  9. API-kontraktsändringar av IVMInstall
  10. SelectionEnabler.SelectionClass är nu paketsynlig
  11. ContributionItem.getParent() kan returnera null
  12. Ändringar av isPropertySet(boolesk) i IPropertySource och IPropertySource2
  13. Elementet handlerSubmission borttaget från utökningspunkten org.eclipse.ui.commands
  14. API-fältet GLOBAL_IGNORES_CHANGED som är "static" eller inte "final" i TeamUI är slutgiltigt
  15. ClassCastException som använder FillLayout
  16. Skapa en gränssnittskontroll med en borttagen överordnad

1. Insticksprograminställningar

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:

  1. Objekttypen som finns i inställningsändringshändelser är inte garanterad. Både det nya och det gamla värdet i händelsen kan vara null, en sträng eller ett typdefinierat objekt. För att vara en god klient bör inställningsändringslyssnarna kunna hantera dessa tre situationer.
  2. Om insticksprogrammet använder 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.

2. Ändringar av IPath-begränsningar

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.

3. Utökningsregister

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:

Å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):

4. Kodformateraralternativ

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.

5. API-kontraktsändringar av AntCorePreferences

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.

6. API-kontraktsändringar av Policy-klassen i JFace

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.

7. API-kontraktsändringar som tillåter null som standardperspektiv

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.

8. API-kontraktsändringar av IViewLayout

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.

9. API-kontraktsändringar av IVMInstall

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.

10. SelectionEnabler.SelectionClass är nu paketsynlig

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.

11. ContributionItem.getParent() kan returnera null

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.

12. Ändringar av isPropertySet(boolesk) i IPropertySource och IPropertySource2

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.

13. Elementet handlerSubmission borttaget från utökningspunkten org.eclipse.ui.commands

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.

14. API-fältet GLOBAL_IGNORES_CHANGED som är "static" eller inte "final" i TeamUI är slutgiltig

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.

15. ClassCastException som använder FillLayout

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.

16. IllegalArgumentException returnerades när en gränssnittskontroll med en borttagen överordnad skapades

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.