Discussion :

[Gugelhupf]

Bonjour,

Je souhaiterais vous poser quelques questions sur les classes URLClassLoader et Class.


1. Lorsqu'on instancie une classe URLClassLoader, le jar (ou les jars) qui est récupéré, est placé en forme de fichier sur la machine ou bien directement stocké en RAM ?


2. Pourriez-vous me dire quels sont les impacts les plus négatifs lors de l'utilisation des classes URLClassLoader et Class (par étape) :

• a. Instancier une classe URLClassLoader (récupérer un jar situé sur la machine locale, réseau local ou internet).
• b. Chargement d'une classe (création d'un objet Class avec la méthode loadClass de URLClassLoader)
• c. Créer une nouvelle instance (avec la méthode newInstance() de la classe Class).

3. Considérant que le jar est récupéré à partir du réseau ou internet, pensez-vous que ce soit un bon moyen d'obscurcir son script dans certains cas particuliers ? (ex: je ne veux pas que les personnes qui décompilent le code sache quelle est la méthode de calcul pour augmenter le niveau d'un personnage dans un jeu).
L'objectif n'est pas de sécuriser, mais de retarder la découverte de cette méthode de calcul.


4. Y a-t-il une différence entre Class.forName("Toto") et objetURLClassLoader.loadClass("Toto") ?


Merci

[grunt2000]

1. Lorsqu'on instancie une classe URLClassLoader, le jar (ou les jars) qui est récupéré, est placé en forme de fichier sur la machine ou bien directement stocké en RAM ?

C'est assez difficile à dire, désormais.
Depuis la version 1.6 Java sait compiler en mémoire vive un source et utiliser sa classe directement comme si elle faisait partie du programme original.
Néanmoins, je pense qu'il y a toujours une représentation sur le disque de la classe.
J'en suis quasi certain pour URLClassLoader, parce que les antivirus alarment souvent sur des jars tiers au chargement des applications. Je ne vois pas comment ils pourraient agir si les classes n'existaient pas sur le disque.


2. Pourriez-vous me dire quels sont les impacts les plus négatifs lors de l'utilisation des classes URLClassLoader et Class (par étape) :

• a. Instancier une classe URLClassLoader (récupérer un jar situé sur la machine locale, réseau local ou internet).
• b. Chargement d'une classe (création d'un objet Class avec la méthode loadClass de URLClassLoader)
• c. Créer une nouvelle instance (avec la méthode newInstance() de la classe Class).

C'est à peu près pareil tout ça.
Au final, il s'agit juste de sélectionner le DefaultClassLoader ou un ClassLoader externe avant d'y trouver sa classe.
Tous finissent par faire un findClass et loadClass donc à part la récupération sur un emplacement externe de ton jar par URLClassLoader, si c'est ton choix, où tu perdras un peu en performances, je ne vois pas de differences.


3. Considérant que le jar est récupéré à partir du réseau ou internet, pensez-vous que ce soit un bon moyen d'obscurcir son script dans certains cas particuliers ? (ex: je ne veux pas que les personnes qui décompilent le code sache quelle est la méthode de calcul pour augmenter le niveau d'un personnage dans un jeu).
L'objectif n'est pas de sécuriser, mais de retarder la découverte de cette méthode de calcul.

Non. Ce n'est pas par là que j'agirais.

4. Y a-t-il une différence entre Class.forName("Toto") et objetURLClassLoader.loadClass("Toto") ?

L'une va chercher la classe dans le ClassLoader déjà chargé de ton application Java, l'autre va essayer de la trouver dans un jar où emplacement externe auparavant.

[Gugelhupf]

Bonjour,

Merci pour votre réponse @grunt2000.

En faite, pour la première question, je me demandais si dans le cas où Java sauvegarde le .class téléchargé, est-ce que celui-ci est sauvegardé quelque part sur le disque ou non.


Pour la seconde question :
Pourriez-vous me dire à quel moment exactement l'URLClassLoader va télécharger le ".jar" qui se trouve à distance, lors de l'instanciation d'URLClassLoader ? Ou bien lors de l'utilisation de la méthode loadClass("nom de ma classe").


J'aurais 2 nouvelles questions :
5. Y a t-il une différence de performance entre l'instanciation normale (ex: new MaClasse() ), et l'instanciation via un objet de type Class avec la méthode newInstance() ?

6. Lorsqu'on dit que le ClassLoader va "charger les classes", est-ce que le ClassLoader va mettre en mémoire une liste de l'emplacement de tous les fichiers .class (ex: { "C:/chemin/Toto.class", "C:/chemin/Tata.class", "C:/chemin/Titi.class" } ), ou bien s'agit-t-il d'autre chose ?


Merci

[plawyx]

5. Y a t-il une différence de performance entre l'instanciation normale (ex: new MaClasse() ), et l'instanciation via un objet de type Class avec la méthode newInstance() ?

J'ai fait des tests avec différentes différentes classes et différents types d'attributs: je n'ai pas réussi à obtenir une règle (ou une tendance) claire sur les performances de l'instanciation par new, .newInstance() ou par clonage.

Pourtant dans certains cas, j'obtenais des facteurs 200 voir 500 sur les temps de traitement. Dans d'autres cas, les résultats étaient inversés.

[Gugelhupf]

Bonjour,

Dans d'autres cas, les résultats étaient inversés.

Je ne m'attendais pas aux cas où la réflexion/introspection donne de meilleures résultats (niveau performance) que l'écriture normale ( new MaClasse() )




@tchize_

Il est lu via la méthode ad-hoc sur la classe URL depuis son emplacement d'origine.

Je me doute bien qu'il y a une réception de flux de la machine qui utilise URLClassLoader sur la machine source (qui contient les .jar et .class).
La question que je me pose c'est que fait la JVM exécutant URLClassLoader de ce flux ? Est-ce qu'elle le stocke en RAM, ou bien au format fichier ".class" sur le disque local.
Si par exemple le Garbage Collector supprimer l'objet URLClassLoader, est-ce que les .jar téléchargés sont supprimés de la RAM, ou bien les fichiers .class restent quelque part sur le disque ?

7. Donc si je comprends bien (dans l'ordre) :

1. L'instanciation d'URLClassLoader va télécharger les .jar et .class
2. La méthode loadClass() va juste permettre de récupérer le type Class<T>
3. La méthode newInstance() va permettre de créer une nouvelle instance de T

N'hésitez pas à me rectifier



8. Est-ce que l'instanciation d'une classe URLClassLoader est synchrone ou asynchrone ? => est-ce que l'instruction new URLClassLoader() est bloquante (attend que le téléchargement soit terminé) ou non ?
Pourquoi je pose cette question ? C'est simple, notre enseignant nous a dit que les instructions suivantes pouvaient bloquer la JVM :

Code :

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

1
2
3
4
5
6
Image img = getTolKit().getImage(urlImage);
// getImage() est asynchrone
 
while(img.getHeigth() == -1){
    // Mettre l'instruction Thread.yield() sinon risque de boucle infinie
}

Ce cas de boucle infinie arrive lorsque le thread actif attend un appel système avant de donner la main au thread dans getImage(), sauf qu'aucun appel système n'est effectué dans la boucle while (donc boucle infinie).
C'est un cas particulier de la JVM qui utilise un algorithme sur les appels systèmes.



PS: N'hésitez pas à répondre à la question 6. , et ensuite je pense que je passerais en résolu


Merci

[tchize_]

La question que je me pose c'est que fait la JVM exécutant URLClassLoader de ce flux ?

Elle crée un tableau de URL qu'elle transmet à une classe de type sun.misc.URLClassPath. C'est URLClassPath qui fait le boulot éventuel de connection au serveur web, et son comportement n'est pas documenté.
Si tu veux t'y plonger, tu peux regarder comment il travaill:

http://www.docjar.com/html/api/sun/m...Path.java.html

Mais en gros, il a un comportement qui dépend du type de l'url. Si c'est un fichier local: ouverture en local. Si c'est un folder distance, demande de connexion au serveur web pour chaque classe. Je n'ai pas eu le courage d'aller en détail si c'est un JAR distant, mais il semble qu'il joue sur une connexion restant ouverte avec le serveur et les reprise http pour aller directement à l'indx voulu sans devoir tout garder.

Est-ce qu'elle le stocke en RAM, ou bien au format fichier ".class" sur le disque local.

ni l'un ni l'autre, normalement, il ne stocke pas

L'instanciation d'URLClassLoader va télécharger les .jar et .class

non, ça va juste créer un liste d'url stockée quelque part. Sans plus.

la méthode loadClass() va juste permettre de récupérer le type Class<T>

cette méthode repose sur findClass qui, lui, peut déclencher un téléchargement.

La méthode newInstance() va permettre de créer une nouvelle instance de T

Oui

est-ce que l'instruction new URLClassLoader() est bloquante (attend que le téléchargement soit terminé)

Non, elle en télécharge rien.

Pourquoi je pose cette question ? C'est simple, notre enseignant nous a dit que les instructions suivantes pouvaient bloquer la JVM :

Code :

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

1
2
3
4
5
6
Image img = getTolKit().getImage(urlImage);
// getImage() est asynchrone
 
while(img.getHeigth() == -1){
    // Mettre l'instruction Thread.yield() sinon risque de boucle infinie
}

Il doit réviser son cours. Il n'y a pas de méthode Image.getHeight(). Par contre, il y a une méthode Image.getHeight(ImageObserver). D'ailleurs, là, on te mentionne clairement que tout est asynchrone et que getHeight peut te retourner -1 si ce n'est pas encore connu. Enfin, tu peux passer un ImageObserver pour être notifié. Le problème n'est pas trop le temps du réseau, mais le travail, parfois important, nécessaire pour décoder les images si elles sont grande. Je peux passer 10ms sur les IO pour lire 500k d'un fichier, mais 2 secondes pour faire le décodage...

Ce cas de boucle infinie arrive lorsque le thread actif attend un appel système avant de donner la main au thread dans getImage(), sauf qu'aucun appel système n'est effectué dans la boucle while (donc boucle infinie).
C'est un cas particulier de la JVM qui utilise un algorithme sur les appels systèmes.

Je ne sais pas où tu va chercher ça, mais non, l'ImageProducer utilisé derrière n'attends pas que ton programme fasse quoi que ce soit pour décoder. Le Thread.yield est inutile. D'ailleurs, la javadoc de Thread.yield() met en garde contre son utilisation:

Code :

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

1
2
3
4
5
6
-> C'est juste une indication au scheduler
-> Il est libre de l'ignorer
-> Ca "tente" d'améliorer le partage du CPU
-> C'est rarement adéquat d'utiliser cette méthode
-> doit être utilisé en combinaison avedes des benchmark et un profiling détaillé indiquant sa nécessité
-> Peut être utilise pour faciliter le reproduction de certains bugs

Par contre, si tu veux éviter de gaspiller des cycles dans la boucle active, tu peux utiliser le ImageObserver, c'est bien plus approprié comme méthode

[tchize_]

1. Lorsqu'on instancie une classe URLClassLoader, le jar (ou les jars) qui est récupéré, est placé en forme de fichier sur la machine ou bien directement stocké en RAM ?

Il est lu via la méthode ad-hoc sur la classe URL depuis son emplacement d'origine.

Pourriez-vous me dire quels sont les impacts les plus négatifs lors de l'utilisation des classes URLClassLoader et Class (par étape)

Bha rien de bien différent de quand tu utilise des class normalement. Ce que tu fais avec URLClassloader, surprise, la jvm le fait aussi avec ton code. Le class loader de base de ton application est souvent déjà un URLClassloader.

La seule particularité quand tu utilise un classloader séparé, c'est que ton application de base ne vois pas les classes présentes dans le URLClassloader, ces domaines sont séparés.

3. Considérant que le jar est récupéré à partir du réseau ou internet, pensez-vous que ce soit un bon moyen d'obscurcir son script dans certains cas particuliers ? (ex: je ne veux pas que les personnes qui décompilent le code sache quelle est la méthode de calcul pour augmenter le niveau d'un personnage dans un jeu).
L'objectif n'est pas de sécuriser, mais de retarder la découverte de cette méthode de calcul.

Si tu ne veux pas que l'utilisateur connaisse la méthode de calcul, fait le calcul sur le server et pas coté client

4. Y a-t-il une différence entre Class.forName("Toto") et objetURLClassLoader.loadClass("Toto") ?

Le premier utilise le classloader de ta classe courante (this.getClass().getClassloader()), le second utilise un classloader spécifique. A part ça, c'est basiquement le même