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.
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:
String
eller et skrevet objekt. For å være en god klient
må preferanseendringslyttere derfor kunne håndtere alle disse tre mulige situasjonene.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.
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.
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:
IExtensionPoint
, IExtension
og IConfigurationElement
oppgir nå
at det oppstår et InvalidRegistryObjectException
når objektet er ugyldig. Det er ikke merket
av for unntaket slik at klienter som ikke er klar over dette, ikke blir tvunget til å
merke av for det.isValid()
-metode ble
lagt til i disse grensesnittene slik at en klient kan bestemme om
et objekt fremdeles er gyldig.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).
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.
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
.
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.
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.
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
.
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.
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.
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.
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.
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
.
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.
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.
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.