Modifiche necessarie quando si adottano i meccanismi e le API 3.2

Questa sezione descrive le modifiche necessarie se si tenta di sostituire il plugin 3.1 per adottare i meccanismi e le API 3.2.

  1. Launch configurations
  2. Launch Modes
  3. International Components for Unicode for Java (ICU4J)
  4. Runtime split

Launch configurations

Associazione di risorse della configurazione di avvio

Eclipse 3.2 fornisce una nuova infrastruttura per l'associazione delle configurazioni di avvio alle risorse. Questa associazione consente alla piattaforma di filtrare le risorse per le configurazioni di avvio e di eliminare le configurazioni associate a progetti eliminati. La finestra di avvio è stata migliorata per supportare un insieme di filtri che consentono di nascondere le configurazioni associate a progetti chiusi ed eliminati. Anche la finestra di avvio supporta il filtraggio in base agli insiemi di lavoro nella finestra del workbench attiva, che può essere selezionata anche nella finestra di avvio.

È responsabilità del client gestire l'associazione delle risorse nelle configurazioni di avvio. L'API è stata aggiunta a ILaunchConfigurationWorkingCopy per impostare le risorse associate ad una configurazione ed è stata aggiunta a ILaunchConfiguration per ottenere le risorse associate ad una configurazione. Ad esempio, durante la migrazione devono essere considerati le schede di avvio, i collegamenti di avvio e i partecipanti al refactoring. Anche il codice che crea o modifica le configurazioni di avvio deve aggiornare le associazioni alle risorse.

Supporto per la migrazione delle configurazioni di avvio

Eclipse 3.2 fornisce una nuova infrastruttura per la migrazione delle configurazioni di avvio affinché siano compatibili con la nuova strumentazione. Ad esempio, in Eclipse 3.2, è stato aggiunto supporto per filtrare le configurazioni di avvio in base alle risorse. Le configurazioni di avvio devono essere aggiornate per fornire le associazioni alle risorse per bilanciare la nuova funzione. Users can manually migrate launch configurations in their workspace from the Run/Debug > Launching > Launch Configurations preference page, by pressing the Migrate button.

È possibile aggiungere un nuovo attributo delegato di migrazione, facoltativo al punto di estensione launchConfigurationTypes, indicando una classe che implementa la nuova interfaccia ILaunchConfigurationMigrationDelegate. Il delegato della migrazione è responsabile di identificare i candidati per la migrazione ed eseguire la migrazione.

Launch Modes

È stato aggiunto un nuovo attributo facoltativo al punto di estensione launchModes che supporta l'esternalizzazione le etichette delle azioni nel menu di avvio a discesa. I client che contribuiscono alle modalità di avvio, devono indicare le proprie etichette da utilizzare per avviare i menu a discesa, ad esempio "Esegui come". Il nuovo attributo si chiama launchAsLabel. La piattaforma fornisce etichette appropriate per le modalità di avvio dell'esecuzione, del debug e dei profili. Per la compatibilità con le versioni precedenti, quando per una modalità di avvio non viene specificato il nuovo attributo, le etichette del menu a discesa vengono generate come prima, mediante MessageFormat con "{0} As". Fare riferimento al difetto correlato 105235.

International Components for Unicode for Java (ICU4J)

ICU4J è una serie di librerie Java che forniscono un supporto completo per Unicode, per la globalizzazione software e l'internazionalizzazione. Per poter fornire questa funzione alla comunità Eclipse, ICU4J è stato aggiunto alla piattaforma creata per Eclipse 3.2. You will see it in the build as a plug-in named com.ibm.icu. La piattaforma Eclipse utilizzerà le API ICU in Eclipse 3.2.

Migrazione

La migrazione del codice applicativo può essere eseguita in maniera incrementale, il che significa che non è necessaria l'adozione completa della funzione ICU4J per ottenere i vantaggi dell'utilizzo di ICU4J. Fare riferimento alla pagina ICU4J sul wiki Eclipse per ulteriori informazioni su come migrare il codice per utilizzare ICU4J.

Plug-in di sostituzione ICU4J

L'aggiunta del plug-in ICU4J aggiunge all'ordine 3MB di memoria. Alcune applicazioni non possono infatti implementare ICU4J se la dimensione dell'applicazione ha la precedenza rispetto all'utilizzo della funzione ICU4J. In questo caso, è disponibile un plug-in di sostituzione (com.ibm.icu.base) dalla pagina della build della piattaforma Eclipse. Scaricare il plug-in, rimuovere il plug-in com.ibm.icu e la relativa origine dalla directory /plugins, quindi rilasciare il plug-in di sostituzione. Ciò è necessario in quanto la piattaforma Eclipse ha adottato le API ICU per la versione 3.2 e pertanto la rimozione del plug-in ICU restituirà errori di compilazione nel codice della piattaforma. Il plug-in di sostituzione ha una dimensione di circa 100KB e viene richiamato semplicemente mediante l'implementazione predefinita di JDK delle classi utilizzate più di frequente e dalle API in ICU4J. Fare riferimento alla pagina ICU4J sul wiki Eclipse per ulteriori informazioni su come utilizzare il plug-in di sostituzione ICU.

Effetto su JFace - ViewerSorter e StructuredViewer

Per supportare ICU4J in JFace, sono richieste delle aggiunte API in modo da impedire ogni riferimento alle classi ICU nelle API. Ciò ha richiesto l'aggiunta di:

  1. a new class called org.eclipse.jface.viewers.ViewerComparator, of which org.eclipse.jface.viewers.ViewerSorter is now a subclass.
  2. two new methods to org.eclipse.jface.viewers.StructuredViewer, to support the addition of org.eclipse.jface.viewers.ViewerComparator.

Rationale

La classe ViewerSorter ha un metodo pubblico getCollator() che restituisce java.text.Collator. Poiché questo metodo è un'API, esso non può essere modificato in modo da utilizzare un ICU Collator. Inoltre, le classi ICU non possono far parte dell'API (firme) in quanto una dipendenza del plug-in diretta sull'ICU impedirebbe l'utilizzo di JFace come aiutonomo (con SWT). Per risolvere queste limitazioni, è stata aggiunta la classe ViewerComparator che utilizza un java.util.Comparator piuttosto che un ICU Collator. Ciò è stato effettuato in quanto la classe Collator dell'ICU implementa java.util.Comparator, pertanto qualsiasi StructuredViewer può utilizzare il Collator piuttosto che java.text.Collator, ma JFace non deve aggiungere una dipendenza sul plug-in ICU4J. I due nuovi metodi aggiunti a StructuredViewer supportano l'utilizzo del Collator dell'ICU per ordinare il contenuto del visualizzatore mediante un ViewerComparator e non con ViewerSorter. È preferibile che qualsiasi StructuredViewer utilizzi questi metodi per richiamare e impostare il programma di ordinamento del visualizzatore (comparatore) al posto dei metodi getSorter() e setSorter(ViewerSorter).

Runtime split

New runtime APIs

The org.eclipse.equinox.common bundle includes several new API classes (e.g., Assert and ListenerList) that have common names. If your code has a class with the same name and uses import * statements to import both the local class and classes from the runtime, you might get the following error message:

   The type ABC is ambiguous
  

Organizing the imports and choosing the appropriate import source should resolve this problem.

Explicit class paths in the custom build scripts

As a result of the code being moved into new runtime plug-ins, custom scripts that explicitly references org.eclispe.core.runtime might need to add one or more of the following plug-ins: