Utilisation des améliorations du chargeur de classe

Dernière mise à jour : 9 décembre 2002

Eclipse 2.1 présente de nombreuses améliorations des performances, notamment dans le domaine du chargement de classes. Pour faciliter la compréhension de ces nouvelles fonctions, des marques ont été ajoutées au fichier manifeste des plug-in qui décrit leur utilisation.

Activation

Les améliorations des performances du chargeur de classe sont automatiquement activées par défaut. Si l'utilisateur souhaite ignorer ce comportement et les désactiver, elles peuvent alors transmettre l'argument de ligne de commande -noPackagePrefixes au fichier exécutable Eclipse.

Format

La déclaration des préfixes de package dans le fichier manifeste des plug-in est indiquée par un élément packages pour chaque bibliothèque déclarée dans le fichier. L'élément packages possède un attribut prefixes qui répertorie les préfixes de package pour cette bibliothèque.

Il n'est pas rare que les fichiers jar contiennent du code résidant dans plusieurs packages. Par exemple, le plug-in org.eclipse.core.runtime contient du code dans les packages suivants :
    org.eclipse.core.runtime
    org.eclipse.core.internal.runtime,
    org.eclipse.core.internal.plugins
    org.eclipse.core.runtime.model
.

Dans ce cas, le fichier plugin.xml spécifie :

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

Notez que org.eclipse.core est un préfixe courant pour tous les packages du plug-in. Une autre possibilité consiste à déclarer les 4 préfixes dans le fichier en tant que liste séparée par des virgules. Dans ce cas, il faut trouver le meilleur compromis entre le nombre de vérifications nécessaires par rapport à plusieurs entrées et l'utilisation d'un préfixe pouvant entraîner de fausses occurrences. Selon la façon dont votre code est structuré, il peut être préférable de répertorier jusqu'à 5-10 préfixes de package que d'utiliser un préfixe plus général. Par exemple, si l'ensemble de votre code pour plusieurs plug-in contient le même préfixe (par exemple, com.mycompany), alors vous ne tirerez pas pleinement parti de tous les avantages disponibles si vous n'indiquez que le préfixe "com.mycompany" dans le fichier.

Lorsqu'un plug-in contient plusieurs déclarations de bibliothèque, chacune d'elles doit tenir compte des préfixes de package de son fichier JAR.

Si vous choisissez de ne pas inclure d'éléments packages dans le manifeste de plug-in, votre code fonctionnera, mais vous ne tirerez pas parti de l'optimisation du chargement des classes. Notez que votre liste de préfixes de package doit être complète pour tous les packages de l'ensemble des bibliothèques de votre plug-in. Si cette liste n'est pas complète, alors votre code ne fonctionnera pas.

Utilisation avec le fichier de propriétés du chargeur de classe

Dans Eclipse 2.0.2 et dans les premières compilations d'Eclipse 2.1 Integration, un nouveau dispositif permettait à l'utilisateur de spécifier un fichier de propriétés du chargeur de classe qui contenait les préfixes de package permettant d'activer les améliorations du chargeur de classe. L'utilisation de ce fichier est spécifiée ici.

Eclipse 2.1 présente une compatibilité amont totale avec le fichier de propriétés du chargeur de classe et, en fait, il peut être utilisé en association avec les déclarations de préfixes de packages du manifeste de plug-in. Cette section décrit le comportement de l'interaction entre ces deux mécanismes :

Comportement par défaut : (aucun argument de ligne de commande) Les préfixes de package seront lus à partir du fichier plugin.xml et appliqués à la stratégie de chargement des classes. Le fichier classloader.properties n'est pas utilisé ni pris en considération.

Utilisation de -classloaderProperties : Les préfixes de package sont lus à partir du fichier plugin.xml, puis le fichier classloader.properties est lu. Si le fichier de propriétés du chargeur de classe contient une entrée pour un plug-in dont les préfixes ont été définis dans le fichier de manifeste, l'entrée du fichier de propriétés sera prioritaire. (les résultats ne sont PAS fusionnés) Si l'entrée du fichier de propriétés ne contient pas de valeur (par exemple, org.eclipse.core.runtime=), alors tous les préfixes déclarés dans le fichier de manifeste seront supprimés et la stratégie de chargement des classes sera par défaut de ne pas utiliser les améliorations.

Utilisation de -noPackagePrefixes : Tous les préfixes de package déclarés dans le fichier de manifeste de plug-in sont ignorés et le fichier de propriétés du chargeur de classes n'est pas non plus pris en compte. La stratégie de chargement des classes devient par défaut de ne pas utiliser les améliorations relatives aux préfixes.

Utilisation combinée de -classloaderProperties et de -noPackagePrefixes : Toutes les déclarations de package du fichier manifeste de plug-in sont ignorées. Le fichier de propriétés du chargeur de classe est lu et toutes les déclarations définies dans ce fichier sont prises en considération lors du chargement des classes.

Identification des incidents

Si vous obtenez une erreur java.lang.ClassNotFoundException, cela indique l'existence possible d'un problème avec vos entrées dans le fichier manifeste ou le fichier de propriétés. Essayez d'exécuter Eclipse avec l'argument de ligne de commande -noPackagePrefixes et n'utilisez PAS l'argument -classloaderProperties. Vous désactiverez ainsi toutes les améliorations du chargement des classes relatives aux préfixes de package.

Si votre code s'exécute correctement après cela, alors il est probable que la syntaxe des fichiers était correcte mais que des entrées manquaient dans la liste des préfixes de package séparés par des virgules. Pour vérifier si c'est le cas, mettez en commentaires les lignes appropriées du fichier. Utilisez un signe dièse (#) pour mettre en commentaires la ligne du plug-in incriminé dans le fichier de propriétés ou utilisez des caractères de commentaire HTML (<!-- ... -->) pour mettre en commentaires la déclaration des packages dans le fichier plugin.xml incriminé.

Problèmes connus

Si un fichier manifeste de plug-in déclare la liste des préfixes de package, alors tous les fragments qui y sont ajoutés doivent également répertorier leurs préfixes de package. Si ce n'est pas le cas, un incident NoClassDefFoundError se produira. La solution consiste soit à utiliser l'argument de ligne de commande -noPackagePrefixes pour désactiver les améliorations du chargeur de classes, soit à ajouter les entrées de préfixes de package appropriées au plug-in et à l'ensemble de ses fragments.

Copyright IBM Corporation and others 2000, 2003.