Incompatibilità tra Eclipse 3.0 e 3.1

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.

  1. Preferenze dei plugin
  2. Modifiche ai vincoli IPath
  3. Registro delle estensioni
  4. Opzioni del programma di formattazione del codice
  5. Modifiche del contratto API per AntCorePreferences
  6. Modifiche del contratto API per la classe Policy in JFace
  7. Modifiche del contratto API per consentire una prospettiva predefinita null
  8. Modifiche del contratto API per IViewLayout
  9. Modifiche del contratto API per IVMInstall
  10. Visibilità nel pacchetto di SelectionEnabler.SelectionClass
  11. Valore di restituzione null per ContributionItem.getParent()
  12. Modifiche a isPropertySet(boolean) in IPropertySource e IPropertySource2
  13. Eliminazione dell'elemento handlerSubmission dal punto di estensione org.eclipse.ui.commands
  14. Modifica in finale del campo API statico non finale GLOBAL_IGNORES_CHANGED
  15. ClassCastException utilizzando FillLayout
  16. Creazione di un widget con un elemento principale eliminato

1. Preferenze dei plugin

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:

  1. Il tipo degli oggetti contenuti negli eventi di modifica preferenze non è garantito; il vecchio e il nuovo valore negli eventi possono essere null, String oppure un oggetto con tipo. Quindi, i listener di modifica preferenze devono essere in grado di gestire tutte e tre le possibili situazioni.
  2. Se il plugin utilizza 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.

2. Modifiche ai vincoli IPath

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.

3. Registro delle estensioni

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:

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.

4. Opzioni del programma di formattazione del codice

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.

5. Modifiche del contratto API per AntCorePreferences

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.

6. Modifiche del contratto API per la classe Policy in JFace

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.

7. Modifiche del contratto API per consentire una prospettiva predefinita null

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.

8. Modifiche del contratto API per IViewLayout

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.

9. Modifiche del contratto API per IVMInstall

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.

10. Visibilità nel pacchetto di SelectionEnabler.SelectionClass

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.

11. Valore di restituzione null per ContributionItem.getParent()

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.

12. Modifiche a isPropertySet(boolean) in IPropertySource e IPropertySource2

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à.

13. Eliminazione dell'elemento handlerSubmission dal punto di estensione org.eclipse.ui.commands

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.

14. Modifica in finale del campo API statico non finale GLOBAL_IGNORES_CHANGED

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.

15. ClassCastException utilizzando FillLayout

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.

16. Generazione di IllegalArgumentException durante la creazione di un widget con un elemento principale eliminato

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.