Discussion :

[ptyxs]

Bonjour,
il me semble avoir vu quelque part qu'il était possible de compiler une appli Java de telle sorte qu'elle puisse s'exécuter même dans le cas
où la JVM serait absente de la machine sur laquelle serait exécutée l'appli, ou dans le cas où la version de la JVM de la machine
ne conviendrait pas (par exemple une appli programmée en Java 8 s'exécuterait sur une machine ne contenant que Java 7).

Merci pour toutes infos sur cette possibilité, notamment via Eclipse et Netbeans.

[FaridM]

Salut,

Est-ce que c'est launch4j que tu cherche ?

[ptyxs]

Je ne sais pas mais je vais regarder.
Peut-être plutôt quelque chose qui s'appelle 'native package' ou un nom de ce genre? des liens avec une bonne doc et surtout une doc récente là-dessus pourraient être intéressants...

A vrai dire mon problème principal est celui que je mentionnais plus haut : programmer sous Java 8 et livrer une appli qui soit exécutable sur une machine sous Java 7 sans exiger l'installation de Java 8 sur la machine qui exécutera l'application. Bien que je programme sous Linux la machine cible sur laquelle exécuter l'appli serait plutôt sous Windows.

[Nico02]

Salut,

Il est impossible (a ma connaissance) d'exécuter du code Java sans JVM. C'est elle qui est chargé de convertir le bytecode généré lors de la compilation de ton code source en code machine, et d'assurer ainsi la compatibilité de ton code sur toute les plateformes. Sans cette JVM, la machine est incapable d'interpréter le bytecode et donc de faire fonctionner ton programme.

Il existe la JNI qui permet de faire appel à du code natif depuis du code Java, mais ce code Java lui nécessite bien de s’exécuter dans une JVM.

Pour ce qui est de la compatibilité en version du JRE, Oracle assure une compatibilité ascendante. C'est à dire qu'une application développée pour Java 1.2 fonctionnera aussi avec le tout dernier JRE, mais l'inverse évidement n'est pas vrai. Tu ne pourras pas utiliser les lambas de Java 8 avec une vielle version de ton JRE.

Pour ce qui est de lunch4J, c'est juste un moyen d'encapsuler des .jar dans un .exe, cela ne l'affranchie pas de l'utilisation d'une JVM.

Après il existe la technologie JavaWebStart qui permet (entre autre) de contrôler la version d'une JVM présente sur le poste client. Elle offre aussi la possibilité de la télécharger si nécessaire.

[ptyxs]

Impossible donc d'encapsuler dans un .jar tout ce qui est nécessaire pour faire exécuter l'application (sur un système donné, disons Windows 7 etc.), par conséquent. Impossible d'encapsuler l'application + le JRE qui va bien et le JVM qui va bien, pour qu'une appli compilée sous Java 8 puisse tourner sur un Windows sans Java ou un Windows avec Java 7...

.

[thelvin]

Disons que si un éditeur de JVM voulait faire des outils pour intégrer sa propre JVM avec un seul .jar à lancer avec, le tout encapsulé dans un seul .exe, ce serait possible. Ou alors une JVM Opensource qui fournisse un outil de ce genre.

Mais alors l'exe en question aurait déjà la taille de la JVM, plus la bibliothèque de base Java, plus la taille du programme. En l'état ce n'est pas très intéressant. Pour le coup, des évolutions pour arranger ça sont prévues depuis longtemps (l'idée étant qu'on a pas besoin d'une JVM entière avec toute la bibliothèque de base si on en n'utilise que 10%, et qu'il faudrait donc pouvoir économiser tout ça.) Mais pour l'instant on en voit pas le début de la queue.

[FaridM]

Impossible donc d'encapsuler dans un .jar tout ce qui est nécessaire pour faire exécuter l'application (sur un système donné, disons Windows 7 etc.), par conséquent. Impossible d'encapsuler l'application + le JRE qui va bien et le JVM qui va bien, pour qu'une appli compilée sous Java 8 puisse tourner sur un Windows sans Java ou un Windows avec Java 7...

.

As-tu regardé de plus prêt Launch4j?

La première phrase de leur site :

Launch4j is a cross-platform tool for wrapping Java applications distributed as jars in lightweight Windows native executables. The executable can be configured to search for a certain JRE version or use a bundled one

N'est-ce pas ce que tu recherche ?

[thelvin]

Ah oui, tiens. Jusqu'à maintenant j'en ai seulement vus qui me proposaient d'installer une JRE au lieu d'avoir carrément la sienne.

... Ce qui me renforce un peu dans mon impression que personne trouve ça intéressant en l'état. Mais si c'est ce qui est voulu ici et que ça existe...

[ptyxs]

Merci à tous. Je regarderai tout cela de plus près.
Peut-être y a-t-il quelque chose dans ce sens dans la technique du "native packaging" ou "self-contained application packaging", décrite ici pour JavaFX :
http://docs.oracle.com/javafx/2/depl...g.htm#BCGIBBCI
on y voit que

"Your application is easily deployed on fresh systems with no requirement for Java Runtime to be installed."

[bouye]

Parmi les (très) nombreuses solutions (souvent payantes) de wrappers ou launcher natif, vous en avez plusieurs de gratuits et qui gèrent également les JVM embarquées dans l'application (donc pas besoin de JVM pré-installées sur le système) :

• javapackager (anciennement javafxpackager), la solution d'Oracle dispo depuis le JDK7 -> multiplateforme, génère installeur + launcher natif Windows, Mac OS X, Linux
• Launch4J -> multiplateforme, génère launcher natif Windows
• WinRun4J -> exécutable launcher natif Windows 32bit ou 64bit précompilé à customiser (très facile). À coupler avec un générateur d'installeur (NSIS ou autre) pour créer une distribution.

Par contre je confirme qu'on se retrouve a la fin avec une application constituée d'un launcher de qq dizaines/centaines de Ko, de 500Ko-10Mo de JAR propres à l'application + dépendances ... et de 50+Mo de JVM embarquée pour faire tourner le tout... Mais c'est alors un moindre mal puisqu'on a plus de problèmes de versions de la JVM ou encore des soucis avec des utilisateurs qui ne peuvent pas l'installer car n'ayant pas les droits.

[ptyxs]

Merci beaucoup.