getClass (). getClassLoader () est null, pourquoi?
J'ai du code qui appelle ..
x = getClass().getClassLoader();
Cela retourne null si.
Lorsque je lance le même code, pas à partir d'Eclipse, mais à partir de la ligne de commande, il renvoie un chargeur de classes.
Je peux pirater le code pour le faire ...
if (getClass().getClassLoader() == null)
{
x = ClassLoader.getSystemClassLoader().getSystemResourceAsStream( loadedPropFileName );
}
les deux sont compilés et exécutés avec la même machine virtuelle. (Je suis sûr à 99,99%).
Quelqu'un a une idée pourquoi le premier retournerait null pour le classloader?
Modifier:
Ma question est la suivante: «Quelqu'un a-t-il une idée de la raison pour laquelle la même classe renvoie la valeur null lorsqu'elle est démarrée via Eclipse et un chargeur de classes lorsqu'elle est chargée à partir de la ligne de commande».
Merci pour le conseil que le chargeur Bootstap doit charger la classe dans Eclipse. Je ne sais pas pourquoi cela se produit si.
Citer le doc API :
Certaines implémentations peuvent utiliser null pour Représenter le chargeur de classes d'amorçage. Cette méthode renvoie null dans ces implémentations Si cette classe était chargée par le chargeur de classes d'amorçage. .
Voilà comment cela fonctionne . Chaque fois que JVM essaie de charger une classe, il vérifie si les conditions sont réunies.
Si Class est chargé à partir de Bootstrap ClassPath i.e; jdk\jre\lib\rt.jar, BootStrap ClassLoader sera appelé.
Si Class est chargé depuis Extension Classpath i.e; jdk\jre\lib\ext * .jar, l'extension ClassLoader sera appelée.
Si Class est chargé à partir de Application ClassPath, i.e; comme spécifié dans la variable d'environnement, Application ClassLoader est appelé.
Bootstrap ClassLoader n'étant pas implémenté en Java, il est implémenté en c ou en c ++. Il n'y a donc aucune référence à cela. C'est pourquoi il renvoie la valeur null. Mais Extension et Application class Loader étant écrit en Java, vous obtiendrez la référence Sun.misc.Launcher$ExtClassLoader@someHexValue et Sun.misc.Launcher$AppClassLoader@someHexValue.
Donc, si vous faites quelque chose comme ceci System.out.println (String.class.getClassLoader ()), vous aurez la valeur null car cette classe a été appelée par BootStrap ClassLoader. Par contre, si vous faites de même Pour une classe dans le chemin Ext ou App Class, vous obtiendrez $ ExtClassLoader @ someHexValue et Sun.misc.Launcher$AppClassLoader@someHexValue respectivement.
"Cette méthode retournera null dans de telles implémentations si cette classe a été chargée par le chargeur de classes d'amorçage." http://Java.Sun.com/j2se/1.4.2/docs/api/Java/lang/Class.html#getClassLoader ()
Une chose est certaine, Eclipse a une configuration de chargeur de classe plus complexe et plus complexe que lorsque vous exécutez à partir de la ligne de commande. Si vous constatez des différences dans la manière dont le chargeur de classe d'une classe apparaît dans l'une par rapport à l'autre, c'est probablement une raison.
Je ne connais pas exactement ce que fait exactement Eclipse, mais je pense qu'il est très probable que votre classe soit pas chargée par le chargeur de classes bootstrap lorsqu’elle est exécutée à partir d’Eclipse, mais qu’Eclipse tente de le faire paraître ainsi.
Le chargeur ClassLoader de démarrage est statique une fois l'application lancée et vous ne pouvez pas y ajouter de fichiers JAR ni de classes ultérieurement, à moins que Eclipse n'ait redéfini l'implémentation ... Dans ce cas, une autre explication est possible.
"Cette méthode retournera null dans de telles implémentations si cette classe a été chargée par le chargeur de classes d'amorçage." - JavaDoc at getClassLoader ()
Le chargeur de classe null est réservé aux classes système pour des raisons de sécurité et ne peut être utilisé que si Class.forName (nom de chaîne, initialisation booléenne, chargeur ClassLoader). Si une classe a un ClassLoader null, la plupart des contrôles de sécurité ne sont pas effectués.
J'ai eu le même problème. Mais résolu en utilisant: -
<ClassName>.class.getClass().getResource(urlString);
J'espère que cela aide les autres ...
Avait un problème similaire. Résolu en n'utilisant pas la méthode getClass. La suite a fonctionné pour moi.
<ClassName>.class.getClassLoader();