Eclipse è stato modificato tra le versioni 3.0 e 3.1 in modi incompatibili che influiscono sui plugin. Le sezioni di seguito riportate descrivono le aree modificate e forniscono istruzioni per la migrazione dei plugin dalla versione 3.0 alla versione 3.1. È opportuno fare riferimento a queste sezioni solo se si verificano problemi durante l'esecuzione del plugin 3.0 su 3.1.
Elementi interessati: i plugin che inizializzano i propri valori di preferenza
predefiniti sovrascrivendo Plugin#initializeDefaultPreferences
o che utilizzano listener di
modifica preferenze.
Descrizione: in Eclipse 3.1 l'oggetto org.eclipse.jface.preference.IPreferenceStore
ottenuto da org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore
è stato migrato per poter
essere utilizzato sul nuovo framework delle preferenze di Eclipse 3.0
fornito dal plugin org.eclipse.core.runtime
.
Azione richiesta: in conseguenza di ciò, i client che utilizzano le API delle preferenze devono controllare due possibili problemi:
String
oppure un oggetto con tipo. Quindi, i listener di modifica preferenze devono essere in grado di
gestire tutte e tre le possibili situazioni.org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences
, è necessario verificare che
il plugin org.eclipse.core.runtime.compatibility
sia incluso nell'elenco di plugin richiesti, in quanto questa
dipendenza è stata rimossa dal plugin org.eclipse.ui.workbench
.Per informazioni più dettagliate, vedere la sezione consultare la documentazione relativa all'archivio delle preferenze.
Elementi interessati: i plugin che creano, gestiscono o archiviano gli oggetti IPath.
Descrizione: in Eclipse 3.0, IPath presentava numerose limitazioni sui segmenti di percorso, che erano più restrittive rispetto al sistema operativo sottostante. Queste limitazioni includevano:
Queste limitazioni sono state rimosse in Eclipse 3.1, quando il percorso dei dati (spazio di lavoro) della piattaforma si trova in un file system che non presenta tali limitazioni.
Azione richiesta: per abilitare il trattamento corretto della gamma di percorsi espansa, l'uso di Path e IPath all'interno dei plugin dovrebbe essere riesaminato ed aggiornato in base alle indicazioni riportate di seguito. La maggior parte dei plugin non modificati continueranno a comportarsi come nella versione 3.0 per i percorsi ammessi in 3.0. Tuttavia, se non sono effettuate le modifiche indicate, potrebbero terminare in errore nel caso di percorsi ammessi nella versione 3.1 che erano non ammessi in 3.0.
I plugin che archiviano le rappresentazioni in stringa dei percorsi in un formato che può essere letto su più piattaforme diverse, devono migrare al nuovo metodo factory Path.fromPortableString. Questo metodo crea un'istanza IPath da un formato indipendente dalla piattaforma. Questa rappresentazione in stringa dei percorsi può essere creata utilizzando il metodo IPath.toPortableString. Esempi di file di metadati interessati sono quelli archiviati all'interno dei progetti dello spazio di lavoro Eclipse (.project, .classpath, ecc.) e tutti i percorsi archiviati in un archivio delle preferenze (org.eclipse.core.runtime.preferences.IPreferencesService).
Nota: fromPortableString leggerà correttamente tutte le stringhe di percorso create utilizzando il metodo IPath.toString di Eclipse 3.0, ma non il metodo toString di Eclipse 3.1. Quindi, nella maggior parte dei casi non è richiesta alcuna modifica ai formati di file di metadati esistenti, tranne che per la scrittura di percorsi con toPortableString e la lettura di percorsi con fromPortableString.
I plugin che creavano percorsi da letterali di stringa fissi che consideravano ':' e '\' come caratteri a significato speciale su tutte le piattaforme devono essere migrati. La soluzione migliore è quella di limitare i letterali stringa di percorso ad un sottoinsieme che sia supportato su tutte le piattaforme (evitare i caratteri due punti e barra retroversa). I letterali di percorso possono supportare l'insieme completo di percorsi Unix validi, utilizzando il formato di stringa di percorso portabile generato da Path.toPortableString. Questo formato interpreta il primo carattere due punti (':') come separatore di dispositivo, barra ('/') come separatore di segmento e un doppio due punti ("::") come carattere due punti letterale. Ad esempio, il codice new Path("c:/temp") creerà ora un percorso relativo con due segmenti su piattaforme Unix. In modo simile, new Path("a\\b") creerà ora un percorso con un solo segmento su piattaforme Unix e un percorso con due segmenti su Windows.
I plugin che costruiscono i percorsi utilizzando il metodo IPath.append(String) che considerava ':' e '\' come caratteri a significato speciale su tutte le piattaforme devono aggiornare il proprio codice. In Eclipse 3.1, questo metodo utilizza delimitatori di segmento e di dispositivo specifici del sistema operativo per interpretare la stringa di percorso fornita. Ad esempio, richiamando append("a\\b") su piattaforme Unix ora si accoderà un solo segmento, mentre su Windows si accoderanno due segmenti.
I file di dati letti e interpretati dalla piattaforma non tratteranno più ':' e '\' come caratteri speciali su tutte le piattaforme. Tutti i percorsi archiviati in file di dati che possono essere letti su più piattaforme devono essere in formato trasferibile. Ad esempio, i percorsi di file di icona e gli altri percorsi in plugin.xml devono utilizzare solo '/' come separatore del segmento di percorso.
Elementi interessati: i plugin che gestiscono o mantengono gli oggetti IExtensionPoint
,
IExtension
e IConfigurationElement
dal plugin o dal registro delle estensioni della piattaforma Eclipse.
Descrizione: prima della versione 3.0, tutti gli oggetti ottenuti dal registro delle estensioni (del precedente registro plugin)
rimanevano validi per sempre. In Eclipse 3.0 erano state effettuate modifiche per consentire l'aggiunta e rimozione dinamica dei plugin
senza dover riavviare Eclipse. Quando si rimuove un plugin senza riavviare, le relative voci nel registro delle estensioni diventano
necessariamente non valide. Di conseguenza, un altro plugin in attesa di un oggetto precedentemente ottenuto dalla voce del registro delle
estensioni del plugin eliminato, verrebbe lasciato in attesa di un oggetto non valido. Il solo suggerimento per un client sarebbe di
restare in attesa di IRegistryChangeEvent
.
Il problema esisteva da Eclipse 3.0, ma si verificava raramente nella pratica perché è inusuale rimuovere un plugin senza riavviare Eclipse.
Il problema è stato risolto nella versione 3.1 nel modo seguente:
IExtensionPoint
, IExtension
e IConfigurationElement
specificano ora che
verrà generata una InvalidRegistryObjectException
quando l'oggetto non è valido. L'eccezione non è controllata, in modo che
i client non siano obbligati a verificarla.isValid()
a queste interfacce in modo che il client possa determinare se un oggetto è
ancora valido.Azione richiesta: se il plugin deve supportare la gestione dinamica (ovvero, gestire correttamente l'aggiunta o la rimozione
improvvisa dei plugin) il codice relativo agli oggetti IExtensionPoint
, IExtension
e IConfigurationElement
presente nell'origine di altri plugin deve essere modificato per rilevare IRegistryChangeEvent
, esattamente come se fosse
un'eccezione controllata. La rilevazione dell'eccezione (piuttosto che il controllo anticipato di isValid()
) è il solo modo
sicuro di gestire la situazione in cui un plugin viene rimosso da un thread simultaneo.
Elementi interessati: i plugin che accedono alle opzioni del programma di formattazione del codice Java.
Descrizione: in Eclipse 3.0, i valori dell'opzione del programma di formattazione del codice
org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR
potevano solo essere TAB
o
SPACE
. Le specifiche fornite non dichiaravano esplicitamente che il tipo di valore era un'enumerazione, che poteva cambiare in
futuri release. In Eclipse 3.1, è stato aggiunto un terzo valore possibile, MIXED
, per risolvere il
problema 73104.
Le specifiche sono state modificate per aggiungere questo nuovo valore e per consentire l'aggiunta di altri valori in futuro.
Azione richiesta: i client che leggono o impostano da programma questa opzione del programma di formattazione del codice devono verificare il codice per considerare il nuovo terzo valore e per assicurarsi di gestire senza problemi un eventuale valore dell'opzione non ancora previsto.
Elementi interessati: i plugin che creano sottoclassi o istanze di org.eclipse.ant.core.AntCorePreferences
.
Descrizione: in Eclipse 3.0, la classe org.eclipse.ant.core.AntCorePreferences
non indicava che i client non
potevano creare un'istanza o una sottoclasse.
Questa omissione è stata risolta in Eclipse 3.1, la classe è contrassegnata come una classe che non ammette sottoclassi o istanze.
Azione richiesta: i client che creano da programma un'istanza di org.eclipse.ant.core.AntCorePreferences
devono migrare il codice per richiamare le preferenze utilizzando org.eclipse.ant.core.AntCorePlugin.getPreferences()
.
Le sottoclassi devono essere rielaborate per non essere più sottoclassi di org.eclipse.ant.core.AntCorePreferences
.
Elementi interessati: le applicazioni RCP che sovrascrivono il log JFace impostato dal workbench.
Descrizione: in Eclipse 3.0, il workbench impostava il log del workbench come log per la registrazione degli errori JFace,
passando il log del plugin del workbench direttamente a org.eclipse.jface.util.Policy.setLog(ILog)
. In
3.1, la dipendenza da ILog
è stata rimossa da JFace allo scopo di consentire applicazioni autonome che utilizzano SWT e JFace
al di fuori del runtime Eclipse. È stata introdotta una nuova interfaccia, ILogger
, per soddisfare i requisiti di JFace. Il
workbench è stato modificato per fornire un ILogger
che include ILog
del workbench. Per ulteriori dettagli, fare
riferimento al problema 88608.
Azione richiesta: la maggior parte delle applicazioni RCP non devono sovrascrivere il log impostato dal workbench, ma se in
precedenza richiamavano Policy.setLog(ILog)
, è necessario modificarle per passare invece ILogger
.
Elementi interessati: le applicazioni RCP che si aspettano una prospettiva predefinita non null.
Descrizione: per consentire alle applicazioni RCP di essere avviate con una finestra vuota senza una prospettiva aperta
(miglioramento 71150),
WorkbenchAdvisor.getInitialWindowPerspectiveId()
e IPerspectiveRegistry.getDefaultPerspective()
sono stati
modificati per consentire di restituire null. In IDE, c'è sempre una prospettiva predefinita, quindi
IPerspectiveRegistry.getDefaultPerspective()
non restituirà null. In modo simile, se un'applicazione RCP esistente restituiva in
precedenza un valore non null da WorkbenchAdvisor.getInitialWindowPerspectiveId()
,
IPerspectiveRegistry.getDefaultPerspective()
restituirà ancora un valore non null.
Azione richiesta: non è richiesta alcuna azione da parte dei client.
Elementi interessati: i plugin che implementano org.eclipse.ui.IViewLayout.
Descrizione: in Eclipse 3.0, la classe org.eclipse.ui.IViewLayout
non indicava che non poteva essere implementata
dai client. Questa omissione è stata risolta in Eclipse 3.1, la classe è contrassegnata come una classe che non ammette
implementazioni dei client.
Azione richiesta: le classi di implementazione devono essere rielaborate per non implementare più
org.eclipse.ui.IViewLayout
.
Elementi interessati: i plugin che implementano org.eclipse.jdt.launching.IVMInstall.
Descrizione: in Eclipse 3.0, la classe org.eclipse.jdt.launching.IVMInstall
non indicava che non poteva essere implementata
dai client. Questa omissione è stata risolta in Eclipse 3.1, la classe è contrassegnata come una classe che non ammette implementazioni
dirette dei client. Per mantenere la compatibilità binaria, ai client viene ancora consentito di implementare
direttamente l'interfaccia, ma è fortemente consigliato l'utilizzo di una sottoclasse di
org.eclipse.jdt.launching.AbstractVMInstall
. I client che implementano IVMInstall
dovrebbero anche implementare la nuova interfaccia facoltativa
org.eclipse.jdt.launching.IVMInstall2
, che è ora implementata da AbstractVMInstall
. Si
consiglia l'implementazione da parte dei client della nuova interfaccia IVMInstall2
, per evitare
il problema noto 73493. Si consiglia la migrazione alla sottoclasse di
AbstractVMInstall
.
Azione richiesta: le classi di implementazione che non creano già sottoclassi di
org.eclipse.jdt.launching.AbstractVMInstall
devono essere rielaborate per creare una sottoclasse
di org.eclipse.jdt.launching.AbstractVMInstall.
Elementi interessati: i plugin che utilizzano org.eclipse.ui.SelectionEnabler.SelectionClass.
Descrizione: in Eclipse 3.0, la classe di implementazione nidificata
org.eclipse.ui.SelectionEnabler.SelectionClass
era pubblica, senza limitazioni al suo utilizzo. Questa omissione è stata
risolta in Eclipse 3.1, la classe è visibile nel pacchetto.
Azione richiesta: le classi che creavano istanze o estensioni di
org.eclipse.ui.SelectionEnabler.SelectionClass
devono essere rielaborate per non fare più
riferimento a questa classe.
Elementi interessati: i plugin che richiamano getParent()
per una sottoclasse di org.eclipse.jface.action.ContributionItem.
Descrizione: in Eclipse 3.0, il metodo org.eclipse.jface.action.ContributionItem.getParent()
non specificava
che poteva essere restituito un valore null. Questa omissione è stata risolta in Eclipse 3.1, Javadoc per il metodo dichiara che il valore
restituito può essere null. Per ulteriori dettagli, fare riferimento al problema
92777.
Azione richiesta: il codice che richiama ContributionItem.getParent() deve assicurare la gestione di un risultato null.
Elementi interessati: i plugin che implementano org.eclipse.views.properties.IPropertySource
o IPropertySource2.
Descrizione: in Eclipse 3.0, la specifica del metodo org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean)
era stata modificata in modo non corretto per specificare un valore di restituzione true se la proprietà specificata non presentava un
valore predefinito significativo. Nelle precedenti versioni, era stato specificato che in questo casi doveva essere restituito false. Questo
è stata una modifica involontaria dell'API, anche se l'implementazione aveva un funzionamento corretto quando l'origine della proprietà
implementava IPropertySource
invece di IPropertySource2
.
Questa situazione è stata corretta nella versione 3.1,
con IPropertySource.isPropertySet(boolean)
che è tornato alla specifica precedente (deve essere restituito false in questo
caso) e IPropertySource2.isPropertySet(boolean) che lo sovrascrive specificando che deve essere restituito true in questo caso. Per ulteriori dettagli, fare
riferimento al problema 21756.
Azione richiesta: le classi che implementano IPropertySource o IPropertySource2, in cui alcune delle proprietà presentano valori predefiniti significativi, devono essere verificate per assicurarsi che restituiscano il valore opportuno per isPropertySource(boolean). I client dovrebbero verificare che il pulsante Ripristina i valori predefiniti nella vista Proprietà abbia il funzionamento previsto per le relative origini delle proprietà.
Elementi interessati: i plugin che utilizzano l'elemento sperimentale
handlerSubmission
introdotto nel punto di estensione
org.eclipse.ui.commands
di Eclipse 3.0.
Descrizione: in Eclipse 3.0, era stato introdotto un elemento sperimentale
nel punto di estensione org.eclipse.ui.commands
. Questo elemento era considerato un modo di
registrare i gestori tramite XML. Da allora, è stato introdotto un meccanismo superiore, il punto di
estensione org.eclipse.ui.handlers
. Dal momento che l'elemento era contrassegnato come
sperimentale, adesso è stato rimosso.
Azione richiesta: i plugin che definiscono un elemento handlerSubmission
devono
migrare al punto di estensione org.eclipse.ui.commands
.
Elementi interessati: i plugin che impostavano il campo GLOBAL_IGNORES_CHANGED di TeamUI.
Descrizione: in Eclipse 3.0, il campo GLOBAL_IGNORES_CHANGED era stato aggiunto alla classe TeamUI. Questo campo è una costante che viene utilizzata in un evento di modifica proprietà per indicare che l'elenco di esclusione globale gestito dal plugin Team è stato modificato. Questo campo non era contrassegnato come finale in 3.0, ma avrebbe dovuto. È stato reso finale in 3.1.
Azione richiesta: i plugin che impostavano questo campo non possono più eseguire questa azione.
Elementi interessati: i plugin che utilizzano in modo non corretto FillLayout.
Descrizione: in Eclipse 3.0, a FillLayout non erano associati dati di layout, e se un'applicazione assegnava dati di layout ad un elemento secondario gestito da FillLayout, questi erano ignorati. In Eclipse 3.1, è stato aggiunto il supporto a FillLayout per mettere in cache le informazioni di dimensione allo scopo di migliorare le prestazioni nel ridimensionamento. I dati in cache sono archiviati nell'oggetto FillData associato ad ogni elemento secondario gestito da FillLayout. Se un'applicazione assegna erroneamente dati di layout ad un elemento secondario, viene generata una ClassCastException quando si richiama computeSize sull'elemento principale.
Azione richiesta: individuare gli elementi secondari di un FillLayout ai quali sono assegnati dati di layout e interrompere l'assegnazione di dati di layout.
Elementi interessati: i plugin che rilevano eccezioni durante la creazione di widget.
Descrizione: in Eclipse 3.0, se veniva creato un widget con un elemento principale eliminato, non veniva generata alcuna eccezione e il codice del widget terminava in errore successivamente oppure era generata una SWTException con testo "Widget Is Disposed". In Eclipse 3.1, se si crea un widget con un elemento principale eliminato, il costruttore genererà una IllegalArgumentException con testo "Argument not valid".
Azione richiesta: il codice che gestisce la SWTException durante la creazione di un widget dovrà anche gestire la IllegalArgumentException.