Utilizzo del potenziamento del caricatore classi

Ultimo aggiornamento: 9 dicembre 2002

Eclipse 2.1 include molte funzioni di miglioramento delle prestazioni, incluse alcune che riguardano il caricamento delle classi. Per ottenere questo risultato, sono stati aggiunti tag al file manifest del plug-in e di seguito viene spiegato il loro funzionamento.

Attivazione

Il miglioramento delle prestazioni del caricatore classi viene attivato automaticamente per impostazione predefinita. Se l'utente vuole disabilitare questo comportamento, può richiamare l'eseguibile Eclipse passando l'argomento di riga comandi -noPackagePrefixes.

Formato

I prefissi di pacchetto nel file manifest del plug-in sono indicati dall'elemento packages per ciascuna libreria dichiarata nel file. L'elemento packages presenta un attributo prefixes che elenca i prefissi di pacchetto per la libreria.

Spesso i file jar contengono codice che risiede in più pacchetti. Ad esempio, il plug-in org.eclipse.core.runtime contiene codice nei seguenti pacchetti:
    org.eclipse.core.runtime
    org.eclipse.core.internal.runtime,
    org.eclipse.core.internal.plugins
    org.eclipse.core.runtime.model
.

In questo caso, plugin.xml specifica:

    <runtime>
        <library name="runtime.jar">
            <export name="*"/>
            <packages prefixes="org.eclipse.core"/>
        </library>
    </runtime>

Si noti che org.eclipse.core è un prefisso comune a tutti i pacchetti del plug-in. L'alternativa è di dichiarare tutti e 4 i prefissi nel file come elenco separato da virgole. In questo caso occorre valutare la scelta tra il numero elevato di verifiche richieste per più elementi e l'uso di un prefisso che potrebbe includere false corrispondenze. In funzione della struttura del codice, potrebbe essere più conveniente elencare 5-10 prefissi di pacchetto piuttosto che utilizzare un prefisso generico. Ad esempio, se tutto il codice presente in più plug-in contiene lo stesso prefisso (com.mycompany), non risulta conveniente elencare il solo prefisso singolo "com.mycompany" nel file.

Se un plug-in contiene più dichiarazioni di libreria, ognuna di essere dovrebbe considerare i prefissi di pacchetto del proprio jar.

Se si sceglie di non includere elementi packages nel proprio manifest del plug-in, il codice potrà operare ma senza sfruttare l'ottimizzazione del caricamento delle classi. Si noti che l'elenco di prefissi di pacchetto deve essere completo, includendo tutti i pacchetti di tutte le librerie del plug-in. Se l'elenco non è completo, il codice non potrà funzionare.

Utilizzo con il file delle proprietà Classloader

In Eclipse 2.0.2 e nelle versioni di integrazione Eclipse 2.1, è stata aggiunta un funzione che consentiva all'utente di specificare un file delle proprietà del caricatore delle classi che conteneva i prefissi di pacchetto per abilitare il potenziamento del caricatore classi. Informazioni sull'uso di questo file sono riportate qui.

Eclipse 2.1 mantiene la compatibilità con il file delle proprietà del caricatore classi; infatti questo può essere utilizzato unitamente alle dichiarazioni di prefissi di pacchetto del file manifest del plug-in. Questa sezione descrive l'interazione tra questi due meccanismi.

Comportamento standard: (nessun argomento di riga comandi) i prefissi di pacchetto saranno letti dal file plugin.xml e applicati alla strategia di caricamento classi. Il file classloader.properties non viene considerato.

Utilizzo di -classloaderProperties: i prefissi di pacchetto sono letti dal file plugin.xml e successivamente viene letto il file classloader.properties. Se è presente nel file delle proprietà del caricatore classi una voce per un plug-in che presenta prefissi definiti nel file manifest, la voce del file delle proprietà ha la priorità. I risultati NON sono uniti. Se la voce nel file delle proprietà non presenta un valore (ovvero, org.eclipse.core.runtime=), allora tutti i prefissi dichiarati nel file manifest vengono eliminati e la strategia di caricamento classi ritorna al comportamento predefinito, non viene utilizzato alcun potenziamento.

Utilizzo di -noPackagePrefixes: i prefissi di pacchetto dichiarati nel file manifest del plug-in sono ignorati ed anche il file delle proprietà del caricatore classi non viene considerato. La strategia di caricamento classi ritorna al comportamento predefinito e non utilizza il potenziamento dei prefissi.

Utilizzo congiunto di -classloaderProperties e -noPackagePrefixes: tutte le dichiarazioni di pacchetto nel file manifest del plug-in sono ignorate. Viene letto il il file delle proprietà del caricatore classi e tutte le dichiarazioni in esso contenute sono considerate per il caricamento classi.

Risoluzione dei problemi

Se viene rilevata la condizione java.lang.ClassNotFoundException, questa è un'indicazione di problemi con le voci del file manifest o del file delle proprietà. Eseguire Eclipse con l'argomento di riga comandi -noPackagePrefixes e NON utilizzare l'argomento -classloaderProperties. Questo disabilita il potenziamento di caricamento classi che riguarda i prefissi di pacchetto.

Se il codice viene eseguito correttamente dopo questa operazione, i file potrebbero avere sintassi corretta ma potrebbe mancare qualche voce nell'elenco dei prefissi di pacchetto. Per verificare questo problema, provare a commentare alcune righe del file. Utilizzare il simbolo cancelletto (#) per trasformare in commento le righe del plug-in nel file delle proprietà oppure i caratteri di commento HTML (<!-- ... -->) per trasformare in commento le dichiarazioni di pacchetto nel file plugin.xml.

Problemi noti

Se il file manifest del plug-in dichiara l'elenco di prefissi di pacchetto, anche tutti i frammenti che contribuiscono ad esso devono elencare i propri prefissi di pacchetto. Se ciò non avviene, si verifica una condizione NoClassDefFoundError. Questo problema può essere risolto utilizzando l'argomento di riga comandi -noPackagePrefixes per disattivare il potenziamento del caricatore classi, oppure aggiungendo le voci di prefissi di pacchetto opportune al plug-in e ai relativi frammenti.

Copyright IBM Corporation e altri 2000, 2003.