Lancer un .jar depuis un .jar

Bonjour,
je sais bien que la question est répandue, mais après avoir écumé pas mal de forum, je me suis rendu compte que partout on dit de faire ceci :

Runtime.getRuntime().exec("java -jar le_fichier_jar");

seulement, cette méthode marche-t-elle sur tous les OS ?

Sur un autre forum quelqu'un parle d'utiliser

Code:

---

Thread.currentThread().getContextClassLoader().getResource(...)

---

mais je n'ai pas réussi à mettre en application cette piste ...

merci d'avance.

Bonjour,

A partir du moment où java et le fichier jar sont disponible est accessible il n'y a pas de raison que ça ne marche pas.

bien sûr, seulement, c'est des lignes de commandes si je ne m'abuse.
Même si c'est la même chose sous windows et linux, se n'est sans doute pas pareil pour tous les OS ... si ?
merci.

Cette commande est problématique.

D'abord elle fait appel à l'installation par défaut de java, qui n'est pas nécessairement la même que celle qui a donné naissance à votre application courante.
Ensuite, des gens comme moi, n'ont pas d'installation java par défaut. Quand je lance un jar je tappe
/home/tchize/apps/jdkxxx/bin/java

C'est une habitude de développeur, je fais coexister tellement de jvm qu'il vaut mieux éviter d'en utiliser une par défaut.

Je n'ai cependant pas de solution 100% efficace à te proposer en remplacement :)

d'accord, je comprend ... donc j'ai fait comme tout le monde, et si une exception est levée, je dit à l'utilisateur qu'il peu lancer manuellement le .jar à telle chemin ...
merci beaucoup.

NB

pour info, c'est pour un système de mise à jour automatique ;)

Citation:

---

Envoyé par Dominique49

Runtime.getRuntime().exec("java -jar le_fichier_jar");

seulement, cette méthode marche-t-elle sur tous les OS ?

---

Presque...

Comme l'a dit tchize_ il faut que java soit installé et configuré par défaut sur le système.

Mais il faut également que le chemin ne comporte pas d'espace ou de caractères spéciaux qui pourrait géner.

:arrow: Il est préférable de passer par exec(String[]) qui permet de séparer les paramètres proprement, ou mieux via ProcessBuilder.

De plus sous Windows les Jar ne sont lancé par java mais par javaw (qui est la version graphique).


De même, il faut impérativement fermer les flux d'entrées/sorties si on ne les utilises pas...

Citation:

---

Envoyé par Dominique49

Sur un autre forum quelqu'un parle d'utiliser

Code:

---

Thread.currentThread().getContextClassLoader().getResource(...)

---

mais je n'ai pas réussi à mettre en application cette piste ...

---

C'est hors-sujet : ce n'est pas pour lancer un jar indépendant, mais pour y récupérer des ressources...

Citation:

---

Envoyé par tchize_

Je n'ai cependant pas de solution 100% efficace à te proposer en remplacement :)

---

:arrow: System.getProperty("java.home").

Cette propriété te permet normalement de récupérer le chemin d'installation du JRE courant. A partir de là du peux reconstruire le chemin complet.

Ainsi ceci devrait faire l'affaire :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

public static void launch(String jarFileName) throws IOException { boolean isWindows = System.getProperty("os.name").toLowerCase().contains("windows");   // On récupère le chemin depuis "java.home" : File java = new File(System.getProperty("java.home"), isWindows ? "bin/javaw.exe" : "bin/java" );   // On lance le jar : Process p = new ProcessBuilder( java.getAbsolutePath(), "-jar", jarFileName).start(); p.getInputStream().close(); p.getOutputStream().close(); p.getErrorStream().close();   }

---

a++

salut, merci beaucoup pour tout ceci !
juste une question, la commande java paraît tout aussi bien marcher que javaw ... quelle est la différence en fait ?

Code:

---

De même, il faut impérativement fermer les flux d'entrées/sorties si on ne les utilises pas...

---

Pourquoi ? parce que ça pourrait perturber l'autre .jar ?

merci.

Citation:

---

Envoyé par Dominique49

juste une question, la commande java paraît tout aussi bien marcher que javaw ... quelle est la différence en fait ?

---

Sous les systèmes Windows il y a deux types d'applications. Donc on a deux version de java :

• java correspond à la version "console", associé à une console type "DOS".
• javaw correspond à la version graphique, indépendant de toute console.

Pour lancer un programme disposant d'un interface utilisateur sous Windows, javaw est donc plus indiqué que java. Maintenant si tu le lances depuis un programme Java la console devrait être invisible donc ca ne change pas grand chose...


Sous les autres OS il n'y a pas de tel distinction entre application console et graphique...

Citation:

---

Envoyé par Dominique49

Code:

---

De même, il faut impérativement fermer les flux d'entrées/sorties si on ne les utilises pas...

---

Pourquoi ? parce que ça pourrait perturber l'autre .jar ?

---

Lorsque tu lances un Process via ProcessBuilder ou Runtime.exec(), ses flux d'entrés/sorties sont lié au processus courant via de "petit" buffer. Si tu traites pas correctement ces flux cela peut bloquer le processus (fils ou courant).

Il est donc impératif de les traiter ou de les fermer (si tu ne les utilises pas).

Exemple de blocage : le process fils génère des logs lorsqu'il démarre, qui vont remplir le "buffer". Si le process "parent" ne traite pas le flux, le buffer ne sera jamais vidé et le process fils restera bloqué en écriture.


Le fait de les fermer détruira le buffer et renverra les infos vers /dev/null (ou NUL sous Windows), ce qui fait que tout sera perdu, mais sans blocage.



Dans ton cas, je suppose que tu stoppes le process parent juste après donc la fermeture des flux est implicite... Mais il est préférable de prendre de bonne habitude.





A noter qu'avec Java 7 tu peux utiliser inheritIO() pour mapper directement les flux du process que tu lances sur le process courant, et du coup tu n'as plus rien à faire du tout :D

Code:

---

1 2	Process p = new ProcessBuilder( java.getAbsolutePath(), "-jar", jarFileName) .inheritIO().start();

---

a++