Discussion :

[joel.drigo]

... que l'url ne soit pas déjà dans le classpath, ne serait il pas équivalent de simplement faire "URLClassLoader ucl = new URLClassLoader(new URL[]{url} )" ?

Ça, ça créé un nouveau classloader indépendant du classloader système. On peut le faire, mais un new ne fonctionnera pas, parce que le classloader système ne connaitra pas cet url, donc ne trouveras pas la classe. Pour instancier la classe, il faudra la charger par ucl.loadClass() qui te renveras une instance de Class, sur laquelle tu pourras faire un newInstance() pour l'instancier. Une autre solution serait de faire un classloader personalisé (à base d'URLClassLoader, mais en gérant soit-même ce que fait le system classloader(!)) et de lancer l'application avec ce classloader (java -Djava.system.class.loader=la classe de classloader personalisée...).

[joel.drigo]

Addendum : j'ai aussi essayé en changeant le classloader du contexte (Thread.currentThread().setContextClassLoader()), mais ça ne fonctionnait pas d'une part (peut-être pour la même raison qu'actuellement, puisque je n'ai testé qu'avec les jars embarqués — cependant entre temps, m'est venue une petite idée de la raison que je testerai peut-être ce soir), mais aussi parce qu'on ne modifie que le classloader du thread courant (donc, potentiellement, on aura des problèmes sur d'autres threads).

[ToTo13]

J'ai utilisé ce code :

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
 
	String jar = "monjar.jar" ;
	URLClassLoader ucl = (URLClassLoader) ClassLoader.getSystemClassLoader() ;
	Class<?> sysclass = URLClassLoader.class;
 
	try {
		Method method = sysclass.getDeclaredMethod("addURL", new Class<?>[]{URL.class}) ;
		method.setAccessible(true) ;
		method.invoke(ucl, new Object[]{new URL("jar", "", jar)}) ;
		}
	catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e)
		{
		e.printStackTrace() ;
		System.err.println("Error, could not add URL to system class loader") ;
		System.exit(-1) ;
		}

Tout ce passe bien alors que ça ne devrait pas, car monjar.jar n'existe pas.
Du coup lorsque j'appelle l'une des méthodes qui aurait dû être chargée, j'ai très logiquement une java.lang.NoClassDefFoundError
Une idée pourquoi je n'ai pas d'erreur ?

[joel.drigo]

Une idée pourquoi je n'ai pas d'erreur ?

Oui, il n'y a pas d'erreur lorsqu'on donne une url qui référence un fichier qui n'existe pas. Comme quand on fait un java -cp .;machin.jar toto et que machin.jar n'existe pas.

[ToTo13]

Ok, tout fonctionne très bien sur le principe, sauf un petit détail.

Je construit jar avec NetBeans et pour pouvoir compilé correctement il faut que j'indique l'un des deux jar (natif ou non). Du coup son nom se retrouve automatiquement dans le classpath et par conséquent il est chargé au lancement.

Est ce qu'il est possible de préciser à NetBeans de ne pas lister un jar ?
Ou est ce que l'on peut modifier le classpath d'un jar une fois que celui-ci a été construit/compilé ?

[joel.drigo]

Personnellement, pour faire le test, j'ai simplement modifié le manifest pour virer le jar dans la classpath. Je ne sais pas si on peut paramétrer NetBeans pour que le jar ne soit pas inclus dans la classpath, mais on doit pouvoir faire une task ant pour automatiser ça.

[ToTo13]

Oui, mais le manifest est dans le jar ! Comment est ce que tu peux le modifier ?

L'idéal serait de la faire avant la construction du jar.

[joel.drigo]

Oui, mais le manifest est dans le jar ! Comment est ce que tu peux le modifier ?

Je l'ai fait avec 7z : tu ouvres le jar, et tu édites le manifest avec la fonction Editer, dans la propriété Class-Path Class-Path: .

L'idéal serait de la faire avant la construction du jar.

Certes. Mais je n'utilise pas NetBeans pour développeer (seulement pour profiler) , donc je ne sais pas si c'est possible de le faire dans NetBeans. La création du jar dans NetBeans ne modifie-t-elle pas le build.xml qu'il y a dans le project ? Il suffirait alors de modifier le build.xml pour faire une build spécifique. Sinon, il faut l'écrire complètement.

[ToTo13]

N'importe quel soft de décompression fait le boulot pour décompresser, puis il suffit juste d'utiliser "jar", via la commande : jar -cmf META-INF/MANIFEST.MF monjar.jar *

Malheureusement, je m'aperçois maintenant que mon code ne charge pas du tout le fichier jar :-(

Code java :

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

1
2
3
4
5
6
7
8
9
10
 
String jar = "lib/Core" + (CallNative ? "Native" : "") + ".jar" ;
if ( new File(jar).exists() )
	{
	URLClassLoader ucl = (URLClassLoader) ClassLoader.getSystemClassLoader() ;
	Class<?> sysclass = URLClassLoader.class ;
	Method method = sysclass.getDeclaredMethod("addURL", new Class<?>[]{URL.class}) ;
	method.setAccessible(true) ;
	method.invoke(ucl, new Object[]{new URL("jar", "", jar)}) ;
	}

Le jar existe et je n'ai aucune erreur au chargement.
Mais lorsque j'appelle une classe qu'il contient, j'ai une magnifique java.lang.NoClassDefFoundError :-(

[joel.drigo]

Là, ton jar est un fichier, donc il faut que tu crées l'URL avec le protocole file, par jar.

Ou tout simplement : file.toURI().toURL()

[ToTo13]

Merci infiniment, tout fonctionne parfaitement !!!

Par ailleurs, je viens de trouver cela à l'instant et ça semble faire la même chose : JCL.

[joel.drigo]

Merci infiniment, tout fonctionne parfaitement !!!

Par ailleurs, je viens de trouver cela à l'instant et ça semble faire la même chose : JCL.

Interessant ! Peut-être y trouvera-t-on la solution pour faire fonctionner le programme avec des jars embarqués. Je n'ai pas eu le temps de creuser de mon côté (j'ai dans l'idée que peut-être que l'URLClassLoader ne gère pas le protocole jar justement, et qu'il faut implémenter cette prise en charge).
Mais si ça te convient de fonctionner avec des jars externes, je ne poursuivrai probablement pas mon investigation (surtout si une API fait déjà le boulot).