Tussen Eclipse 3.0 en 3.1 komen enige punten van incompatibiliteit voor die van invloed op plugins zijn. In de volgende secties worden de gebieden besproken die zijn gewijzigd, en de migratie van 3.0-plugins naar 3.1. U hoeft de informatie alleen te raadplegen als u problemen ondervindt met het uitvoeren van 3.0-plugins in 3.1.
Van toepassing op: plugins die de standaardwaarden voor de voorkeuren initialiseren door Plugin#initializeDefaultPreferences
te vervangen of met wijzigings-listeners werken.
Beschrijving: In Eclipse 3.1 is het object org.eclipse.jface.preference.IPreferenceStore
uit org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore
gemigreerd en in het nieuwe framework van Eclipse 3.0 uit de plugin org.eclipse.core.runtime
opgenomen.
Consequentie: Clients die de voorkeuren-API's gebruiken, moeten op twee mogelijke problemen controleren:
String
of een object met een type kan zijn. Wijzigings-listeners moeten daarom kunnen omgaan met al deze situaties. org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences
gebruikt, moet u eraan denken dat u de plugin org.eclipse.core.runtime.compatibility
opneemt in de lijst met vereist plugins, omdat deze dependency verwijderd is uit de plugin org.eclipse.ui.workbench
. Raadpleeg ook de alinea Opslagplaats voor voorkeuren JFace in het gedeelte van deze handleiding over aanbevolen wijzigingen.
Van toepassing op: plugins voor het maken, manipuleren of bewaren van IPath-objecten.
Beschrijving: In Eclipse 3.0 werd IPath gekenmerkt door een aantal beperkingen voor de padsegmenten die meer beperkend waren dan de beperkingen van het onderliggende besturingssysteem, zoals:
Deze beperkingen zijn in Eclipse 3.1 niet langer van toepassing als het besturingssysteem waarin het werkgebied is opgenomen deze beperkingen niet hanteert.
Consequentie: U kunt het uitgebreide padbereik inschakelen door alle voorvallen van Path en IPath in de plugins op te vragen en bij te werken. Het gedragspatroon van de meeste ongewijzigde plugins blijft hetzelfde voor alle paden die in 3.0 ook al waren toegestaan. Tenzij u de voorgeschreven wijzigingen aanbrengt, treden fouten op als de plugins paden bevatten die alleen in 3.1 zijn toegestaan.
Plugins voor het bewaren van tekenreekspaden die voor meerdere platforms geschikt moeten zijn, kunnen naar de factory-methode Path.fromPortableString worden gemigreerd. Deze methode geeft een instance van IPath in platformonafhankelijke indeling als resultaat. U kunt de tekenreekspaden maken met de methode IPath.toPortableString. Deze situatie is bijvoorbeeld van toepassing op de metagegevensbestanden van Eclipse-werkgebiedsprojecten (zoals PROJECT- en CLASSPATH-bestanden) en alle paden van de voorkeurenverzameling (org.eclipse.core.runtime.preferences.IPreferencesService).
Opmerking: Alle padtekenreeksen die met de methode IPath.toString van Eclipse 3.0 maar niet de methode toString van Eclipse 3.1 zijn gemaakt, worden juist gelezen door fromPortableString. In de meeste gevallen hoeft u daarom geen wijzigingen aan te brengen aan bestaande metagegevensbestanden. Zorg er wel voor dat u paden schrijft met toPortableString en leest met fromPortableString.
Plugins voor het maken van paden op basis van hardgecodeerde tekenreeksliteralen waarmee ':' en '\' als speciale tekens gelden op alle platforms, moeten worden gemigreerd. De eenvoudigste methode is het beperken van de tekenreekspadliteralen tot de subset die door alle platforms wordt ondersteund (vermijden van dubbele punten en schuine strepen naar links). Padliteralen kunnen de volledige set Unix-paden ondersteunen als u paden maakt met Path.toPortableString. In deze indeling wordt de eerste enkele dubbele punt (':') als apparaataanduiding gezien, de schuine streep naar rechts ('/') als segmentscheidingsteken en twee dubbele punten ("::") als literale dubbele punt. De instructie new Path("c:/temp") geeft een relatief pad met twee segmenten op Unix-platforms als resultaat. new Path("a\\b") geeft op Unix-platforms een pad met één segment en in Windows een pad met twee segmenten als resultaat.
Plugins die paden construeren met de methode IPath.append(String) waarbij ':' en '\' als speciale tekens voor alle platforms golden, moeten mogelijk worden bijgewerkt. In Eclipse 3.1 worden in deze methode het apparaataanduidingsteken en het segmentscheidingsteken van het besturingssysteem gebruikt voor het inlezen van de opgegeven padtekenreeks. Als u bijvoorbeeld append("a\\b") aanroept, wordt op een Unix-platform één segment toegevoegd en in Windows twee.
Voor alle gegevensbestanden die door het platform worden gelezen en verwerkt, worden ':' en '\' niet langer als speciale tekens gezien op alle platforms. Alle paden in gegevensbestanden voor meerdere platforms moeten in verwisselbare indeling zijn. Voor paden naar pictogrambestanden en andere paden in plugin.xml mag alleen '/' als scheidingsteken voor padsegmenten worden gebruikt.
Van toepassing op: plugins voor het manipuleren of behouden van IExtensionPoint
-, IExtension
- en IConfigurationElement
-objecten van de plugin of het extensieregister van het Eclipse-platform.
Beschrijving: Vóór 3.0 bleven alle objecten uit het extensieregister (het eerdere pluginregister) altijd geschikt. In Eclipse 3.0 zijn wijzigingen aangebracht, zodat plugins dynamisch kunnen worden toegevoegd of verwijderd zonder dat Eclipse opnieuw moest worden gestart. Wanneer een plugin wordt verwijderd zonder opnieuw starten, worden de verwijzingen naar de plugin in het extensieregister ongeldig. Als een plugin naar een object uit de extensieregistervermelding van de gewiste plugin verwijst, wordt het object ongeldig. Een client kon alleen van de verwijdering op de hoogte worden gebracht met behulp van een listener voor IRegistryChangeEvent
. Het probleem is niet opgelost, maar komt slechts zelden voor omdat Eclipse vrijwel altijd opnieuw wordt gestart na het verwijderen van plugins.
In 3.1 is het probleem als volgt aangepakt:
IExtensionPoint
, IExtension
en IConfigurationElement
wordt voortaan InvalidRegistryObjectException
verworpen zodra het object ongeldig is. De uitzondering is niet gemarkeerd, zodat dynamische niet op de hoogte gestelde clients niet worden gedwongen de geldigheid te controleren. isValid()
is toegevoegd aan de interfaces, zodat de geldigheid van objecten kan worden vastgesteld door clients. Consequentie: Als uw plugin dynamisch moet zijn en moet kunnen omgaan met het on-the-fly toevoegen of verwijderen van plugins, moet u de code met betrekking tot IExtensionPoint
-, IExtension
- en IConfigurationElement
-objecten uit andere plugins zodanig wijzigen dat IRegistryChangeEvent
wordt afgevangen (zoals een gecontroleerde uitzondering). Het afvangen van de uitzondering (in plaats van het opvragen van isValid()
) is de enige onfeilbare manier om het verwijderen van een plugin door een gelijktijdige thread te kunnen verwerken.
Van toepassing op: plugins voor het programmatisch opvragen van de opties van de Code Formatter voor Java.
Beschrijving: In Eclipse 3.0 waren TAB
en SPACE
de enige waarden die u voor de optie org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR
kon gebruiken. Er werd niet vermeld dat het waardetype een opsomming was, die mogelijk zou worden uitgebreid in latere versies. In Eclipse 3.1 is een derde waarde, MIXED
, toegevoegd om de programmafout 73104 aan te pakken.
Deze nieuwe waarde is opgenomen in de specificatie en meer waarden kunnen worden toegevoegd in de toekomst.
Consequentie: In clients die deze optie van de Code Formatter programmatisch opvragen of instellen, moet de code worden voorbereid op de nieuwe waarde en moeten niet-voorziene waarden netjes worden afgehandeld.
Van toepassing op: plugins die org.eclipse.ant.core.AntCorePreferences
als subklasse gebruiken of instantiëren.
Beschrijving: In Eclipse 3.0 werd niet gespecificeerd dat de klasse org.eclipse.ant.core.AntCorePreferences
niet mocht worden geïnstantieerd of niet als subklasse mocht worden gebruikt. In Eclipse 3.1 is dit scenario aangepakt en is de klasse gekenmerkt als niet beschikbaar als subklasse of niet-instantieerbaar.
Consequentie: Migreer de code van clients die een instance van org.eclipse.ant.core.AntCorePreferences
programmatisch maken, zodat de voorkeuren worden opgehaald met org.eclipse.ant.core.AntCorePlugin.getPreferences()
. org.eclipse.ant.core.AntCorePreferences
mag niet langer als subklasse worden gebruikt.
Van toepassing op: RCP-toepassingen voor vervanging van het door de workbench ingestelde JFace-logboek.
Beschrijving: In Eclipse 3.0 werd het workbenchlogboek ingesteld als logboek voor het vastleggen van JFace-fouten door het logboek van de workbenchplugin rechtstreeks door te geven aan org.eclipse.jface.util.Policy.setLog(ILog)
. In 3.1 is de dependency van ILog
verwijderd uit JFace, zodat zelfstandige toepassingen op basis van SWT en JFace buiten de runtime van Eclipse beschikbaar kunnen zijn. Er is een nieuwe interface, ILogger
, toegevoegd om aan de eisen van JFace te kunnen voldoen. De workbench is gewijzigd en biedt de interface ILogger
voor het beheren van ILog
. Raadpleeg de foutmelding 88608 voor meer informatie.
Consequentie: Voor de meeste RCP-toepassingen hoeft het door de workbench ingestelde logboek niet te worden vervangen. Als eerder echter Policy.setLog(ILog)
werd aangeroepen, moet voortaan de interface ILogger
worden doorgegeven.
Van toepassing op: RCP-toepassingen die een standaardperspectief anders dan nullverwachten.
Beschrijving: Om RCP-toepassingen te kunnen starten met een leeg venster zonder geopende perspectieven (verbetering 71150), zijn WorkbenchAdvisor.getInitialWindowPerspectiveId()
en IPerspectiveRegistry.getDefaultPerspective()
zodanig gewijzigd dat null als resultaat kan worden gegeven. In de IDE is altijd een standaardperspectief beschikbaar en dus geeft IPerspectiveRegistry.getDefaultPerspective()
niet null als resultaat. Als een bestaande RCP-toepassing eerder een waarde anders dan null gaf voor WorkbenchAdvisor.getInitialWindowPerspectiveId()
, zal IPerspectiveRegistry.getDefaultPerspective()
nog steeds een waarde anders dan null als resultaat geven.
Consequentie: Voor clients is geen actie vereist.
Van toepassing op: plugins die org.eclipse.ui.IViewLayout
implementeren.
Beschrijving: In Eclipse 3.0 werd niet gespecificeerd dat de klasse org.eclipse.ui.IViewLayout
niet mocht worden geïmplementeerd door clients. In Eclipse 3.1 is dit scenario aangepakt en is de klasse gekenmerkt als niet-implementeerbaar.
Consequentie: Alle implementerende subklassen moeten worden gereviseerd, zodat deze niet langer org.eclipse.ui.IViewLayout
implementeren.
Van toepassing op: plugins die org.eclipse.jdt.launching.IVMInstall
implementeren.
Beschrijving: In Eclipse 3.0 werd niet gespecificeerd dat de klasse org.eclipse.jdt.launching.IVMInstall
niet rechtstreeks mocht worden geïmplementeerd door clients. In Eclipse 3.1 is dit scenario aangepakt en is de klasse gekenmerkt als niet rechtstreeks implementeerbaar. Omwille van de binaire compatibiliteit kan de interface nog steeds rechtstreeks worden geïmplementeerd door clients. Het wordt echter ten zeerste aanbevolen een subklasse van org.eclipse.jdt.launching.AbstractVMInstall
te gebruiken met clients. Clients die IVMInstall
implementeren, moeten ook de nieuwe optionele interface org.eclipse.jdt.launching.IVMInstall2
implementeren, die nu wordt geïmplementeerd door AbstractVMInstall
. Het wordt voor clients aanbevolen de nieuwe interface, IVMInstall2
te implementeren om te voorkomen dat programmafout 73493 optreedt. Gebruik voor de migratie een subklasse van AbstractVMInstall
.
Consequentie: Alle implementerende klassen die org.eclipse.jdt.launching.AbstractVMInstall
nog niet als subklasse gebruiken, moeten worden gereviseerd zodat dit wel het geval is.
Van toepassing op: plugins die org.eclipse.ui.SelectionEnabler.SelectionClass
gebruiken.
Beschrijving: In Eclipse 3.0 was de geneste implementatieklasse org.eclipse.ui.SelectionEnabler.SelectionClass
openbaar, zonder beperkingen voor het gebruik ervan. In Eclipse 3.1 is dit scenario aangepakt en is de klasse zichtbaar gemaakt voor pakketten.
Consequentie: Alle klassen die org.eclipse.ui.SelectionEnabler.SelectionClass
instantiëren of uitbreiden, moeten worden gereviseerd zodat niet langer naar deze klasse wordt verwezen.
Van toepassing op: plugins die getParent()
aanroepen voor een subklasse van org.eclipse.jface.action.ContributionItem
.
Beschrijving: In Eclipse 3.0 werd voor de methode org.eclipse.jface.action.ContributionItem.getParent()
niet gespecificeerd dat deze null als resultaat kon geven. In Eclipse 3.1 is dit scenario aangepakt en wordt in de Javadoc voor de methode vermeld wanneer de methode in null kan resulteren. Raadpleeg de programmafout 92777 voor meer informatie.
Consequentie: Alle code die ContributionItem.getParent() aanroept, moet zijn voorbereid op het resultaat null.
Van toepassing op: plugins die org.eclipse.ui.views.properties.IPropertySource
of IPropertySource2
implementeren.
Beschrijving: In Eclipse 3.0 was de specificatie van de methode org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean)
onjuist gewijzigd en werd beweerd dat 'true' als resultaat werd gegeven als de opgegeven eigenschap geen betekenisvolle standaardwaarde had. In eerdere versies werd gezegd dat in dergelijke gevallen 'false' moest worden teruggegeven. Dit was een onbedoelde API-wijziging, hoewel de implementatie op dezelfde manier functioneerde als in de broncode van de eigenschap IPropertySource
werd geïmplementeerd in plaats van IPropertySource2
.
In 3.1 is het probleem gecorrigeerd en is IPropertySource.isPropertySet(boolean)
teruggezet naar de eerdere specificatie ('false' als resultaat geven voor eigenschappen zonder betekenisvolle standaardwaarden) en kan dit met IPropertySource2.isPropertySet(boolean) worden vervangen door 'true'. Raadpleeg de programmafout 21756 voor meer informatie.
Consequentie: Voor alle klassen die IPropertySource of IPropertySource2 implementeren, moet worden gecontroleerd of de juiste waarde voor isPropertySource(boolean) als resultaat wordt gegeven indien sommige eigenschappen geen betekenisvolle standaardwaarden hebben. Clients moeten controleren of de knop voor het herstellen van de standaardwaarde in de view Eigenschappen op de verwachte manier functioneert voor de broncode van de eigenschap.
Van toepassing op: plugins die het experimentele element handlerSubmission
uit het extensiepunt org.eclipse.ui.commands
van Eclipse 3.0 gebruiken.
Beschrijving: In Eclipse 3.0 werd een experimenteel element geïntroduceerd in het extensiepunt org.eclipse.ui.commands
. Het element fungeerde voor het registreren van afhandelingsroutines via XML. Er is sindsdien een veel beter extensiepunt, org.eclipse.ui.handlers
, beschikbaar. Omdat het element als experimenteel gold, is het verwijderd.
Consequentie: Alle plugins die het element handlerSubmission
definiëren, moeten migreren naar het extensiepunt org.eclipse.ui.commands
.
Van toepassing op: plugins die het veld GLOBAL_IGNORES_CHANGED van TeamUI instelden.
Beschrijving: In Eclipse 3.0 is het veld GLOBAL_IGNORES_CHANGED toegevoegd aan de klasse TeamUI. Dit veld is een constante die wordt gebruikt in wijzigings-events van eigenschappen om aan te geven dat de lijst met globale negeringen (beheerd door de Team-plugin) is gewijzigd. Dit veld werd in 3.0 niet als final gemarkeerd, hoewel dit veld het geval had moeten zijn. Sinds 3.1 is het veld alsnog final.
Consequentie: Het bovenstaande veld kan niet langer worden ingesteld door plugins.
Van toepassing op: plugins die FillLayout onjuist gebruiken.
Beschrijving: In Eclipse 3.0 werden geen layoutgegevens gekoppeld aan de FillLayout en layoutgegevens die door een toepassing werden toegewezen aan een door een FillLayout beheerd onderliggend item, werden genegeerd. In Eclipse 3.1 is ondersteuning toegevoegd voor het in de cache plaatsen van formaatgegevens door een FillLayout, zodat de prestaties op het gebied van formaatswijzigingen worden verbeterd. De cachegegevens worden bewaard in een FillData-object dat aan elke door de FillLayout beheerd onderliggend item wordt gekoppeld. Als een toepassing layoutgegevens onjuist aan een onderliggend item heeft gekoppeld, wordt de uitzondering ClassCastException verworpen zodra computeSize door het bovenliggende item wordt aangeroepen.
Consequentie: Zoek alle onderliggende items van FillLayouts waaraan layoutgegevens zijn toegewezen en stop met het toewijzen van de layoutgegevens.
Van toepassing op: plugins die uitzonderingen afvangen tijdens het maken van widgets.
Beschrijving: In Eclipse 3.0 werd geen uitzondering verworpen wanneer een widget werd gemaakt met een gewist bovenliggend item. Vervolgens traden verderop fouten op in de code van de widget of werd de uitzondering SWTException met de tekst "Widget Is Disposed" verworpen. In Eclipse 3.1 wordt de uitzondering IllegalArgumentException met de tekst "Argument not valid" verworpen door de constructor als een widget werd gemaakt met een gewist bovenliggend item.
Consequentie: Alle code die de uitzondering SWTException afhandelt bij het maken van widgets moet ook de uitzondering IllegalArgumentException afhandelen.