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.
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:
String
eller et indtastet objekt. For at være en god klient skal
indstillingsændringslytteprogrammer kunne håndtere alle disse tre mulige situationer. 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.
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.
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:
IExtensionPoint
, IExtension
og IConfigurationElement
angiver nu, at InvalidRegistryObjectException
afgives, når objektet er ugyldigt. Undtagelsen er ikke valgt, så dynamiske, ikke-opmærksomme klienter tvinges ikke til at vælge den. isValid()
metode blev tilføjet til disse grænseflader, så en klient kan bestemme, om et objekt stadig er gyldigt. 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).
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.
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
.
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
.
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.
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
.
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.
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.
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.
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.
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.
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.
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.
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.