JNI ou pas, mais transparent

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:

---

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.

Salut,

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

Code:

---

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:

  ---

  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; }

  ---

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 :-(

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:

---

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)));   }   }

---

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.

Citation:

---

Envoyé par ToTo13

- 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:

---

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; }

---

Citation:

---

Envoyé par ToTo13

- 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".

Citation:

---

Envoyé par joel.drigo

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.

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.

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 ?

Citation:

---

Envoyé par joel.drigo

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 ?

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.

Citation:

---

Envoyé par 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

---

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.

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.

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.

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

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:

   ---

   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:

   ---

   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:

   ---

   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:

   ---

   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.

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

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

Citation:

---

Envoyé par tchize_

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:

---

1 2 3 4 5 6 7

public class C {   public ... method(...) { ... new A(...) ... new B(...) ... }   }

---

va devenir

Code:

---

1 2 3 4 5 6 7

public class C implements InterfaceC {   public ... method(...) { ... factory.newA(...) ... factory.newB(...) ... }   }

---

Citation:

---

Envoyé par joel.drigo

Code:

---

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} )" ?

Citation:

---

Envoyé par ToTo13

... 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...).

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).

J'ai utilisé ce code :

Code:

---

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 ?

Citation:

---

Envoyé par ToTo13

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.

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é ?

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.

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.

Citation:

---

Envoyé par ToTo13

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: .

Citation:

---

Envoyé par ToTo13

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.

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:

---

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 :-(

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()

:ave: Merci infiniment, tout fonctionne parfaitement !!! :yaisse2: :yaisse1:

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

Citation:

---

Envoyé par ToTo13

:ave: Merci infiniment, tout fonctionne parfaitement !!! :yaisse2: :yaisse1:

---

:ccool:

Citation:

---

Envoyé par ToTo13

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).