Discussion :

[mouhab]

bonjour a tous,
j'ai cree un programme et j'ai cree son jar executable et tous ,et souhaite transformer ce jar executable a fichier executable .exe.donc le moindre aide sera le bienvenus.

[Népomucène]

à tout hasard :

http://devwizard.free.fr/html/fr/JavaExe.html
Il s'agit d'un faux exe qui ne sert que de lanceur. Il faut tout de même une jvm d'installée. Cela peut servir à rassurer un client

Faire passer une application java en "vrai" exe est quelque chose de très controversé
qui dégénère aussitôt en troll dès qu'on en parle.

Si on veut le faire avec une application qui aura une durée de vie de plusieurs années, alors on s'expose à des problèmes sans fin :
- un convertisseur de code java en exe est souvent très coûteux
- le convertisseur peut ne pas prendre toutes les fonctionnalités de java
- perte de bénéfice de l'évolution des versions de java (sauf à acheter les nouvelles versions du convertisseur)
- problème de portabilité sur Linux
- je suis sûr que j'en oublie

Rester dans le périmètre de java est tout de même plus confortable.

[bouye]

Dans le meme style Launch4j marche tres bien aussi : http://launch4j.sourceforge.net/

[hwoarang]

Toujours dans le meme style, il y a JSmooth... Cela dit, si quelqu'un sait comment generer un vrai exe qui n'a pas besoin d'une jvm, je suis aussi preneur...

a+

[tchize_]

java est concu pour fonctionner dans un JVM, tu aura toujours besoin d'un JVM, qu'elle soit embarquée avec l'exe ou téléchargée à part. Si tu l'embarque dans l'exe, le problème c'est que le plus petit programme java que tu ferai occuperai quand même plus de 60M!

[adiGuba]

Salut,

Cela dit, si quelqu'un sait comment generer un vrai exe qui n'a pas besoin d'une jvm, je suis aussi preneur...

Tu as GCJ (mais qui reste incomplet si je ne me trompe pas) ou Excelsior JET (mais qui reste assez onéreux).

De toute manière dans ces cas là, la JVM est généralement remplacée par une librairie native...

a++

[hwoarang]

java est concu pour fonctionner dans un JVM, tu aura toujours besoin d'un JVM, qu'elle soit embarquée avec l'exe ou téléchargée à part. Si tu l'embarque dans l'exe, le problème c'est que le plus petit programme java que tu ferai occuperai quand même plus de 60M!

Bah on pourrait imaginer un outil qui n'embarque que ce qui est necessaire... Meme si je me rends bien compte de la complexité de l'outil en question :-)

Tu as GCJ (mais qui reste incomplet si je ne me trompe pas) ou Excelsior JET (mais qui reste assez onéreux).

De toute manière dans ces cas là, la JVM est généralement remplacée par une librairie native...

Oui, j'avais lu quelque chose sur GCJ mais je me suis arreté aux commentaires disant, comme toi, que ce n'est pas très complet (et de mémoire, je crois que c'est le support de swing qui peche donc c'est assez important - meme si c'est à confirmer)
Quand à Excelsior JET, si c'est onereux, je n'en ai pas l'utilité. C'etait juste une question que je me posais en passant :-)

[tchize_]

Bah on pourrait imaginer un outil qui n'embarque que ce qui est necessaire... Meme si je me rends bien compte de la complexité de l'outil en question :-)

Il y a bien les JVM "allégée" que sun/oracle a commencer à développer (principalement dans le but de servir à javafx) où une jvm minimale est isntallée et celle -ci télécharge au fur et à mesure les classes dont le programme à besoin. Mais que je sache, ce n'est pas encore le cas (et ça nécessitera que ton utilisateur dispose d'un connection internet).

Maintenant, je vois pas trop l'utilité de convertir un jar en exe, une fois la jvm installé, un jar se comporte comme un exe, tu peux double cliquer dessus :/

[hwoarang]

Maintenant, je vois pas trop l'utilité de convertir un jar en exe, une fois la jvm installé, un jar se comporte comme un exe, tu peux double cliquer dessus :/

Bah j'en vois quelques unes :
- Pas de necessité d'avoir une jvm (je sais qu'on va me dire que la plupart des gens l'ont deja installée mais pas tout le monde)
- Pas de necessité de mettre à jour la jvm (par exemple sur un PC avec java 1.4 et un programme developpé en 1.6)
- Decompilation beaucoup plus compliquée (pour les programmes commerciaux par exemple)
- Pas de probleme du à l'utilisation de machines virtuelles de versions différentes (sur ce point, j'ai jamais eu de probleme mais par principe...)

[adiGuba]

• Tu n'installes pas la JVM, mais un "runtime" propre à l'outil utilisé pour compiler (GCJ ou Excelsior JET). Bref tu remplaces l'installation de la JVM par l'installation de bibliothèques.
• Idem pour les mises à jours...
• Il existe des outils pour se protéger de la décompilation. Je n'ai pas vraiment d'expérience dans le domaine mais la décompilation n'est pas propre à Java, même si c'est vrai que cela doit être facilité du fait de l'introspection (qui implique que les classes contiennent beaucoup d'informations).
• La compilation native revient à implémenter une machines virtuelles. Donc en quelques sorte Excelsior JET est une JVM. D'ailleurs il a passé le Java Compatibility Kit...

a++

[tchize_]

- Decompilation beaucoup plus compliquée (pour les programmes commerciaux par exemple)

Et l'histoire informatique montre que l'efficacité de ce genre de produit dans ce but approche de 0 selon mon opinion. Quelqu'un qui a décidé de craker les protection de ton outil, et qui a les compétences requise, y arrivera. Tu ne fera que le ralentir un petit peu mais
-> si ton programme vise un marché de niche, il n'intéressera en général pas les cracker professionnel, et tes clients paieront
-> si ton programme vise un gros marché avec pleins de clients, aucun outil ne te permettra de résister à la masses des crackers, par contre les boites qui les vendent seront bien enclines à te vendre des licences .


Et comme di adiguba: des outils d'obfuscation, ça existe, faut juste payer

[hwoarang]

• Tu n'installes pas la JVM, mais un "runtime" propre à l'outil utilisé pour compiler (GCJ ou Excelsior JET). Bref tu remplaces l'installation de la JVM par l'installation de bibliothèques.

Dans ce cas, c'est qu'on n'obtient pas un exe classique. D'ailleurs, je ne connais pas d'outil qui permet de transformer un .jar en .exe qui fonctionne directement et sans jvm ou équivalent. Ce que je trouverais interessant, c'est d'obtenir un .exe completement indépendant.

• Il existe des outils pour se protéger de la décompilation. Je n'ai pas vraiment d'expérience dans le domaine mais la décompilation n'est pas propre à Java, même si c'est vrai que cela doit être facilité du fait de l'introspection (qui implique que les classes contiennent beaucoup d'informations).

Oui mais avec java, on peut carrement recuperer le code source...

• La compilation native revient à implémenter une machines virtuelles. Donc en quelques sorte Excelsior JET est une JVM. D'ailleurs il a passé le Java Compatibility Kit...

Dans ce cas, ce n'est pas une compilation native. Par définition, si c'etait une compilation native, l'executable devrait etre independant. Je sais qu'on joue sur les mots mais j'ai deja dit ce que serait l'objectif d'un compilateur java<->natif pour moi.

Et l'histoire informatique montre que l'efficacité de ce genre de produit dans ce but approche de 0 selon mon opinion. Quelqu'un qui a décidé de craker les protection de ton outil, et qui a les compétences requise, y arrivera. Tu ne fera que le ralentir un petit peu mais
-> si ton programme vise un marché de niche, il n'intéressera en général pas les cracker professionnel, et tes clients paieront
-> si ton programme vise un gros marché avec pleins de clients, aucun outil ne te permettra de résister à la masses des crackers, par contre les boites qui les vendent seront bien enclines à te vendre des licences .


Et comme di adiguba: des outils d'obfuscation, ça existe, faut juste payer

Je n'en ai pas besoin, je donnais juste des arguments qui justifient à mes yeux l'interet d'un outil de compilation java<->natif. Meme si je suis globalement d'accord. Quoique dire "si un bon hacker veut cracker mon programme, il y arrivera donc autant ne pas le protéger" revient pour moi à dire "si un bon voleur veut entrer chez moi il y arrivera donc autant laisser mes clés visibles sur la porte". C'est sur qu'un hacker chevronné arrivera à casser n'importe quelle protection mais le but, c'est de se protéger des moins bons... M'enfin bon, une fois encore, ce n'est qu'un argument, je n'ai pas besoin de protéger quoi que ce soit.

a+

[adiGuba]

Ce que je trouverais interessant, c'est d'obtenir un .exe completement indépendant.

Indépendant de quoi ?
Tu connais beaucoup d'exécutable un tant soit peu complexe qui soient réellement indépendant ?

Oui mais avec java, on peut carrement recuperer le code source...

Comme je l'ai dit je n'ai pas de connaissance là dessus... mais il me semble que c'est a peu près la même chose dans plusieurs langages (avec un code plus ou moins utile dans tous les cas).

Dans ce cas, ce n'est pas une compilation native. Par définition, si c'etait une compilation native, l'executable devrait etre independant.

Non au contraire, en compilant nativement l'exécutable est encore plus dépendant car lié à un OS précis, à une certaine architecture matérielle et à des bibliothèque précises...

Au contraire un programme Java pur est bien plus indépendant car il ne requiert que la présence d'une JVM..

C'est sur qu'un hacker chevronné arrivera à casser n'importe quelle protection mais le but, c'est de se protéger des moins bons...

Dans ce cas il y a l'obfuscation


a++

[tchize_]

Oui mais avec java, on peut carrement recuperer le code source...

On récupère "un" code source. Bien entendu, si tu as activé les option des débuggage (ce que fait tout bon ide), toutes les informations (noms des méthodes privés, noms des champs privés, nom des variables locales) sont préservés, ce qui facilite grandement le travail de décompilateur, mais ce problème n'est pas propre à java. Décompile un code sans informations de debuggage, tu verra la différence (t'aura des a et des b et des c partout dans les noms de variables).

Dans ce cas, ce n'est pas une compilation native. Par définition, si c'etait une compilation native, l'executable devrait etre independant.

Tu aura toujours besoin de librairies, Celle-ci devront au minimum se charger des éléments suivants:
-> fournir toute l'API java SE
-> fournir toute la gestion des classloader et de la mémoire
Une compilation native veux simplement dire que le code obtenu est du code machine pour la plateforme visée, et non plus du bytecode java. Donc plus d'interprétation à la volée ou de hotspot nécessaire. Tout le reste est toujours nécessaire.

C'est comme celui qui programme en Delphi, pour que son programme fonctionne, l'utilisateur devrai installer les librairies redistribuables Delphi, même chose certaines librairies de visual studio, etc...

"si un bon voleur veut entrer chez moi il y arrivera donc autant laisser mes clés visibles sur la porte".

La comparaison serait plutot "y a des voleurs, je vais donc installer une porte blindée avec serrure codée, plutot qu'une bête porte en PVC avec serrure à barillet de Mr tout le monde. Laisser les clés ce serait comme mettre le code source sur ton site web. Celui qui commence à décompiler (code obfusqué ou pas), il a déjà décidé de rentrer et il rentrera Enfin, si ça peu te rassurer, utilise un obfusceur de code.

[JuFromParis]

Donc en fait, il n'existe aucun petit logiciel de conversion permettant de créer un .exe non extractible ?

On peut constamment récupérer les codes d'une appli java?

[thelvin]

Avec la remarque qu'on peut constamment récupérer les codes d'absolument tout. Le principe est finalement le même qu'une page HTML : si tu veux qu'elle s'affiche sur l'ordinateur de ton visiteur, tu dois la fournir en clair, point. Un .jar est juste un peu moins clair qu'une page HTML, et un .exe est juste un peu moins clair qu'un .jar.

Le fait est que Java est un langage se basant sur de nombreux standards simples, et donc même les plus grands novices peuvent extraire un .jar avec leur dézippeur préféré, alors que les formats PE ou ELF sont effroyablement compliqués vu qu'il faut installer des outils d'inspection qui ne sont pas déjà là.

Le fait est aussi que Java est un langage très rigoureux, encourageant à la propreté à tous les niveaux, et très encapsulé, ce qui fait des codes désassemblés faciles à décompiler avec les bons outils, chose plus difficile avec du code machine d'un processeur qui existe vraiment, dans des langages dont l'assembleur produit touche à tout à la fois.

Je suis sûr qu'il existe des outils qui permettent de brouiller tout ça pour ressembler un peu plus au grand n'importe quoi d'un vrai .exe, ce qui complique, il est vrai, la tâche de décompilation (mais pas de trouver une clé secrète par exemple.)
Mais ces outils ont souvent de nombreux bugs et autres incompatibilités, sont souvent payants, et au bout d'un moment pourquoi se tourner vers Java si on tient absolument à s'éloigner de tous ses principes ? Je suppose que pas grand-monde ne le fait.
En tout cas quelles qu'en soient les raisons, il est manifeste que ces outils sont mal connus.

[JuFromParis]

Bon ok, on peut toujours récuperer les codes sources..

Mais en fait ce que je recherche, c'est un logiciel qui crée un .exe à partir du jar mais que ce .exe ne soit pas extractible par winrar ou autre, histoire de ne pas tenter un utilisateur curieux.

J'ai testé plusieurs logiciels et à chaque fois, clic droit sur le .exe et l'option de winrar (extraire ici) apparait!!

Ce matin, j'ai testé Launch4J et la, surprise, pas de "extraire ici"!
Sauf quand j'ajoute une icone au .exe, bizarre non!!

Alors quelqu'un aurait-il une solution pour ca?? Ou un autre logiciel à proposer (payant ou gratuit)?

Merci.