Comprendre le mécanisme du CLASSLOADER

**fabszn** · 03/08/2010, 16h58

Hello,

Je cherche à comprendre et cerner le mécanisme du classLoader.

J'ai fait des recherches sur internet j'ai trouvé différentes choses sur le sujet, mais j'avoue avoir encore le sentiment de ne pas tout bien comprendre encore.

Par exemple, lors du lancement d'un JVM, combien de classloader sont utilisés?
Comment savoir quel classloader est utilisé pour une classe donnée?

En fait, j'aimerai pouvoir échanger sur le sujet avec quelqu'un qui maitrise le sujet (qui à échanger hors forum, afin de ne pas le polluer)

Je vous remercie par avance pour votre aide,

Cordialement,

**tchize_** · 03/08/2010, 17h17

Envoyé par fabszn

Hello,

Je cherche à comprendre et cerner le mécanisme du classLoader.

Il charge des classes, avec un mécanisme de délagation prioritaire vers le parent, "en général"

Par exemple, lors du lancement d'un JVM, combien de classloader sont utilisés?

Ca dépend de la jvm, de son implémentation. a la base t'as en général une classloader pour les classe de la jvm + un classloader pour ton application en elle même. Ce petit code donne une idée.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
public class Main {
 
 
    public static void main(String[] argv)
	{
        ClassLoader cl = new Main().getClass().getClassLoader();
        while (cl!=null){
            System.out.println("Classloader "+cl);
            cl=cl.getParent();
            }
	}
 
}

Comment savoir quel classloader est utilisé pour une classe donnée?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

monMachin.getClass().getClassloader()

**fabszn** · 03/08/2010, 17h32

Hello,

Merci beaucoup pour ta réponse rapide.

En exécutant le code que tu m'as indiqué, j'obtiens ce résultat :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Classloader sun.misc.Launcher$AppClassLoader@11b86e7
Classloader sun.misc.Launcher$ExtClassLoader@35ce36

Cela veut dire que ma classe Main est chargée par le classLoader AppClassLoader et que ce dernier est chargé par ExtClassLoader?

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

Dans le cas d'un serveur d'application, type Tomcat par exemple, il doit y avoir un classloader pour le démarrage de la JVM (ExtClassLoader), un founit par tomcat (??) et enfin un pour le chargement d'une application (war)..

Est ce que le nombre de classloader peut/ou doit être limité ?
est ce que je peux choisir /et comment quel classloader va charger ma classe?

Je suis désolé pour toutes ces questions.. mais j'aimerai comprendre les tenants et les aboutissants du mécanisme.

Merci d'avance pour ton aide,

Cordialement,

**tchize_** · 03/08/2010, 19h53

Envoyé par fabszn

Cela veut dire que ma classe Main est chargée par le classLoader AppClassLoader et que ce dernier est chargé par ExtClassLoader?

pas nécessairement, la JVM peut très bien démarrer les deux classloaders a son démarrage et les liers entre eux. Le "parent" dans le code d'exemple est celui utilisé par le système de délagation (quand on demande un classe à AppClassLoader, il va d'abord vérifier que ExtClassLoader ne l'a pas). C'est sa popotte interne

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

C'est ce que les noms suggèrent, mais on en sait rien à priori, il faudrait voir le code de ces deux classes, code qu'on ne connais pas et qui est spécifique à la JVM de sun.

Dans le cas d'un serveur d'application, type Tomcat par exemple, il doit y avoir un classloader pour le démarrage de la JVM (ExtClassLoader), un founit par tomcat (??) et enfin un pour le chargement d'une application (war)..

Il y en a plus que ça, mais c'est documenté sur le site de tomcat

Est ce que le nombre de classloader peut/ou doit être limité ?

Non, il n'y a pas de limite. Un classloader c'est juste une classe qui étends ClassLoader. C'est plus le nombre de classes de l'application qu'il faut garder à l'oeil

est ce que je peux choisir /et comment quel classloader va charger ma classe?

Oui et non. Toutes les classes de ton application de base seront chargées par le classloader imposé par la JVM / par le conteneur J2EE / etc suivant le contexte. Par contre rien ne t'interdit d'utiliser ton propre classloader pour charger des classes supplémentaire. C'est utile par exemple pour mettre en place un système de plugins où tu voudrais isoler les plugins l'un de l'autre. Chaque plugin pourrait avec des classes avec le même nom, elle ne se marcheraient pas sur le pieds. Dans ce cas, la class UrlClassLoader te sera bien utile

. Une fois le classloader construit, des appel à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

tonClassLoader.forName("nom.de.Classe").newInstance()

te permettra d'instancier des classes qui y sont.

**fabszn** · 04/08/2010, 10h29

Hello,

Merci beaucoup pour ta réponse!

Je commence à mieux cerner le truc...

Je n'avais jamais fait attention à cette partie de la documentation sur Tomcat.

J'aurais une question complémentaire :

Par exemple, lorsque je configure mon logger (log4j) dans une webApp. Je charge le fichier de configuration en utilisant le mécanisme de chargement de ressource via le classloader.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse.class.getClassLoader().getResource("com/toto/titi/MyFile.xml")

Lorsque je teste en local (sous window) ca marche très bien... en revanche lorsque je déploie sur un environnement tiers (sous linux) il ne trouve pas le fichier de configuration.
Est ce que c'est une différence d'implémentation de la JVM sous jacente qui peut être à l'origine du problème?

Comment je peux maîtriser ce genre de problème qui je pense est lié au classloader?

Merci d'avance pour ton aide,

Cordialement

**adiGuba** · 04/08/2010, 10h42

Salut,

Envoyé par fabszn

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MaClasse.class.getClassLoader().getResource("com/toto/titi/MyFile.xml")

Lorsque je teste en local (sous window) ca marche très bien... en revanche lorsque je déploie sur un environnement tiers (sous linux) il ne trouve pas le fichier de configuration.
Est ce que c'est une différence d'implémentation de la JVM sous jacente qui peut être à l'origine du problème?

Vérifies bien le nom du fichier, et un éventuelle problème de minuscule/majuscule.

Le classloader utilise le système de fichier de l'OS hôte, ce qui pourrait être à l'origine d'une différence de comportement de ce style

a++

**fabszn** · 04/08/2010, 10h44

Hello,

Merci pour ta réponse adiGuba.

Je vais vérifier ça tout de suite.
Aussi, par ta réponse, je comprends que tu écartes avec certitude le problème de classloader que j'évoquais?

Merci d'avance pour votre aide,

Cordialement,

**tchize_** · 04/08/2010, 11h03

oui le classloader n'est pas en cause. D'ailleurs si tu package ton application dans un jar, c'est sur d'avoir toujours le même comportement. Ce n'est pas parce que d'un JVM à l'autre la hierarchie des classloader n'est pas la même que le contrat des méthode de classloader n'est pas respecté. Le classpath de ton application au final est prévisible quel que soit la jvm, et la manière dont se comporte getResource par rapport à ce classpath est le même.

**adiGuba** · 04/08/2010, 11h25

Je n'écartes rien en particulier... mais ces problèmes de casses ont été la majeur partie des problèmes d'une migration d'une appli web de Windows vers Linux.

a++

**professeur shadoko** · 04/08/2010, 12h09

un petit complément (qui vaut ce qu'il vaut... mais bon)
ICI

**fabszn** · 04/08/2010, 15h20

Hello,

Merci pour vos réponses.

@professeur shadoko : Le lien ne fonctionne pas.. :-(

@adiGuba : effectivement.. problème de casse..

Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?

En tout cas merci pour votre aide.

Cordialement,

**adiGuba** · 04/08/2010, 15h27

Envoyé par fabszn

@adiGuba : effectivement.. problème de casse..

classique

Envoyé par fabszn

Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?

Dans quel objectif ?

a++

**professeur shadoko** · 04/08/2010, 15h33

Envoyé par fabszn

@professeur shadoko : Le lien ne fonctionne pas.. :-(

comment se fait-ce?

:
(ça marche pour moi avec différents réseaux et firefox)

**professeur shadoko** · 04/08/2010, 15h42

Envoyé par fabszn

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Classloader sun.misc.Launcher$AppClassLoader@11b86e7
Classloader sun.misc.Launcher$ExtClassLoader@35ce36

...

ExtClassLoader est le classLoader de la JVM (pour une implémentation donnée) et le classloader AppClassLoader est celui à la responsabilité de charger les classes développées?

non ExtClassLoader est le ClassLoader des extensions. Le ClassLoader de bootstrap n'est pas forcément vu par getParent() du fait de cet élement de la doc: "Some implementations may use null to represent the bootstrap class loader. This method will return null in such implementations if this class loader's parent is the bootstrap class loader. "

**tchize_** · 04/08/2010, 16h09

Envoyé par fabszn

Une dernière question, pour résumer un peu, mise à part écrire son propre classloader, à priori on ne peut pas influencer celui qui va charger nos classes au démarrage de la JVM?

Ca n'a pas d'intéret et de toutes façons, tu n'a pas le controle sur le classloader du démarrage de la JVM. Tu as juste le controle sur les classes supplémentaire que ton applicaiton java déjà en cours de fonctionnement, ajoute avec ses propres classloaders.

**fabszn** · 04/08/2010, 16h18

Hello,

@adiGuba : Je n'ai pas d'objectif particulier, c'est juste pour comprendre le mécanisme et mieux le maîtriser.

@professeur shadoko : Désolé, sa doit être le réseau de mon entreprise qui doit avoir des problèmes, j'ai testé depuis mon mobile et ça marche. Je n'ai pas encore tout lu, mais le lien a l'air très intéressant.

Le ClassLoader de bootstrap

Le bootstrap c'est celui que est utilisé par la JVM au moment du démarrage?

Merci pour votre aide,

Cordialement

**tchize_** · 04/08/2010, 16h42

c'est le classloader de base, celui chargé notamment de tout ce qui se trouve dans java.lang

**fabszn** · 04/08/2010, 16h52

Hello,

Merci à tous pour vos réponses et votre aide. Ma lanterne est maintenant un peu plus claire!

**fabszn** · 04/08/2010, 20h52

Hello,

Je reviens après avoir lu l'article conseillé par professeur shadoko. Très intéressant et il m'a encore plus éclairci les idées sur le sujet.

J'ai fait quelques tests pour aller un peu plus loin..

Il y a un truc que je ne comprends pas..

cette ligne ne devrait pas renvoyer le nom d'un classLoader :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

	System.out.println("ClassLoaderDirect : " + java.lang.String.class.getClassLoader());

Le premier qui est chargé au lancement de la JVM?
Lorsque j'exécute ce code, j'ai un référence null.

Merci d'avance pour votre aide,

Cordialement,

**tchize_** · 04/08/2010, 21h04

comme déjà dit, le bootstrap n'est pas nécessairement visible, d'ou le null

Comprendre le mécanisme du CLASSLOADER

Langage Java

Discussions similaires

Partager

Partager