Discussion :

[Spidy]

salut à tous,

j'aimerais savoir s'il était possible (et si oui comment) compiler un programme Java en un fichier .exe pour pouvoir lancer ce programme sans devoir installer le JDK.

pour par exemple pouvoir filer le programme à ses amis et qu'il puissent tester ce dernier (bugs, suggestions...)

[nouknouk]

gcj

[Spidy]

ça a l'air pas mal, sinon j'ai trouvé JET, 100% compatible mais payant.

la version démo dure 90jours donc c'est juste pour tester.

[sinok]

Essentiellement l'intérêt est relativement limité pour moi.
En effet en compilant en natif tu perds tout ce qui fait l'attraît de java en soit, et de ce fait, autant faire une appli en langage natif, tu profiteras de beaucoup plus de possibilités vu qu'ils sont prévus pour, ainsi que de compilateurs amplement plus puissants et optimisés.
De plus ces compilateurs ne produisent pas forcément un code plus rapide qu'une exécution sous JVM du fait de leur manque d'optimisations et de développements.
DOnc pour java il est préférable de distribuer un bundle qui comprend jre et appli pour un OS, celà me semble plus logique. De plus sous les OS non windows les JRE sont très souvent fournis de base ou du moins très aisément installables (Apple fournit directement un JRE 1.5, sous linux, java se trouve systématiquement dans les repositories et dans les installations de base des distros, sous unix, bah c'est unix et je doute que le pékin ait les moyens de se payer une license, à part opensolaris, mais même là on reste dans un domaine pro).

POur le bundle Windows tu as plusieurs solutions, soit de baser sur une solution type JSmooth qui permet de créer un exe (non natif, le code derrière reste du java) et de le linker à une JVM définie par un chemin (relatif bien sur). Sinon tu peux gérer ça via un installer classique type NSIS.

Mais bon il faut garder en mémoire qu'en général un JRE sera déjà installé sur le poste, par contre pas forcément la bonne version. Grosso merdo tu as à peu près 90% des postes existants (connectés au net) qui ont une version de java installée.

[Spidy]

POur le bundle Windows tu as plusieurs solutions, soit de baser sur une solution type JSmooth qui permet de créer un exe (non natif, le code derrière reste du java) et de le linker à une JVM définie par un chemin (relatif bien sur). Sinon tu peux gérer ça via un installer classique type NSIS.

je pourrais avoir des liens qui expliquent comment faire, ça m'intéresse ^^

Mais bon il faut garder en mémoire qu'en général un JRE sera déjà installé sur le poste, par contre pas forcément la bonne version. Grosso merdo tu as à peu près 90% des postes existants (connectés au net) qui ont une version de java installée.

tu vas rire mais je croyais qu'il fallait aussi le JDK et tout le merdier pour simplement executer le programme, donc en fait il faut juste le JRE installé c'est bien ça??

pour l'histoire de version, si sur la machine qui execute le programme c'est la 1.5 et que j'ai compiler mon prog avec le 1.6, il y aura problème??


merci pour tes conseils en tout cas

[adiGuba]

Salut,

tu vas rire mais je croyais qu'il fallait aussi le JDK et tout le merdier pour simplement executer le programme, donc en fait il faut juste le JRE installé c'est bien ça??

Oui le JRE contient tout ce qu'il faut pour exécuter une application Java.

Le JDK comporte un JRE + tous les outils de développements (javac, javap, javadoc, etc.).

pour l'histoire de version, si sur la machine qui execute le programme c'est la 1.5 et que j'ai compiler mon prog avec le 1.6, il y aura problème??

Oui : la compatibilité descendante n'est pas assuré. Donc un programme 1.6 ne marchera pas sur une JVM 1.5...

Par contre un programme compilé avec une version antérieur "devrait" fonctionner sur une JVM plus récente.
Je dis "devrait" car il peut y avoir des bugs ou des erreurs de conception/portabilité qui pourrait poser problème, mais ce sont généralement des cas bien particulier...



Une autre remarque concernant GCJ et Excelsior JET : ils produisent bien un code natif mais il n'est pas pour autant 100% indépendant !
Il faut joindre avec l'application un "runtime" (des *.dll sous Windows, *.so sous linux, etc.) qui contient le code compilé de l'API de base (bref ce qui est intégré dans le JRE).

a++