Inkompatibilitet mellem Eclipse 3.0 og 3.1

Eclipse er ændret fra 3.0 til 3.1 på en måde, som påvirker plugins. Indgangene nedenfor beskriver de områder, der er ændret, og giver en vejledning i, hvordan man overfører 3.0-plugins til 3.1. Bemærk, at du kun behøver læse disse oplysninger, hvis du får problemer med at udføre 3.0-plugins i 3.1.

  1. Plugin-indstillinger
  2. Ændringer i IPath-betingelser
  3. Udvidelsesregistreringsdatabase
  4. Indstillinger for kodeformateringsprogram
  5. API-kontraktændringer i AntCorePreferences
  6. API-kontraktændringer i Policy-klassen i JFace
  7. API-kontraktændringer, der muliggør et null-standardperspektiv
  8. API-kontraktændringer i IViewLayout
  9. API-kontraktændringer i IVMInstall
  10. SelectionEnabler.SelectionClass gjort pakkesynlig
  11. ContributionItem.getParent() kan returnere null
  12. Ændringer i isPropertySet(boolean) i IPropertySource og IPropertySource2
  13. handlerSubmission-elementet er slettet fra org.eclipse.ui.commands-udvidelsespunktet
  14. Statisk, ikke-afsluttende API-felt GLOBAL_IGNORES_CHANGED i TeamUI gjort afsluttende
  15. ClassCastException vha. FillLayout
  16. Opret element med placeret overordnet element

1. Plugin-indstillinger

Hvad påvirkes: Plugins, som initialiserer deres standard-plugin-indstillingsværdier ved at tilsidesætte Plugin#initializeDefaultPreferences, eller som bruger indstillingsændringslytteprogrammer.

Beskrivelse: I Eclipse 3.1 blev org.eclipse.jface.preference.IPreferenceStore-objektet, som blev hentet fra org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore, overført, så det udføres oven på den nye 3.0 Eclipse-indstillingsstruktur, som er leveret af org.eclipse.core.runtime-plugin'en.

Påkrævet handling: Resultatet er, at klienter, der bruger indstillings-API'er, skal tjekke to ting:

  1. Den type objekter, der er indeholdt i indstillingsændringsaktiviteterne, er ikke garanteret. Både den gamle og den nye værdi i aktiviteterne kan være null, en String eller et indtastet objekt. For at være en god klient skal indstillingsændringslytteprogrammer kunne håndtere alle disse tre mulige situationer.
  2. Hvis plugin'en bruger org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences, skal du være sikker på at inkludere plugin'en org.eclipse.core.runtime.compatibility i plugin'ens liste over nødvendige plugins, fordi denne afhængighed er fjernet fra org.eclipse.ui.workbench-plugin'en.

Se også afsnittet JFace-indstillingslagre i afsnittet om anbefalede ændringer i denne guide.

2. Ændringer i IPath-betingelser

Hvad påvirkes: Plugins, som opretter, manipulerer eller gemmer IPath-objekter.

Beskrivelse: I Eclipse 3.0 havde IPath flere betingelser for de stisegmenter, som var mere restriktive end betingelserne for det underliggende styresystem. De omfattede:

Disse betingelser er fjernet i Eclipse 3.1, hvor platformens dataplacering (arbejdsområdet) er placeret i et filsystem, som ikke har disse betingelser.

Påkrævet handling: For at kunne behandle den udvidede vifte af stier korrekt, skal al brug af Path og IPath i plugins gennemgås og opdateres som beskrevet nedenfor. De fleste ikke-ændrede plugins fungerer på præcis samme måde som i 3.0, for så vidt angår alle stier, der betragtes som lovlige i 3.0. Medmindre de her angivne ændringer foretages, kan plugins dog ikke benyttes i forbindelse med stier, der blev betragtet som lovlige i 3.1, men ulovlige i 3.0.

Plugins, som gemmer lagerstrengsrepræsentationer af stier i et format, som skal kunne læses på tværs af forskellige platforme, skal overføres til den nye Path.fromPortableString-factory-metode. Denne metode frembringer en IPath-forekomst fra et platformsuafhængigt format. Strengrepræsentationen af stierne kan oprettes vha. metoden IPath.toPortableString. Eksempler på metadata-filer, som påvirkes, omfatter filer, der gemmes i Eclipse-arbejdsområdeprojekter, (.project, .classpath osv.), og alle stier, der gemmes i indstillingslageret (org.eclipse.core.runtime.preferences.IPreferencesService).

Bemærk: fromPortableString læser alle stistrenge korrekt, som er oprettet vha. Eclipse 3.0 IPath.toString-metoden, men ikke Eclipse 3.1 toString-metoden. I de fleste tilfælde kræves der derfor ingen ændring af eksisterende metadata-filformater, bortset fra hvis du skal begynde at skrive stier med toPortableString og læse stier med fromPortableString.

Plugins, som oprettede stier på basis af permanent indkodede strengkonstanter, som antog, at ':' og '\' havde en bestemt betydning på alle platforme, skal overføres. Den nemmeste løsning er at begrænse strengstikonstanterne til den delmængde, der understøttes på alle platforme (undgå at bruge kolon og backslash). Stikonstanter kan understøtte hele sættet af gyldige UNIX-stier vha. det stistrengsformat, som er fremstillet af Path.toPortableString. Dette format fortolker det første enkeltkolon (':') som et enhedskilletegn, skråstreg ('/') som segmentskilletegn og dobbeltkolon ("::") som et kolon-tegn. Koden ny sti("c:/temp") opretter f.eks. nu en relativ sti med to segmenter på UNIX-platforme. På samme måde opretter ny sti("a\\b") nu en sti med et enkelt segment på UNIX-platforme, og en sti med to segmenter på Windows.

Plugins, som opretter stier vha. metoden IPath.append(String), som antog, at ':' og '\' havde en bestemt betydning på alle platforme, skal eventuelt have opdateret deres kode. I Eclipse 3.1 bruger denne metode enheds- og segmentskilletegn, som er styresystemspecifikke, til at fortolke den leverede stistreng. Kaldet append("a\\b") på UNIX-platforme tilføjer nu et enkelt segment, hvorimod det på Windows fortsat tilføjer to segmenter.

Alle datafiler, som platformen læser og fortolker, behandler ikke længere ':' og '\' som specielle tegn på alle platforme. Alle stier, der er gemt i datafiler, som kan læses på flere platforme, skal være i et format, der kan overføres. Stier til ikonfiler og andre filer i plugin.xml skal f.eks. kun bruge '/' som skilletegn for segmenter i stien.

3. Udvidelsesregistreringsdatabase

Hvad påvirkes: Plugins, som manipulerer eller beholder IExtensionPoint-, IExtension- og IConfigurationElement-objekter fra Eclipse-platformens plugin eller udvidelsesregistreringsdatabase.

Beskrivelse: Før 3.0 kunne alle objekter, der blev hentet fra udvidelsesdatabasen (fra den tidligere plugin-registreringsdatabase), bruges resten af deres tid. Der blev foretaget ændringer i Eclipse 3.0, som gjorde, at plugins kunne tilføjes eller fjernes dynamisk, uden det var nødvendigt at starte Eclipse igen. Når en plugin fjernes, uden at systemet genstartes, bliver dens indgange i udvidelsesregistreringsdatabasen nødvendigvis ugyldige. Det betyder, at en anden plugin, som holder fast på en objekt, der tidligere er hentet fra den slettede plugins udvidelsesdatabaseindgang, efterlades med et ugyldigt objekt. Det eneste tip, som en klient kunne få, ville være resultatet af at lytte til IRegistryChangeEvent. Problemet har eksisteret siden Eclipse 3.0, men man støder ikke ret tit på det i praksis, fordi det er meget usædvanligt for en plugin at blive fjernet, uden at Eclipse genstartes.

Problemet er forsøgt løst i 3.1 på følgende måde:

Påkrævet handling: Hvis plugin'en skal være dynamisk opmærksom, dvs. være i stand til at håndtere løbende tilføjelser og fjernelser af plugins, skal den kode, der håndterer IExtensionPoint-, IExtension- og IConfigurationElement-objekter, som stammer fra en anden plugin, ændres, så de opfanger IRegistryChangeEvent, præcis som hvis det var en valgt undtagelse. At fange undtagelsen (i stedet for en isValid()-præmarkering) er den eneste helt sikre måde at håndtere det tilfælde, hvor en plugin fjernes af en samtidig programdel (thread) (hvilket den helt sikkert ville blive).

4. Indstillinger for kodeformateringsprogram

Hvad påvirkes: Plugins, som rent programmæssigt har adgang til indstillingerne for Java-kodeformateringsprogrammet.

Beskrivelse: I Eclipse 3.0 kunne værdierne for kodeformateringsprogrammet org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR kun være TAB eller SPACE. Specifikationen nævnte ikke klart, at værditypen var en enumeration, som kunne blive større i fremtidige versioner. I Eclipse 3.1 er der tilføjet en tredje, mulig værdi MIXED, som kan rette fejlen 73104. Specifikationen er ændret, så den indeholder denne nye værdi, og så flere værdier kan tilføjes i fremtiden.

Påkrævet handling: Klienter, som rent programmæssigt læser eller angiver dette kodeformateringsprogram, skal markere deres kode, så de kan tage højde for den nye, tredje værdi, og så de kan sikre, at den skrives på en robust måde, som lukker stille og roligt, hvis den skulle støde på en indstilling, som den ikke forventer.

5. API-kontraktændringer i AntCorePreferences

Hvad påvirkes: Plugins, som er underklasser til eller som opretter en forekomst af org.eclipse.ant.core.AntCorePreferences

Beskrivelse: I Eclipse 3.0 var klassen org.eclipse.ant.core.AntCorePreferences ikke valgte, så klienter ikke kunne oprette en forekomst af den eller være en underklasse til den. Det var en forglemmelse, som er løst i Eclipse 3.1, hvor klassen er valgte, som at den ikke forventes at være en underklasse eller at oprette en forekomst.

Påkrævet handling: Klienter, som rent programmæssigt opretter en forekomst af org.eclipse.ant.core.AntCorePreferences, skal overføre deres kode, så de kan hente indstillingerne ved hjælp af: org.eclipse.ant.core.AntCorePlugin.getPreferences(). En eventuel underklasse skal omarbejdes, så den ikke længere er en underklasse til org.eclipse.ant.core.AntCorePreferences.

6. API-kontraktændringer i Policy-klassen i JFace

Hvad påvirkes: RCP-programmer, som tilsidesætter den JFace-log, som er angivet af arbejdsbænken.

Beskrivelse: I Eclipse 3.0 angav arbejdsbænken arbejdsbænkens log som den log, der skulle bruges til at registrere JFace-fejl i log, ved at overføre arbejdsbænkens plugins log direkte i org.eclipse.jface.util.Policy.setLog(ILog). I 3.1 er afhængigheden af ILog fjernet fra JFace for at aktivere enkeltstående programmer vha. SWT og JFace uden for Eclipse-runtime. Der er indført en ny grænseflade ILogger, som skal imødekomme JFaces behov. Arbejdsbænken er ændret, så den stiller en ILogger til rådighed, der indpakker arbejdsbænkens ILog. Der er flere oplysninger i fejl 88608.

Påkrævet handling: De fleste RCP-programmer behøver ikke tilsidesætte den log, arbejdsbænken angiver, men hvis de tidligere har kaldt Policy.setLog(ILog), skal de ændres, så de i stedet videregiver en ILogger.

7. API-kontraktændringer, der muliggør et null-standardperspektiv

Hvad påvirkes: RCP-programmer, som forventer et ikke-null-standardperspektiv.

Beskrivelse: For at RCP-programmer kan starte med et tomt vindue uden åbne perspektiver (udvidelse 71150), er WorkbenchAdvisor.getInitialWindowPerspectiveId() og IPerspectiveRegistry.getDefaultPerspective() ændret, så det er tilladt at returnere null. I IDE er der altid et standardperspektiv, så IPerspectiveRegistry.getDefaultPerspective() returnerer ikke null. På samme måde gælder det, at hvis et eksisterende RCP-program tidligere returnerede en ikke-null-værdi fra WorkbenchAdvisor.getInitialWindowPerspectiveId(), returnerer IPerspectiveRegistry.getDefaultPerspective() stadig en ikke-null-værdi.

Påkrævet handling: Klienter skal intet foretage sig.

8. API-kontraktændringer i IViewLayout

Hvad påvirkes: Plugins, som implementerer org.eclipse.ui.IViewLayout.

Beskrivelse: I Eclipse 3.0 var klassen org.eclipse.ui.IViewLayout ikke valgte, så klienter kunne ikke implementere den. Det var en forglemmelse, som er løst i Eclipse 3.1, hvor klassen er valgte, som at den ikke forventes at blive implementeret af klienter.

Påkrævet handling: Klasser, der implementeres, skal omarbejdes, så de ikke længere implementerer org.eclipse.ui.IViewLayout.

9. API-kontraktændringer i IVMInstall

Hvad påvirkes: Plugins, som implementerer org.eclipse.jdt.launching.IVMInstall.

Beskrivelse: I Eclipse 3.0 var klassen org.eclipse.jdt.launching.IVMInstall ikke valgte, så klienter kunne ikke implementere den direkte. Det var en forglemmelse, som er løst i Eclipse 3.1, hvor klassen er valgte, som at den ikke forventes at blive implementeret direkte af klienter. For at opretholde den binære kompatibilitet tillader vi stadig klienter at implementere grænsefladen direkte, men vi anbefaler kraftigt, at klienterne i stedet er underklasser til org.eclipse.jdt.launching.AbstractVMInstall. Klienter, som implementerer IVMInstall, skal også implementere den ny valgfri grænseflade org.eclipse.jdt.launching.IVMInstall2, som AbstractVMInstall for øjeblikket implementerer. Det anbefales, at klienter implementerer den ny grænseflade, IVMInstall2, for at undgå det problem, der er nævnt i fejl 73493. Den anbefalede overførsel er til underklassen AbstractVMInstall.

Påkrævet handling: Alle implementerende klasser, som ikke allerede er underklasser til org.eclipse.jdt.launching.AbstractVMInstall, skal omarbejdes, så de bliver underklasser til org.eclipse.jdt.launching.AbstractVMInstall.

10. SelectionEnabler.SelectionClass gjort pakkesynlig

Hvad påvirkes: Plugins, som bruger org.eclipse.ui.SelectionEnabler.SelectionClass.

Beskrivelse: I Eclipse 3.0 var den indlejrede implementeringsklasse org.eclipse.ui.SelectionEnabler.SelectionClass offentlig (public) og havde ingen betingelser for brugen. Det var en forglemmelse, som er løst i Eclipse 3.1, hvor klassen er gjort pakkesynlig.

Påkrævet handling: Klasser, som opretter en forekomst af eller udvider org.eclipse.ui.SelectionEnabler.SelectionClass, skal omarbejdes, så de ikke længerer henviser til denne klasse.

11. ContributionItem.getParent() kan returnere null

Hvad påvirkes: Plugins, som kalder getParent() på en underklasse til org.eclipse.jface.action.ContributionItem.

Beskrivelse: I Eclipse 3.0 angav metoden org.eclipse.jface.action.ContributionItem.getParent() ikke, at den kunne returnere null. Det var en forglemmelse, som er rettet i Eclipse 3.1, hvor Javadoc til metoden angiver, hvornår den kan returnere null. Der er flere oplysninger i fejl 92777.

Påkrævet handling: Kode, der kalder ContributionItem.getParent(), skal sikre, at den kan håndtere et null-resultat.

12. Ændringer i isPropertySet(boolean) i IPropertySource og IPropertySource2

Hvad påvirkes: Plugins, som implementerer org.eclipse.ui.views.properties.IPropertySource eller IPropertySource2.

Beskrivelse: I Eclipse 3.0 var specifikationen til metoden org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) ved en fejl ændret til at angive, at true skal returneres, hvis den angivne egenskab ikke havde en standardværdi, der gav mening. I tidligere versioner angav den, at false skulle returneres i den slags tilfælde. Det var en utilsigtet, brydende API-ændring, selvom implementeringen fungerede på samme måde som tidligere, hvis egenskabskilden implementerede IPropertySource og ikke IPropertySource2. Det er rettet i 3.1, hvor IPropertySource.isPropertySet(boolean) er ændret tilbage til den tidligere specifikation (at false skal returneres i disse tilfælde), og hvor IPropertySource2.isPropertySet(boolean) tilsidesætter denne for at angive, at true skal returneres i den slags tilfælde. Der er flere oplysninger i fejl 21756.

Påkrævet handling: Klasser, der implementerer IPropertySource eller IPropertySource2, hvor nogle af egenskaberne ikke har standardværdier, der giver mening, skal markeres for at sikre, at de returnerer den korrekte værdi for isPropertySource(boolean). Klienter skal kontrollere, at knappen Gendan standardværdi i oversigten Egenskaber fungerer som forventet for deres egenskabskilde.

13. handlerSubmission-element slettet fra org.eclipse.ui.commands-udvidelsespunktet

Hvad påvirkes: Plugins, som har brugt det eksperimenterende handlerSubmission-element, der blev indført i org.eclipse.ui.commands-udvidelsespunktet i Eclipse 3.0.

Beskrivelse: I Eclipse 3.0 blev der indført et eksperimenterende element i org.eclipse.ui.commands-udvidelsespunktet. Elementet var ment som en måde at registrere behandlere på via XML. Siden dengang er der indført en meget bedre mekanisme, org.eclipse.ui.handlers-udvidelsespunktet. Da elementet var valgte som eksperimentelt, er det nu ændret.

Påkrævet handling: Plugins, der definerer et handlerSubmission-element, skal overføres til org.eclipse.ui.commands-udvidelsespunktet.

14. Statisk, ikke-afsluttende API-felt GLOBAL_IGNORES_CHANGED i TeamUI gjort afsluttende

Hvad påvirkes: Plugins, som angav GLOBAL_IGNORES_CHANGED-feltet TeamUI.

Beskrivelse: I Eclipse 3.0 blev feltet GLOBAL_IGNORES_CHANGED tilføjet til klassen TeamUI. Feltet er en konstant, som bruges i en egenskabsændringsaktivitet for at angive, at listen over globale ignoreringer, som blev opretholdt af Team-plugin, er ændret. Felter var ikke valgte som afsluttende i 3.0, men skulle have været det. Det er gjort afsluttende i 3.1.

Påkrævet handling: Plugins, som angav ovenstående felt, kan ikke længere angive det.

15. ClassCastException vha. FillLayout

Hvad påvirkes: Plugins, som ukorrekt bruger FillLayout.

Beskrivelse: I Eclipse 3.0 blev der ikke tilknyttet layoutdata til FillLayout, og hvis et program tildelte layoutdata til et underliggende program, som blev administreret af FillLayout, blev det ignoreret. I Eclipse 3.1 er der tilføjet understøttelse til FillLayout, så det kan placere oplysninger om størrelse i cache for at forbedre ydeevnen i forbindelse med ændring af størrelse. De data, der er placeret i cache, er gemt i et FillData-objekt, som er tilknyttet hvert af de underliggende objekter, som administreres af FillLayout. Hvis et program ukorrekt har tildelt layout til et underliggende objekt, bliver der afsendt en ClassCastException, når computeSize kaldes på den overliggende objekt.

Påkrævet handling: Find eventuelle underliggende objekter i FillLayout, som har tildelt layoutdata, og lad være med at tildele flere layoutdata.

16. IllegalArgumentException afsendt. Opret et element med placeret overordnet element

Hvad påvirkes: Plugins, som opfanger undtagelser, samtidig med at de opretter elementer.

Beskrivelse: I Eclipse 3.0 var det sådan, at hvis der blev oprettet et element med et placeret overordnet element, blev der ikke afsendt en undtagelse, og elementkoden gav på et senere tidspunkt en fejl, eller der blev afsendt en SWTException med teksten "Widget Is Disposed". I Eclipse 3.1 afsender konstruktøren en IllegalArgumentException med teksten "Argument not valid", hvis der oprettes et element med et placeret overordnet element.

Påkrævet handling: Kode, som håndterer SWTException, samtidig med at der oprettes et element, skal også håndtere IllegalArgumentException.