Inkompatibiliteter mellom Eclipse 3.0 og 3.1

Eclipse ble endret slik at det oppstod inkompatibiliteter mellom 3.0 og 3.1 på måter som påvirker plugin-moduler. De følgende punktene beskriver områdene som ble endret, og de inneholder instruksjoner for migrering av plugin-moduler fra 3.0 til 3.1. Du trenger bare å se her hvis du har problemer med å kjøre plugin-moduler fra 3.0 på 3.1.

  1. Plugin-preferanser
  2. Endringer i IPath-begrensninger
  3. Utvidelsesregister
  4. Alternativer for kodeformaterer
  5. Endringer i API-kontrakten for AntCorePreferences
  6. Endringer i API-kontrakten for Policy-klassen i JFace
  7. Endringer i API-kontrakten for å tillate et nullstandardperspektiv
  8. Endringer i API-kontrakten for IViewLayout
  9. Endringer i API-kontrakten for IVMInstall
  10. SelectionEnabler.SelectionClass er gjort pakkesynlig
  11. ContributionItem.getParent() kan returnere null
  12. Endringer for isPropertySet(boolean) i IPropertySource og IPropertySource2
  13. handlerSubmission-element er slettet fra utvidelsespunktet org.eclipse.ui.commands
  14. Det statiske, ikke-endelige API-feltet GLOBAL_IGNORES_CHANGED i TeamUI er gjort endelig
  15. ClassCastException bruker FillLayout
  16. Oppretting av en widget med en fjernet overordnet

1. Plugin-preferanser

Dette påvirkes: Plugin-moduler som initialiserer standard preferanseverdier for plugin-moduler ved å overstyre Plugin#initializeDefaultPreferences eller bruke preferanseendringslyttere.

Beskrivelse: I Eclipse 3.1 er objektet org.eclipse.jface.preference.IPreferenceStore, som kommer fra org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore, migrert for å ligge øverst i det nye preferanserammeverket for Eclipse 3.0 som leveres av plugin-modulen org.eclipse.core.runtime.

Nødvendig handling: Som et resultat skal klienter som bruker preferanse-APIene, kontrollere to saker:

  1. Hvilken type objekter som ligger i preferanseendringshendelsene, garanteres ikke. Både den gamle verdien og den nye verdien i hendelser kan være null, en String eller et skrevet objekt. For å være en god klient må preferanseendringslyttere derfor kunne håndtere alle disse tre mulige situasjonene.
  2. Hvis plugin-modulen bruker org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences, må du ta med plugin-modulen org.eclipse.core.runtime.compatibility i din plugin-moduls liste over nødvendige plugin-moduler, fordi denne avhengigheten er fjernet fra plugin-modulen org.eclipse.ui.workbench.

Se også avsnittet JFace Preference Store i seksjonen om anbefalte endringer i denne veiledningen.

2. Endringer i IPath-begrensninger

Dette påvirkes: Plugin-moduler som oppretter, endrer eller lagrer IPath-objekter.

Beskrivelse: I Eclipse 3.0 hadde IPath flere begrensninger for segmentene av baner som var mer restriktive enn restriksjonene for det underliggende operativsystemet. Disse omfattet:

Disse begrensningene er fjernet i Eclipse 3.1 fordi plattformens dataplassering (arbeidsområde) er i et filsystem som ikke har disse begrensningene.

Nødvendig handling: For å aktivere den riktige behandlingen av det utvidede området med baner, bør du gå gjennom og oppdatere all bruk av Path og IPath i plugin-modulene slik det er beskrevet nedenfor. De fleste uendrede plugin-moduler vil fortsette å fungere nøyaktig som i 3.0 i alle baner som vurderes som lovlige i 3.0. Med mindre disse bestemte endringene er gjort, er det imidlertid sannsynlig at de mislykkes i tilfeller som omfatter baner som vurderes som lovlige i 3.1, men som var ulovlige i 3.0.

Plugin-moduler som lagrer strengrepresentasjoner av baner i et format som må være lesbart på flere plattformer, bør migreres til den nye factory-metoden Path.fromPortableString. Denne metoden produserer en IPath-forekomst fra et plattformuavhengig format. Denne strengrepresentasjonen av baner kan opprettes ved hjelp av metoden IPath.toPortableString. Eksemplene på påvirkede metadatafiler omfatter filer som lagres i Eclipse-arbeidsområdeprosjekter (.project, .classpath etc.), og alle baner som er lagret i preferanselageret (org.eclipse.core.runtime.preferences.IPreferencesService).

Merk: fromPortableString utfører en riktig lesing av alle banestrenger som er opprettet ved hjelp av IPath.toString-metoden fra Eclipse 3.0, men ikke toString-metoden for Eclipse 3.1. I de fleste tilfeller er det dermed ikke nødvendig med noen endring i de eksisterende metadatafilformatene, bortsett fra å begynne å skrive baner med toPortableString og lese baner med fromPortableString.

Plugin-moduler som opprettet baner fra hardkodede strengkonstanter som forventet : og \, hadde spesialbetydning på alle plattformer, og må migreres. Den enkleste løsningen er å begrense strengbanekonstanter til delsettet som støttes på alle plattformer (unngå kolon og omvendt skråstrek). Banekonstanter kan støtte hele settet av gyldige Unix-baner ved å bruke det flyttbare banestrengformatet som produseres av Path.toPortableString. Dette formatet tolker det første enkeltkolonet (:) som enhetsskilletegn, skråstrek (/) som segmentskilletegn og dobbeltkolon (::) som et konstantkolontegn. Koden new Path("c:/temp") oppretter for eksempel en relativ bane med to segmenter på Unix-plattformer. På liknende måte oppretter new Path("a\\b") en bane med ett enkelt segment på Unix-plattformer, og en bane med to segmenter i Windows.

Plugin-moduler som konstruerer baner ved hjelp av metoden IPath.append(String) som forventet ':' og '\', og hadde spesialbetydning på alle plattformer, kan trenge å oppdatere koden. I Eclipse 3.1 bruker denne metoden operativsystemspesifikke enhets- og segmentskilletegn til å tolke den oppgitte banestrengen. Et kall til append("a\\b") på Unix-plattformer vil for eksempel tilføye ett enkelt segment, mens i Windows vil det fortsatt bli tilføyd to segmenter.

Datafiler som leses og tolkes av plattformen, behandler ikke lenger ':' og '\' som spesialtegn på alle plattformer. Alle baner som er lagret i datafiler som kan leses på flere plattformer, må være i flyttbar form. For eksempel må baner til ikonfiler og andre baner i plugin.xml bare bruke '/' som segmentskilletegn for baner.

3. Utvidelsesregister

Dette påvirkes: Plugin-moduler som manipulerer eller beholder IExtensionPoint-, IExtension- og IConfigurationElement-objekter fra Eclipse-plattformens plugin-modul eller utvidelsesregister.

Beskrivelse: Før 3.0 var alle objekter som ble skaffet fra utvidelsesregisteret (for det tidligere plugin-registeret), brukbare til evig tid. Det ble gjort endringer i Eclipse 3.0 som tillot at plugin-moduler kunne legges til eller fjernes dynamisk uten at Eclipse måtte startes på nytt. Når en plugin-modul blir fjernet uten omstart, blir plugin-modulens oppføringer i utvidelsesregisteret nødvendigvis ugyldige. Det betyr at en annen plugin-modul som oppbevarer et objekt som tidligere ble skaffet fra den slettede plugin-modulens utvidelsesregisteroppføring, vil oppbevare et ugyldig objekt. Det eneste hintet en klient får, vil komme fra å lytte til IRegistryChangeEvent. Problemet har eksistert siden Eclipse 3.0, men har sjelden blitt funnet i praksis, fordi det er svært usannsynlig at en plugin-modul blir fjernet uten at Eclipse startes på nytt.

Dette problemet er behandlet i 3.1 på denne måten:

Nødvendig handling: Hvis plugin-modulen må være dynamisk oppmerksom (det vil si i stand til å utføre umiddelbar tilføying eller fjerning av plugin-moduler), må koden som behandler IExtensionPoint-, IExtension- og IConfigurationElement-objekter fra en annen plugin-modul, endres slik at IRegistryChangeEvent oppfattes, som det var et merket unntak. Oppfanging av unntaket (i stedet for forhåndsmerking av isValid()) er den eneste sikre metoden for å behandle tilfellet der en plugin-modul blir fjernet av en samtidig tråd (som, hvis det skjer, den nesten sikkert vil).

4. Alternativer for kodeformaterer

Dette påvirkes: Plugin-moduler som får programmatisk tilgang til alternativene for Java-kodeformatereren.

Beskrivelse: I Eclipse 3.0 kan verdiene for kodeformatereralternativet org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR bare være TAB eller SPACE. Spesifikasjonen nevnte ikke eksplisitt at verditypen var en oppregning som kan vokse i fremtidige utgaver. I Eclipse 3.1 ble det lagt til en tredje mulig verdi, MIXED, for å adressere programfeil 73104. Spesifikasjonen er endret slik at den inkluderer denne nye verdien, og slik at den tillater at det blir lagt til flere verdier i fremtiden.

Nødvendig handling: Klienter som programmatisk leser eller definerer dette kodeformatereralternativet, bør kontrollere om koden tar hensyn til den nye tredje verdien, og sikre at den er skrevet på en måte som mislykkes med stil hvis det noen gang dukker opp en alternativverdi som ikke er forventet.

5. Endringer i API-kontrakten for AntCorePreferences

Dette påvirkes: Plugin-moduler som oppretter subklasse eller forekomst av org.eclipse.ant.core.AntCorePreferences.

Beskrivelse: I Eclipse 3.0 var det ikke merket av for klassen org.eclipse.ant.core.AntCorePreferences slik at klienter ikke kunne opprette forekomst eller en subklasse av den. Dette var en feil som er rettet i Eclipse 3.1, der klassen er merket som ikke beregnet på oppretting av subklasse eller forekomst.

Nødvendig handling: Klienter som programmatisk oppretter en forekomst av org.eclipse.ant.core.AntCorePreferences, må migrere koden for å hente preferansen ved hjelp av org.eclipse.ant.core.AntCorePlugin.getPreferences(). En hvilken som helst subklasse må omarbeides slik at den ikke lenger oppretter subklasse av org.eclipse.ant.core.AntCorePreferences.

6. Endringer i API-kontrakten for Policy-klassen i JFace

Dette påvirkes: RCP-applikasjoner som overstyrer JFace-loggen som er definert av arbeidsbenken.

Beskrivelse: I Eclipse 3.0 definerte arbeidsbenken arbeidsbenkens logg som den loggen som skal brukes til å loggføre JFace-feil, ved å sende arbeidsbenk-plugin-modulens logg direkte til org.eclipse.jface.util.Policy.setLog(ILog). I 3.1 er avhengigheten med ILog fjernet fra JFace for å aktivere frittstående applikasjoner som bruker SWT og JFace utenfor Eclipse-kjøretiden. Det nye grensesnittet, ILogger, er introdusert for å oppfylle behovene fra JFace. Arbeidsbenken er endret slik at den leverer en ILogger-wrapping for arbeidsbenkens ILog. Hvis du vil ha mer informasjon, kan du lese om feil 88608.

Nødvendig handling: De fleste RCP-applikasjoner trenger ikke å overstyre loggen som er definert av arbeidsbenken, men hvis de tidligere sendte kall til Policy.setLog(ILog), må de endres til å sende en ILogger i stedet.

7. Endringer i API-kontrakten for å tillate et nullstandardperspektiv

Dette påvirkes: RCP-applikasjoner som forventer et standardperspektiv som ikke er null.

Beskrivelse: For å tillate at RCP-applikasjoner starter med et tomt vindu uten åpne perspektiver (forbedring 71150), er WorkbenchAdvisor.getInitialWindowPerspectiveId() og IPerspectiveRegistry.getDefaultPerspective() endret slik at det er tillatt at null beholdes. I IDE finnes det alltid et standardperspektiv, så IPerspectiveRegistry.getDefaultPerspective() vil ikke returnere null. På liknende måte, hvis en eksisterende RCP-applikasjon tidligere returnerte en ikke-nullverdi fra WorkbenchAdvisor.getInitialWindowPerspectiveId(), vil IPerspectiveRegistry.getDefaultPerspective() fremdeles ikke returnere en ikke-nullverdi.

Nødvendig handling: Ingen handling bør være nødvendig for klienter.

8. Endringer i API-kontrakten for IViewLayout

Dette påvirkes: Plugin-moduler som implementerer org.eclipse.ui.IViewLayout.

Beskrivelse: I Eclipse 3.0 var klassen org.eclipse.ui.IViewLayout ikke merket for at klienter ikke kan implementere. Dette var en feil som er rettet i Eclipse 3.1, der klassen er merket som ikke beregnet på implementering av klienter.

Nødvendig handling: Hvilke som helst implementerende klasser må omarbeides slik at de ikke lenger implementerer org.eclipse.ui.IViewLayout.

9. Endringer i API-kontrakten for IVMInstall

Dette påvirkes: Plugin-moduler som implementerer org.eclipse.jdt.launching.IVMInstall.

Beskrivelse: I Eclipse 3.0 var klassen org.eclipse.jdt.launching.IVMInstall ikke merket for at klienter ikke kan implementere direkte. Dette var en feil som er rettet i Eclipse 3.1, der klassen er merket som ikke beregnet på direkte implementering av klienter. For å opprettholde binær kompatibilitet, er det fremdeles tillatt for klienter å implementere grensesnittet direkte, men det anbefales på det sterkeste at klienter oppretter subklasse av org.eclipse.jdt.launching.AbstractVMInstall i stedet. Klienter som implementerer IVMInstall, bør også implementere det nye valgfrie grensesnittet org.eclipse.jdt.launching.IVMInstall2, som AbstractVMInstall nå implementerer. Det anbefales at klienter som implementerer det nye grensesnittet, IVMInstall2, unngår problemet som beskrives i feil 73493. Den anbefalte migreringen er å opprette subklasse av AbstractVMInstall.

Nødvendig handling: Alle implementerende klasser som ikke allerede oppretter subklasse av org.eclipse.jdt.launching.AbstractVMInstall, bør omarbeides slik at de oppretter subklasse av org.eclipse.jdt.launching.AbstractVMInstall.

10. SelectionEnabler.SelectionClass er gjort pakkesynlig

Dette påvirkes: Plugin-moduler som bruker org.eclipse.ui.SelectionEnabler.SelectionClass.

Beskrivelse: I Eclipse 3.0 var den nestede implementeringsklassen org.eclipse.ui.SelectionEnabler.SelectionClass felles, uten begrensninger i bruken. Dette var en feil som er rettet i Eclipse 3.1, der klassen er gjort pakkesynlig.

Nødvendig handling: Alle klasser som oppretter forekomst av eller utvider org.eclipse.ui.SelectionEnabler.SelectionClass, må omarbeides slik at de ikke lenger refererer til denne klassen.

11. ContributionItem.getParent() kan returnere null

Dette påvirkes: Plugin-moduler som sender kall til getParent() i en subklasse av org.eclipse.jface.action.ContributionItem.

Beskrivelse: I Eclipse 3.0 oppgav ikke metoden org.eclipse.jface.action.ContributionItem.getParent() at den kunne returnere null. Dette var en feil som er rettet i Eclipse 3.1, der Javadoc for metoden klargjør når den kan returnere null. Hvis du vil ha mer informasjon, kan du lese om feil 92777.

Nødvendig handling: En hvilken som helst kode som sender kall til ContributionItem.getParent(), må kunne håndtere et nullresultat.

12. Endringer for isPropertySet(boolean) i IPropertySource og IPropertySource2

Dette påvirkes: Plugin-moduler som implementerer org.eclipse.ui.views.properties.IPropertySource eller IPropertySource2.

Beskrivelse: I Eclipse 3.0 var spesifikasjonen for metoden org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) feilaktig endret til å oppgi at det skal returneres true hvis den oppgitte egenskapen ikke har en meningsfull standardverdi. I tidligere versjoner oppgav den at false skulle returneres i dette tilfellet. Dette var en utilsiktet API-endring, selv om implementeringen fungerte på samme måte som før, hvis egenskapskilden implementerte IPropertySource, og ikke IPropertySource2. Dette er rettet i 3.1, der IPropertySource.isPropertySet(boolean) er satt tilbake til den tidligere spesifikasjonen (at det skal returneres false i dette tilfellet), og IPropertySource2.isPropertySet(boolean) overstyrer dette for å oppgi at det skal returneres true i dette tilfellet. Hvis du vil ha mer informasjon, kan du lese om feil 21756.

Nødvendig handling: Alle klasser som implementerer IPropertySource eller IPropertySource2, der noen av egenskapene ikke har meningsfulle standardverdier, bør kontrolleres for å sikre at de returnerer de riktige verdiene for isPropertySource(boolean). Klienter bør kontrollere at knappen Gjenopprett standardverdi i egenskapsvisningen fungerer som forventet for deres egenskapskilde.

13. handlerSubmission-element er slettet fra utvidelsespunktet org.eclipse.ui.commands

Dette påvirkes: Plugin-moduler som brukte det eksperimentelle handlerSubmission-elementet som ble introdusert i utvidelsespunktet org.eclipse.ui.commands i Eclipse 3.0.

Beskrivelse: I Eclipse 3.0 ble det introdusert et eksperimentelt element i utvidelsespunktet org.eclipse.ui.commands. Dette elementet var ment som en metode for å registrere behandlere gjennom XML. Siden den gang, er det introdusert en langt bedre mekanisme, utvidelsespunktet org.eclipse.ui.handlers. Siden elementet var merket som eksperimentelt, er det nå fjernet.

Nødvendig handling: Alle plugin-moduler som definerer et handlerSubmission-element, bør migrere til utvidelsespunktet org.eclipse.ui.commands.

14. Det statiske, ikke-endelige API-feltet GLOBAL_IGNORES_CHANGED i TeamUI er gjort endelig

Dette påvirkes: Plugin-moduler som definerte feltet GLOBAL_IGNORES_CHANGED for TeamUI.

Beskrivelse: I Eclipse 3.0 ble feltet GLOBAL_IGNORES_CHANGED lagt til i TeamUI-klassen. Dette feltet er en konstant som brukes i en egenskapsendringshendelse til å oppgi at listen over globale ignoreringer som vedlikeholdes av plugin-modulen Team, er endret. Dette feltet var ikke merket som endelig i 3.0, noe det skulle ha vært. Det er gjort endelig i 3.1.

Nødvendig handling: Alle plugin-moduler som definerte feltet ovenfor, kan ikke lenger gjøre det.

15. ClassCastException bruker FillLayout

Dette påvirkes: Plugin-moduler som bruker FillLayout feilaktig.

Beskrivelse: I Eclipse 3.0 ble ingen layoutdata knyttet til FillLayout, og hvis en applikasjon tilordnet layoutdata til en underordnet som ble styrt av en FillLayout, ble de ignorert. I Eclipse 3.1 ble det lagt til støtte i FillLayout for å hurtigbufre størrelsesinformasjon slik at ytelsen ved størrelsesendring kunne forbedres. De hurtigbufrede dataene lagres i et FillData-objekt som er knyttet til hver underordnede som styres av FillLayout. Hvis en applikasjon har feilaktig tilordnet layoutdata til en underordnet, oppstår et ClassCastException når det sendes kall til computeSize i den overordnede.

Nødvendig handling: Finn alle underordnede i en FillLayout som har tilordnede layoutdata, og slutt å tildele layoutdataene.

16. IllegalArgumentException oppstod ved oppretting av en widget med en fjernet overordnet

Dette påvirkes: Plugin-moduler med unntak ved oppretting av widgeter.

Beskrivelse: Hvis det ble opprettet en widget med en fjernet overordnet i Eclipse 3.0, oppstod det ikke et unntak, og widget-koden mislyktes senere eller det oppstod et SWTException med tekst om at widget er slettet. Hvis en widget opprettes i Eclipse 3.1 med en slettet overordnet, vil konstruktøren gi et IllegalArgumentException med tekst om at argumentet er ugyldig.

Nødvendig handling: All kode som håndterer SWTException ved oppretting av en widget, må også håndtere IllegalArgumentException.