Forum |  HardWare.fr | News | Articles | PC | S'identifier | S'inscrire | Shop Recherche
2372 connectés 

  FORUM HardWare.fr
  Programmation
  Java

  [JAVA] Mécanisme pour charger des JAR à la demande

 


 Mot :   Pseudo :  
 
Bas de page
Auteur Sujet :

[JAVA] Mécanisme pour charger des JAR à la demande

n°466988
noldor
Rockn'roll
Posté le 24-07-2003 à 15:38:33  profilanswer
 

Je développe une applet qui contient différents plug-ins. Afin d'éviter d'avoir un JAR de départ trop lourd, j'aimerais que les jars des plug-ins ne soient chargés que si nécessaire, càd que si l'utilisateur utilise un des plug-ins.
Existe-t-il un mécanisme permettant de charger un JAR dynamiquement en cours d'exécution ?

mood
Publicité
Posté le 24-07-2003 à 15:38:33  profilanswer
 

n°466991
benou
Posté le 24-07-2003 à 15:39:31  profilanswer
 

URLClassLoader  ...


---------------
ma vie, mon oeuvre - HomePlayer
n°466994
noldor
Rockn'roll
Posté le 24-07-2003 à 15:41:32  profilanswer
 

benou a écrit :

URLClassLoader  ...

j'ai oublié de préciser : ça doit marcher en java 1.1
si mes souvenirs sont exacts, URLClassLoader n'existe qu'à partir de 1.2 :(
merci benou :hello:

n°466999
benou
Posté le 24-07-2003 à 15:43:26  profilanswer
 

bha dans ce cas, je dirais qe tu peux pas ...
 
ou bien tu récupères le code de la classe URLClassLoader .. et tu l'adaptes pour qu'il passe en jdk 1.1


---------------
ma vie, mon oeuvre - HomePlayer
n°467009
lorill
Posté le 24-07-2003 à 15:49:14  profilanswer
 

benou a écrit :

URLClassLoader  ...

[:cupra]

n°467018
benou
Posté le 24-07-2003 à 15:53:05  profilanswer
 
n°467021
Taiche
(╯°□°)╯︵ ┻━┻
Posté le 24-07-2003 à 15:54:36  profilanswer
 


C'est pas très constructif, ce blabla, je demande votre ban :o


---------------
Everyone thinks of changing the world, but no one thinks of changing himself  |  It is the peculiar quality of a fool to perceive the faults of others and to forget his own  |  Early clumsiness is not a verdict, it’s an essential ingredient.
n°467028
*syl*
--> []
Posté le 24-07-2003 à 15:58:34  profilanswer
 

Taiche a écrit :


C'est pas très constructif, ce blabla, je demande votre ban :o

:)

n°467029
benou
Posté le 24-07-2003 à 15:59:56  profilanswer
 

Taiche a écrit :


C'est pas très constructif, ce blabla, je demande votre ban :o


 :o  
 
j'attends la réponse de noldor. Je lui ai déjà donné 2 réponses moa !  :kaola:


---------------
ma vie, mon oeuvre - HomePlayer
n°467049
phnatomass
Je m'empare de ton esprit !!
Posté le 24-07-2003 à 16:16:59  profilanswer
 

Sans être expert en Applet , je dirais que justement il ne faut pas faire de JAR si tu souhaites que les classes soient chargées dynamiquement en fonction du besoin.
En fait le ClassLoader va chercher les classes quand il en a besoin c à d quant dans ton code "apparait" une classe par exemple. Evidement si cette classe herite, implemente ou contient d'autre classe alors évidement elle seront chargés automatiquement.
Dans certain cas pour pouvoir charger une classes selon certaines conditions Class.forName est ton ami.
Si tu détailles plus tes besoins je pourrait te donner des explications + claires que cette vague présentation peu rigoureuse.


Message édité par phnatomass le 24-07-2003 à 16:26:14
mood
Publicité
Posté le 24-07-2003 à 16:16:59  profilanswer
 

n°467069
noldor
Rockn'roll
Posté le 24-07-2003 à 16:33:50  profilanswer
 

phnatomass a écrit :

Sans être expert en Applet , je dirais que justement il ne faut pas faire de JAR si tu souhaites que les classes soient chargées dynamiquement en fonction du besoin.
En fait le ClassLoader va chercher les classes quand il en a besoin c à d quant dans ton code "apparait" une classe par exemple. Evidement si cette classe herite, implemente ou contient d'autre classe alors évidement elle seront chargés automatiquement.
Dans certain cas pour pouvoir charger une classes selon certaines conditions Class.forName est ton ami.
Si tu détailles plus tes besoins je pourrait te donner des explications + claires que cette vague présentation peu rigoureuse.


Class.forName marcherait, mais ce qui m'embête, c'est que je devrais charger classe par classe, et c'est tout de même assez lent

n°467100
phnatomass
Je m'empare de ton esprit !!
Posté le 24-07-2003 à 17:17:17  profilanswer
 

Franchement si tu pouvais donner des détails.
Tu n'es pas obliger de faire un Class.forName pour tout.
En plus si ta bien penser ton modele , tes plugins devrait tous implementer une interface commmune, en suite avec un patern Factory c'est vite réglé .
ex:

Code :
  1. Plugin p = null;
  2.   String plugingClassName ="";
  3.   switch(choix_utilisateur)
  4.   {
  5.     case FILTRE : plugingClassName= "monprojet.plugin.FiltreGaussien";
  6.     break;
  7.     case ROTATION : plugingClassName= "monprojet.plugin.Rotation180";
  8.     break;
  9.     case NOIR_ET_BLANC :
  10. plugingClassName = "monprojet.plugin.ConvertNB";
  11.     break;
  12.   }
  13. if(!plugingClassName.equals("" ))
  14.   p = Class.forName(plugingClassName);
  15. // application de la transformation
  16. monImage = p.apply(monImage)


 
Dans l'exemple je n'utilise pas de Factory ;)  
 
Concernant la lenteur c'est relatif car tes classes ne sont chargé qu'une fois.  
Ce qui peux etre lent c'est si tu utilises des méthodes de reflexion comme :

Code :
  1. Methods [] mesMethodes = maClass.getDeclaredMethods() ;


puis on image une boucle sur mesMethodes[i].invoque(...)
.
Mais en utilisant des interfaces t'as pas ce problème

n°467103
noldor
Rockn'roll
Posté le 24-07-2003 à 17:22:29  profilanswer
 

phnatomass a écrit :

Franchement si tu pouvais donner des détails.
Tu n'es pas obliger de faire un Class.forName pour tout.
En plus si ta bien penser ton modele , tes plugins devrait tous implementer une interface commmune, en suite avec un patern Factory c'est vite réglé .
ex:

Code :
  1. Plugin p = null;
  2.   String plugingClassName ="";
  3.   switch(choix_utilisateur)
  4.   {
  5.     case FILTRE : plugingClassName= "monprojet.plugin.FiltreGaussien";
  6.     break;
  7.     case ROTATION : plugingClassName= "monprojet.plugin.Rotation180";
  8.     break;
  9.     case NOIR_ET_BLANC :
  10. plugingClassName = "monprojet.plugin.ConvertNB";
  11.     break;
  12.   }
  13. if(!plugingClassName.equals("" ))
  14.   p = Class.forName(plugingClassName);
  15. // application de la transformation
  16. monImage = p.apply(monImage)


 
Dans l'exemple je n'utilise pas de Factory ;)  
 
Concernant la lenteur c'est relatif car tes classes ne sont chargé qu'une fois.  
Ce qui peux etre lent c'est si tu utilises des méthodes de reflexion comme :

Code :
  1. Methods [] mesMethodes = maClass.getDeclaredMethods() ;


puis on image une boucle sur mesMethodes[i].invoque(...)
.
Mais en utilisant des interfaces t'as pas ce problème  

j'ai en effet une interface que tous mes plugins doivent implémenter
bon, je vais réfléchir à tout ça

n°467136
benou
Posté le 24-07-2003 à 18:00:36  profilanswer
 

je vois ce que le Class.forName va pouvoir arranger dans sa situation... quand tu fais class.forName, il cherche la classe parmis son classpath => dans le cadre d'une aplpet, tu ne peux utiliser comme ca que les classes de l'environnement Java et les classes du jar de l'applet ...
 
là ce qu'il veut c'est éviter de devoir télécharger un gros JAR, mais plutot plusieurs petits en fonction de ce dont aura besoin l'utilisateur.
 
ou bien j'ai rien compris au premier post  :heink:


---------------
ma vie, mon oeuvre - HomePlayer
n°467137
noldor
Rockn'roll
Posté le 24-07-2003 à 18:02:14  profilanswer
 

benou a écrit :

je vois ce que le Class.forName va pouvoir arranger dans sa situation... quand tu fais class.forName, il cherche la classe parmis son classpath => dans le cadre d'une aplpet, tu ne peux utiliser comme ca que les classes de l'environnement Java et les classes du jar de l'applet ...
 
là ce qu'il veut c'est éviter de devoir télécharger un gros JAR, mais plutot plusieurs petits en fonction de ce dont aura besoin l'utilisateur.
 
ou bien j'ai rien compris au premier post  :heink:  

voilà, tu as compris (c'était pas clair dans mon post, mais ça l'est pas non plus dans ma tête)

n°467150
benou
Posté le 24-07-2003 à 18:11:22  profilanswer
 

ouais ben il te fait un truc qui fait la même chose que URLClassLoader => si tu l'as pas en JDK1.1, bha faut le recoder [:spamafote]


---------------
ma vie, mon oeuvre - HomePlayer
n°467700
phnatomass
Je m'empare de ton esprit !!
Posté le 25-07-2003 à 14:14:33  profilanswer
 

benou a écrit :

je vois ce que le Class.forName va pouvoir arranger dans sa situation... quand tu fais class.forName, il cherche la classe parmis son classpath => dans le cadre d'une aplpet, tu ne peux utiliser comme ca que les classes de l'environnement Java et les classes du jar de l'applet ...
 
là ce qu'il veut c'est éviter de devoir télécharger un gros JAR, mais plutot plusieurs petits en fonction de ce dont aura besoin l'utilisateur.
 
ou bien j'ai rien compris au premier post  :heink:  


 
Justement j'ai dit de ne PAS faire de jar et de les laisser les fichier .class sur le serveur avec l'arborescence qui va bien . Donc chaque fois que Class.forName var reclamer une classe, l'applet ira chercher le ou les fichier.class neccessaire sur le serveur.
Pas mal d'applet utilise cette technique.

n°467707
noldor
Rockn'roll
Posté le 25-07-2003 à 14:21:05  profilanswer
 

phnatomass a écrit :


 
Justement j'ai dit de ne PAS faire de jar et de les laisser les fichier .class sur le serveur avec l'arborescence qui va bien . Donc chaque fois que Class.forName var reclamer une classe, l'applet ira chercher le ou les fichier.class neccessaire sur le serveur.
Pas mal d'applet utilise cette technique.

oui mais si il y a 500 classes à charger comme ça, ça sera quand même lent

n°467729
phnatomass
Je m'empare de ton esprit !!
Posté le 25-07-2003 à 14:41:06  profilanswer
 

Ton projet comporte 500 classes en tout ou t'as 500 classes pour tes plugins ?
Je pense que tu peux mixer un jar pour ton appli de base et les plugin les laisser sous forme de .class. Mais c'est à tester ou à verifier dans les doc.
Il est vrai que le jar te fait gagner en moyenne env 50% en terme de volume.
Maintenant franchement c'est à toi de voir le rapport entre le volume de tes classes de bases neccessaires à ton appli et le volume des classes des plugin, autre parametres la fréquance d'utilisation de plugin differents dans le temps (En clair est ce que en une minute on utilisera 10 plugin different ou 1 seul).
Et pour finit combien pese ton jar en ko ou mo avec ces  500 classes.

n°467740
noldor
Rockn'roll
Posté le 25-07-2003 à 14:46:48  profilanswer
 

phnatomass a écrit :

Ton projet comporte 500 classes en tout ou t'as 500 classes pour tes plugins ?
Je pense que tu peux mixer un jar pour ton appli de base et les plugin les laisser sous forme de .class. Mais c'est à tester ou à verifier dans les doc.
Il est vrai que le jar te fait gagner en moyenne env 50% en terme de volume.
Maintenant franchement c'est à toi de voir le rapport entre le volume de tes classes de bases neccessaires à ton appli et le volume des classes des plugin, autre parametres la fréquance d'utilisation de plugin differents dans le temps (En clair est ce que en une minute on utilisera 10 plugin different ou 1 seul).
Et pour finit combien pese ton jar en ko ou mo avec ces  500 classes.


l'appli de base est relativement petite (le JAR fait 400 ko)
certains plugins sont petis, une trentaine de classes, d'autres plus gros, ça peut aller jusqu'à 3-400 classes représentant 2-3 Mo.  
Mais tu as raison, faut que je fasse des tests, quitte à opter pour un compromis

n°468059
veryfree
Posté le 25-07-2003 à 18:31:36  profilanswer
 

sache que les jars ne sont pas télécharger a chaque chargement de l'applet, c'est comme pour java web start: ton navigateur verifie que le jar qu' il dispose est le meme que celui qui est sur le serveur>> s il est different il télécharge le nouveau, sinon il charge celui qui est ds les tempory file internet....
 

n°468374
noldor
Rockn'roll
Posté le 26-07-2003 à 11:50:26  profilanswer
 

veryfree a écrit :

sache que les jars ne sont pas télécharger a chaque chargement de l'applet, c'est comme pour java web start: ton navigateur verifie que le jar qu' il dispose est le meme que celui qui est sur le serveur>> s il est different il télécharge le nouveau, sinon il charge celui qui est ds les tempory file internet....
 
 

c'est pas browser dependant ça ??


---------------
http://runnerstats.net
n°468447
veryfree
Posté le 26-07-2003 à 14:45:39  profilanswer
 

noldor a écrit :

c'est pas browser dependant ça ??


 
j ai pas compris ce que tu veux savoir dsl...


Message édité par veryfree le 26-07-2003 à 14:45:48
n°468452
noldor
Rockn'roll
Posté le 26-07-2003 à 14:52:00  profilanswer
 

veryfree a écrit :


 
j ai pas compris ce que tu veux savoir dsl...

je demandais si le mécanisme que tu décrivais était valable pour à peu près tous les navigateurs


---------------
http://runnerstats.net
n°468453
veryfree
Posté le 26-07-2003 à 15:02:12  profilanswer
 

noldor a écrit :

je demandais si le mécanisme que tu décrivais était valable pour à peu près tous les navigateurs


 
je pourrait pas te repondre malheureusement, moi meme je galere avec le plug in java , parfois ca marche parfois ca marche pas :/
 
ce qui est sur c 'est que IE gere les fichiers jar de cette facon

mood
Publicité
Posté le   profilanswer
 


Aller à :
Ajouter une réponse
  FORUM HardWare.fr
  Programmation
  Java

  [JAVA] Mécanisme pour charger des JAR à la demande

 

Sujets relatifs
apllet java IRC et signature????Besoin d'information des système AS 400 (bon connaisseurs demandé)
Pour les pros de JAVA et JSPptite question en java
[résolu][JAVA] Interfaces abstraites en Java --> quel intérêt ?[JAVA/FTP] Question de codage
combiner java et sql[Java ou Delphi] calcul de débit ADSL
[Eclipse] Supprimer des associations entre classes Java ? [résolu]Java et les Webcams
Plus de sujets relatifs à : [JAVA] Mécanisme pour charger des JAR à la demande


Copyright © 1997-2022 Hardware.fr SARL (Signaler un contenu illicite / Données personnelles) / Groupe LDLC / Shop HFR