Discussion :

[ToTo13]

Bonjour,

j'utilise depuis peu JNI afin d'accélérer certains traitements.
TOUT ce qui je fais avec JNI, je peux aussi le faire avec Java car j'ai le code en double.
Ce qui je souhaiterai, c'est pouvoir au lancement de mon appli
- scanner toutes les classes de ma librairie
- détecter les méthodes natives
- si la librairie native existe et que la méthode existe dans la librairie native
-----> Pointer sur la méthode native
-----> Pointer sur la méthode java

Quelque chose du genre :

Code java :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
public static void mamethode()
{
// Appeler la méthode native si elle a été détectée au lancement du programme, sinon la méthode java.
}
 
private static void mamethodenative() ;
 
private static void mamethodejava()
{
// mon code java
}

J'aimerai éviter de faire un test à chaque appel de la méthode.

Est ce que quelqu'un aurait une idée ?
Merci par avance.

[joel.drigo]

Salut,

Premièrement, tu peux déterminer si une méthode existe dans une classe et si elle est native, par réflexion :

Code :

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
17
public boolean isNativeMethodExists(Class<?> klass, String methodName, Class<?>...parameterTypes) {
   try {
      final Method method = klass.getMethod(methodName, parameterTypes);
      return Modifier.isNative(method.getModifiers());
   } catch (NoSuchMethodException | SecurityException e) {
      return false;
   }
}
 
public boolean isNotNativeMethodExists(Class<?> klass, String methodName, Class<?>...parameterTypes) {
   try {
      Method method = klass.getMethod(methodName, parameterTypes);
      return !Modifier.isNative(method.getModifiers());
   } catch (NoSuchMethodException | SecurityException e) {
      return false;
   }
}

Reste à "scanner" les classes. Ceci normalement n'est pas possible en Java. 2 solutions :

• Utiliser une variable (liste, tableau) pour stocker toutes les classes à analyser (donc qu'il faut initialiser à la main)
• scanner les fichiers .class dans les dossiers du classpath, ou scanner les entrées des jar s'y trouvant
  Ce que tu peux faire avec ces méthode :
  

  Code :

  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
  17
  18
  19
  20
  21
  22
  23
  24
  25
  26
  27
  28
  29
  30
  31
  32
  33
  34
  35
  36
  37
  38
  39
  40
  41
  42
  43
  44
  45
  46
  47
  48
  49
  50
  51
  52
  53
  54
  55
  56
  57
  58
  59
  60
  61
  public static List<Class<?>> getClassesFromPackage(String packageName) throws IOException, URISyntaxException{
     return getClassNamesFromPackage(packageName).stream()
                                                 .map(className-> toClass(className))
                                                 .filter(c->c.isPresent())
                                                 .map(c->c.get())
                                                 .collect(Collectors.toList());
  }
   
  private static Optional<Class<?>> toClass(String className) {
     try {
        return Optional.of(Class.forName(className));
     } catch (ClassNotFoundException e) {
        e.printStackTrace();
        return Optional.empty();
     }
  }
   
  public static List<String> getClassNamesFromPackage(String packageName) throws IOException, URISyntaxException{
     final ClassLoader classLoader = Thread.currentThread().getContextClassLoader();
     final List<String> names = new ArrayList<String>();;
   
     final String jarPackageName = packageName.replace(".", "/");
     final URL packageURL = classLoader.getResource(jarPackageName);
   
     if (packageURL==null) {
        throw new IllegalStateException("Not found: "+packageName);
     }
     if("jar".equals(packageURL.getProtocol())){
   
        final int start = packageName.length()>0?packageName.length()+1:0;
   
        // build jar file name, then loop through zipped entries
        String jarFileName = URLDecoder.decode(packageURL.getFile(), "UTF-8");
        jarFileName = jarFileName.substring("file:/".length(),jarFileName.indexOf("!"));
        try( JarFile jf = new JarFile(jarFileName) ) {
           for(Enumeration<JarEntry> jarEntries = jf.entries();jarEntries.hasMoreElements(); ){
  	     String entryName = jarEntries.nextElement().getName();
  	     if ( entryName.startsWith(jarPackageName) && entryName.endsWith(".class")){
                  entryName = entryName.substring(start,entryName.lastIndexOf('.'));
  		if ( !entryName.contains("/") ) {
  		    names.add(packageName+"."+entryName);
  		}
  	     }
           }
       }
     } else if ( "file".equals(packageURL.getProtocol()) ){
        final File folder = new File(packageURL.toURI().getPath());
        final File[] content = folder.listFiles();
        if ( content!=null ) {
           for (File actual : content) {
  	    String entryName = actual.getName();
              entryName = entryName.substring(0, entryName.lastIndexOf('.'));
              names.add(packageName+"."+entryName);
           }
       }
     }
     else {
        throw new IllegalStateException("Cannot extract class from " + packageURL);
     }
     return names;
  }

[ToTo13]

Merci beaucoup pour ces informations.

Je suppose que pour tester si une méthode java déclarée "native", pointe bien sur vers une méthode native, il faut tenter de l'appeler. Correct ?

Une idée comment pointer efficacement sur l'une ou l'autre des méthodes ?
Pointer sur une classe ou une autre est facile avec des interfaces, mais des méthodes... pas d'idée :-(

[joel.drigo]

En gros, tu voudrais savoir si l'appel d'une méthode native va soulever une UnsatisfiedLinkError ?

Je pense qu'on devrait le faire en amont, au moment du chargement de bibliothèque native (System.loadLibrary()), en chargeant le bon jar (voir URLClassLoader) en fonction de l'echec ou non du chargement de bibliothèque native (en faisant 2 jar identiques, l'un avec les classes avec les méthode natives. l'autre avec les classes avec les méthodes non natives, mêmes noms, mêmes packages, mêmes méthodes, même signatures, etc.). Plus besoin de scan ou de test : il te suffit de programmer avec l'un des deux jars (de préférence le non natif pour faire les tests dans l'IDE) dans le classpath, mais de ne pas l'exporter dans le classpath, mais en intégrant les 2 fichiers jar dans le jar de l'application.

Sinon, je ne sais pas si on peut tester si l'appel d'une méthode native va soulever une UnsatisfiedLinkError. La méthode bourrine serait d'appeler la méthode et en cas d'exception rediriger vers la méthode non native.

On pourrait faire ça par réflexion, mais on perdrait l'avantage de pouvoir tester les types des paramètres à la compilation (sans parler de la completion), donc il faudrait faire attention aux paramètres qu'on passe (et on ne sait qu'on s'est planté qu'à l'exécution), ou alors il faudrait faire un handler pour chaque couple de méthodes, avec les bons paramètres (du coup, plus vraiment d'intérêt de scanner). On pourrait aussi générer ces classes en avance, ou éventuellement dynamiquement au lancement de l'application.

Ou alors faire un handler avec des lambdas, mais on est obligé systématiquement de duppliquer l'appel, et puis ça peut devenir lourd d'écrire tous les appels comme ça, sans parler des enchainements d'appels...

Genre quelque chose comme ça :

Code :

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
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
public class CallHandler<T> {
 
	private boolean callNative=true;
 
	public T call(Supplier<T> nativeCall, Supplier<T> nonNativeCall) {
 
		if( callNative ) {
			try {
				return nativeCall.get();
			}
			catch( UnsatisfiedLinkError e ) {
				callNative=false;
				return nonNativeCall.get();
			}
		}
		else {
			return nonNativeCall.get();
		}
 
	}
 
	public static class Test {
		public native int nativeTestMethod(int param);
		public int testMethode(int param) {
			return param;
		}
	}
 
	public static void main(String[] args) {
 
		Test test=new Test();
 
		System.out.println(new CallHandler<Integer>().call(()->test.nativeTestMethod(100), ()->test.testMethode(100)));
 
	}
 
}

[ToTo13]

Oui, j'ai l'impression qu'il n'y a pas de solution facile :-(
Dans mon cas je n'ai que peu de méthodes natives et elles sont toutes dans la même librairie.
Je pense à une solution du type
- une interface qui désigne les classes ayant des méthodes natives
- scan de toutes les classes
- les classes qui implémentent l'interface ont une méthode static qui teste chaque méthode native et fait le lien qu'il faut. Dans ce cas le lien serait un simple test sur un booléen.

C'est moche, c'est long, mais simple.

En tout cas merci pour tes réponses.

[joel.drigo]

- une interface qui désigne les classes ayant des méthodes natives

A la place, tu peux parcourir simplement toutes les méthodes de classes pour tester si l'une est native.

Code :

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

1
2
3
4
5
6
7
8
public static boolean hasNativeMethod(Class<?> klass) {
   for(Method method : klass.getMethods()) {
      if ( Modifier.isNative(method.getModifiers()) ) {
	  return true;
      }
   }
   return false;
}

- les classes qui implémentent l'interface ont une méthode static qui teste chaque méthode native et fait le lien qu'il faut. Dans ce cas le lien serait un simple test sur un booléen.

Pourquoi mettre une méthode statique dans chaque classe : une seule suffit pour l'ensemble des classes. Ou alors tu as besoin de traiter des informations spécifiques pour chaque classe et chaque méthode native. Peut-être qu'un fichier descripteur à part pourrait faire l'affaire. Ou alors une annotation (mais je ne sais pas si on peut faire une annotation sur une méthode native). Peut-être un aspect serait la solution (pour rediriger l'appel vers la méthode non native si c'est ce que tu cherches à faire).
Par contre, je ne comprends pas ce que tu veux dire par "le lien serait un simple test sur un booléen".

[ToTo13]

Peut-être un aspect serait la solution (pour rediriger l'appel vers la méthode non native si c'est ce que tu cherches à faire).

Oui, ça ressemble à ce que je souhaite !
Pour faire simple, si le System.loadLibrary n'a pas renvoyé d'erreur alors on appelle les méthodes natives, sinon on appelle les méthodes java.

[ToTo13]

Je viens de jeter un coup d'oeil à AspectJ et dans mon cas je ne vois pas vraiment son intérêt.
Les pointcut s'exécutent avant/après l'appel d'une méthode. Dans mon cas ce serait plutôt "à la place" de la méthode afin de cibler le java ou le natif.
De plus, je devrai en définir un par méthode, ce qui serait aussi long que de faire un simple test.

[joel.drigo]

Je n'ai jamais pratiqué la programmation AOP, donc je ne sais pas concrètement ce qu'on peut faire et comment. J'ai l'impression qu'on peut définir des points de jonction avec des masques, ce qui permettrait de définir l'aspect pour un ensemble de méthode, voire toutes en théorie. Pour le remplacement, effectivement, je ne sais pas si c'est possible. Maintenant, en théorie, techniquement, il n'y a aucun obstacle pour le faire. Sinon, sans passer nécessaire par AspectJ (ou autre système AOP), générer automatiquement des proxys n'est pas très compliqué (et ça éviterait d'avoir à mettre une méthode statique dans toutes les classes — si tu en 10 ça va, si tu en as 500, c'est déjà plus fastidieux).
Mais la méthode par chargement dynamique de jar ne te conviendrait pas ? Ça me semble la technique la plus simple, non ?

[ToTo13]

Mais la méthode par chargement dynamique de jar ne te conviendrait pas ? Ça me semble la technique la plus simple, non ?

Comment est ce que cela fonctionnerait ?

[joel.drigo]

L'idée c'est 2 faire 2 bibliothèques (2 jar) : une qui contient les classes avec methodes native, et une avec leur équivalent avec méthode non native. Elles ont exactement la même structure de package, les mêmes classes et qui ont les mêmes méthodes. On ne mets pas les jars dans le classpath : on les charge par un URLClassLoader personalisé, qui appelle le System.loadLibrary, et en fonction de l'echec ou la réussite, charge le jar correspondant. Quand tu programmes dans un IDE, tu montes l'un des deux jars, ce qui te permet de compiler, et d'avoir la completion, etc. C'est juste une idée, et j'essayerais bien concrètement, mais je n'ai pas trop le temps maintenant. Pour le chargement dynamique de jar par URLClassLoader, je le pratique justement dans le programme Eclipse RCP que je suis en train de travailler. Ma problématique est différente : j'ai besoin d'installer une application web externe dans un projet (Dynamic Web Application). J'ai plusieurs versions de cette application web (sous forme de war, contenant des jars). L'utilisateur choisit une version dans une liste, et je contrôle si la version de l'application et la version de compilation sont compatibles avec le paramétrage du projet. Donc je charge dynamiquement le jar depuis le war (sans le décompresser), j'instancie dynamiquement une classe qui contient la constante qui définit la version de l'application (qui je lis par réflection). C'est même plus complexe que dans ton cas, puisque je charge plusieurs classes ayant le même package et le même nom. Dans ton cas, c'est plus simple : il suffit que le jar soit accessible par le classloader standard pour que les classes soient instanciables. Un peu à la manière des fragments OSGI en fait (d'ailleurs ça aussi je le fais dans une autre application, et ça ressemble peut-être plus à ce que tu veux faire : en fait, j'ai une API avec méthode native, avec une version 32bits et une version 64bits, pour windows et macintosh. Dans mon code, je code avec l'API 32 bits Windows, mais selon que l'application soit exécutée en 32 ou 64 bits, et selon l'OS, c'est un jar ou un autre qui est chargé, avec une bibliothèque native ou une autre. Bon, pour le coup c'est OSGI qui me fait tout le boulot de distribuer et de charger la bonne version, mais ce n'est pas très compliqué à faire.

[ToTo13]

L'idée c'est 2 faire 2 bibliothèques (2 jar) : une qui contient les classes avec methodes native, et une avec leur équivalent avec méthode non native. Elles ont exactement la même structure de package, les mêmes classes et qui ont les mêmes méthodes. On ne mets pas les jars dans le classpath : on les charge par un URLClassLoader personalisé, qui appelle le System.loadLibrary, et en fonction de l'echec ou la réussite, charge le jar correspondant. Quand tu programmes dans un IDE, tu montes l'un des deux jars, ce qui te permet de compiler, et d'avoir la completion, etc. C'est juste une idée

Une idée qui me plait bien et que je vais tester (asap, mais là faut que je dorme un peu :p). Ca a vraiment l'air de correspondre à mes besoins et ça semble vraiment simple.

[ToTo13]

Ne serait il pas possible de charger par défaut un jar et si les méthodes natives sont disponibles, alors on charge le nouveau jar ?
Ca remplacerait les anciennes classes java par les nouvelles qui font des appels natifs.

[joel.drigo]

On ne peut pas procéder comme ça. Ce n'est un problème de jar, mais de classe. A partir du moment où une classe est chargée depuis un jar, on a beau charger un autre jar avec la même classe, la classe provenant du premier jar étant déjà chargée, ce sera elle qui sera toujours utilisée. Il faut absolument déterminer quel jar charger avant de charger la moindre classe ayant 1 version dans chaque jar.

[ToTo13]

ok... la poisse pour moi :-(
Je vais donc tester en faisant ainsi.

[joel.drigo]

J'ai essayé de monter un POC. Il fonctionne si les jars sont externes et qu'on les charge en tant que fichiers, mais je n'arrive pas à faire fonctionner le POC avec des jars embarqués chargés par URL (un problème probablement simple à résoudre, mais vu que je n'ai pas dormi depuis avant-hier, je suis HS et je n'ai plus trop les yeux en face des trous ).

Si tu veux jouer avec :

1. j'ai fait une fausse API native constiuée d'une classe :
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   package fr.developpez.api;
    
   public class Sample {
    
   	public void method() {
   		System.out.println("I'm (actually not) native!");
   	}
    
   }

2. J'ai fait une fausse api non native constituée de la même classe
   

   Code :

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

   1
   2
   3
   4
   5
   6
   7
   8
   9
   package fr.developpez.api;
    
   public class Sample {
    
   	public void method() {
   		System.out.println("I'm not native!");
   	}
    
   }

3. J'ai fait un jar pour chaque api (respectivement apinative.jar et api.jar)
4. J'ai fait une classe utilitaire pour pour charger dynamiquement un jar ou l'autre : je simule l'echec de chargement de la bibliothèque native avec un dialogue à choix multiples
   

   Code :

   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
   17
   18
   19
   20
   21
   22
   23
   24
   25
   26
   27
   28
   29
   30
   31
   32
   33
   34
   35
   36
   37
   38
   39
   40
   41
   42
   43
   44
   45
   46
   47
   48
   49
   50
   51
   52
   53
   54
   55
   56
   57
   58
   59
   60
   61
   62
   63
   64
   65
   66
   67
   68
   69
   70
   71
   72
   73
   74
   75
   76
   77
   78
   79
   80
   81
   82
   83
   84
   85
   86
   87
   88
   89
   90
   91
   92
   93
   94
   95
   96
   97
   98
   99
   100
   101
   102
   103
   104
   105
   106
   package fr.developpez.dynapipoc;
    
   import java.io.File;
   import java.lang.reflect.InvocationTargetException;
   import java.lang.reflect.Method;
   import java.net.MalformedURLException;
   import java.net.URL;
   import java.net.URLClassLoader;
    
   import javax.swing.JOptionPane;
    
   public class InitClassLoader {
    
   	private static final String PARAMETER_USE_FILE = "useFile";
    
   	private static final String APINATIVE = "apinative.jar";
   	private static final String API = "api.jar";
    
   	private static final String PACKAGE = Main.class.getPackage().getName().replace('.', '/') + "/lib/";
   	private static final String APINATIVEJAR = PACKAGE + APINATIVE;
   	private static final String APIJAR = PACKAGE + API;
    
   	public static void init() {
   		switch (JOptionPane.showOptionDialog(null, "Choose API", "POC",
   				JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.QUESTION_MESSAGE,
   				null, new Object[] { "Native", "Not native", "Exit" }, 0)) {
   		case JOptionPane.YES_OPTION:
   			loadNativeApi();
   			break;
   		case JOptionPane.NO_OPTION:
   			loadNotNativeApi();
   			break;
   		default:
   			System.err.println("Exit");
   			System.exit(-1);
   		}
   	}
    
   	private static void loadNativeApi() {
   		if ( useFile() ) {
   			addFile(APINATIVE);
   		}
   		else {
   			loadAPI(APINATIVEJAR);
   		}
   	}
    
   	private static void loadNotNativeApi() {
   		if ( useFile() ) {
   			addFile(API);
   		}
   		else {
   			loadAPI(APIJAR);
   		}
   	}
    
   	private static boolean useFile() {
   		return Boolean.getBoolean(PARAMETER_USE_FILE);
   	}
    
   	private static void loadAPI(String jar) {
   		final URL url = Main.class.getClassLoader().getResource(jar);
   		addURL(url);
   	}
    
       private static final Class<?>[] PARAMETERS = new Class[]{URL.class};
    
       public static void addFile(String s) {
           File f = new File(s);
           addFile(f);
       }
    
       public static void addFile(File f) {
           try {
   			addURL(f.toURI().toURL());
   		} catch (MalformedURLException e) {
   			e.printStackTrace();
   			System.exit(-1);
   		}
       }
    
   	public static void addURL(URL url) {
    
   		URLClassLoader sysLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
   		URL urls[] = sysLoader.getURLs();
   		for (int i = 0; i < urls.length; i++) {
   			if (urls[i].toString().equalsIgnoreCase(url.toString())) {
   				System.err.println("URL " + url + " is already in the CLASSPATH");
   				return;
   			}
   		}
   		Class<?> sysclass = URLClassLoader.class;
   		try {
   			Method method = sysclass.getDeclaredMethod("addURL", PARAMETERS);
   			method.setAccessible(true);
   			System.out.println("Add url "+ url);
   			method.invoke(sysLoader, new Object[] { url });
   		} catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
   			e.printStackTrace();
   			System.err.println("Error, could not add URL to system classloader");
   			System.exit(-1);
   		}
    
   	}
    
   }

5. Puis un programme à exécuter
   

   Code :

   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
   17
   18
   19
   20
   21
   22
   23
   package fr.developpez.dynapipoc;
    
   import fr.developpez.api.Sample;
    
   public class Main {
    
   	public static void main(String[] args) {
    
   		System.out.println("Init");
   		InitClassLoader.init();
    
   		System.out.println("Create instance of class Sample");
   		final Sample sample = new Sample();
    
   		System.out.println("Invoking method...");
   		sample.method();
    
   		System.out.println("Finished.");
   		System.exit(0);
    
   	}
    
   }

6. j'ai embarqué les jars d'api dans le dossier fr/developpez/dynapipoc/lib
7. il y a un paramètre booléen pour charger les jars par fichier, ou par url : useFile
   La command pour lancer l'application en mode "file" est donc : java -DuseFile=true -jar poc.jarEt par url : java -DuseFile=false -jar poc.jar ou java -jar poc.jar
8. il suffit de dezziper la pièce jointe dans un dossier, d'ouvrir un shell et de se placer dans ce dossier, puis de lancer la commande voulu
   Si tu choisi l'option "native", tu verras (j'ai mis les jars dans c:\temp):
   

   Init
   Add url file:/C:/Temp/apinative.jar
   Create instance of class Sample
   Invoking method...
   I'm (actually not) native!
   Finished.

   Si tu choisis l'option "non native", tu verras :
   

   Init
   Add url file:/C:/Temp/api.jar
   Create instance of class Sample
   Invoking method...
   I'm not native!
   Finished.

[ToTo13]

Merci infiniment pour ton aide, je vais regarder tout ça.
Je suis en train de modifier ma librairie pour faire de même.

[tchize_]

Factory, interface et c'est réglé de manière propre, pas avec des crasses de scan auto d'introspection et de pointcut.

[joel.drigo]

Factory, interface et c'est réglé de manière propre, pas avec des crasses de scan auto d'introspection et de pointcut.

S'il n'y a pas beaucoup de classes, c'est certes une solution plus propre. Mais plus il y a de classes, plus ça fait de boulot, en particulier parce qu'il faut aussi modifier le code de ces classes :

Code :

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

1
2
3
4
5
6
7
public class C {
 
    public ... method(...) {
        ... new A(...) ... new B(...) ...        
    }
 
}

va devenir

Code :

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

1
2
3
4
5
6
7
public class C  implements InterfaceC {
 
    public ... method(...) {
        ... factory.newA(...) ... factory.newB(...) ...        
    }
 
}

[ToTo13]

Code :

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
17
18
19
20
21
public static void addURL(URL url) {
		URLClassLoader sysLoader = (URLClassLoader) ClassLoader.getSystemClassLoader();
		URL urls[] = sysLoader.getURLs();
		for (int i = 0; i < urls.length; i++) {
			if (urls[i].toString().equalsIgnoreCase(url.toString())) {
				System.err.println("URL " + url + " is already in the CLASSPATH");
				return;
			}
		}
		Class<?> sysclass = URLClassLoader.class;
		try {
			Method method = sysclass.getDeclaredMethod("addURL", PARAMETERS);
			method.setAccessible(true);
			System.out.println("Add url "+ url);
			method.invoke(sysLoader, new Object[] { url });
		} catch (NoSuchMethodException | SecurityException | IllegalAccessException | IllegalArgumentException | InvocationTargetException e) {
			e.printStackTrace();
			System.err.println("Error, could not add URL to system classloader");
			System.exit(-1);
		}
	}

Je suis un peu surpris par ce morceau de code.
Tu utilises "URLClassLoader sysLoader = (URLClassLoader) ClassLoader.getSystemClassLoader()" pour récupérer le ClassLoader, puis vérifies que l'url que l'on ajoute n'est pas déjà dans le classpath.
Ensuite tu utilises une Methode et ajoute l'url avec "method.invoke(sysLoader, new Object[] { url })".

Si ce n'est le fait de vérifier 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} )" ?