Discussion :

[Claude URBAN]

Bonjour,

Comme le dit " sinok " dans l'une de ses dernières interventions sur le sujet :
" Bon ça revient dans tous les sens, on devrait définitivement le marquer en haut du forum........"
Ba ça, c'est ben vrai… ( pour ceux qui ont connu la mère Denis… )
Et pour ceux qui surf, je peux vous confirmer que c'est une question très récurrente, sur tous les forums, aussi bien Français qu'Anglais et autres.
Ce qui tant à prouver, si besoin est, que c'est le souhait de beaucoup de programmeurs Java que de vouloir écrire en Java et de compiler en Natif. ( rapidité d'exécution et possibilité de se passer de la JRE )
Compte tenu des nombreuses questions et demandes trouvées sur les différents Forums d'informatique, il semblerait que ce soit à ce jour, plus qu'un véritable besoin.

Par contre je ne suis pas d'accord avec sa dernière phrase :
" - Compiler en natif mais là tu perds tout l'attrait de java."
L'intérêt de ce langage ne réside pas uniquement dans le fait qu'il soit multi-plate-forme, mais aussi que ce soit un langage moderne et récent, avec une collection de bibliothèques importante, plus facile à manipuler que le C++, avec les avantages du C++ sans ses inconvénients, bien sur Open-Source, POO, etc.… et bien d'autres avantages encore que je ne développerais pas ici.
Et il ne me semble pas, que cela soit une aberration que de vouloir programmer en Java et de compiler en natif…
Beaucoup programment en Java pour le plaisir et non avec des impératifs professionnels, pour eux ou les copains, sous Windows ou autre et par conséquent, non aucunement besoin du coté multi-plate-forme de Java.
Je suis personnellement persuadé, qu'un jour l'on pourra compiler en natif aussi facilement qu'avec le C ou le C++ par exemple… Il n'y a qu'à voir la demande.

( Mais je ne veux pas lancer un débat , qui a déjà eu lieu, je m'exprime.. tout simplement. )

Pour revenir au problème du " *.exe ", étant moi-même à la recherche de la possibilité de faire des exécutables natifs avec du Java, ( pour mon plaisir et satisfaire ma curiosité ) je n'ai à ce jour trouvé aucune réponse positive à ma question. Mais je ne désespère pas de trouver un jour la solution et je continu à fouiller, sachant que beaucoup de personnes travaillent actuellement sur le sujet.
Ma recherche étant principalement axée sur du " gratos ".

La méthode GCJ semblerait ne pas être encore parfaitement au point, à cause des problèmes rencontrés avec les bibliothèques graphiques AWT & SWING.
( Actuellement on peut compiler en natif avec GCJ, s'il n'y a pas de Graphique. )
Voir sur le site: http://gcc.gnu.org/java/
Il existerait une possibilité avec la bibliothèque SWT ( proposée par ECLIPSE ).
Voir à ce sujet sur http://pisee.sourceforge.net/ le projet intitulé " pisee " qui aurait fait un éditeur de texte en java compilé en natif avec la Bibliothèque SWT et MinGW 5.0.2!
Personnellement j'ai essayé avec un petit prog, et je n'y suis pas arrivé… mais ça ne prouve rien.

Pour répondre à " theniaky ", de ce que j'ai pu voir sur le net, JToExe n'existerait plus.
Par contre, une société dont le siège scientifique est en Russie, commercialise par l'intermédiaire d'une société américaine… ( Wouaps! Dallas ??? ) un compilateur Java/natif connu sous le nom de Excelsior JET 4.1 au prix de $250 à $500 suivant la plate-forme utilisée…. . Quant à l'édition professionnelle de $900 à $2400…
Et oui, il faut vraiment avoir les moyens ( Ils sont fous ces américains… )
IMPRESSIONNANT, n'est-il pas…oui il est…
Par contre, de ce que j'ai pu lire à droite et à gauche " JET 4.1 ", serait un produit très performant… Voir à ce sujet : ) http://www.excelsior-usa.com/home.html
Personnellement, je ne l'ai pas essayé.

A quand la rubrique,… j'ai testé pour vous?… ( en souvenir de : Merci Bernard.. ou Palace, je ne me souviens plus ?? )

En conclusion, et à ce jour pour faire ( absolument et impérativement ) un exécutable " *.exe " avec Java:

Soit-tu dépenses entre 250 et 500 dollars. ( JET 4.1 )

Soit-tu utilises un launchers comme par exemple launch4j ( Que l'on trouve sur ce site et qui fonctionne fort bien. Simple et efficace. Mais il te faudra garder la JRE. )

Soit-tu fais un Jar Exécutable. ( Mais là aussi, il te faudra garder la JRE. )

Soit…….

... de langage tu changeras ...

Amicalement votre.

@ ++

Claude


PS: Si, complément d'information il y a, preneur je suis.

[FreshVic]

Salut,
Juste pour précisé que NAtif n'est pas forcement sinonyme de plus de rapidité :

en voici la preuve

D'autant plus interessant que l'on a une petite comparaison entre GCJ et JET mais surtout parce qu'on s'appercoit que le natif est finalement moins rapide parce que l'on perd les optimisation faite par la JVM.

[Claude URBAN]

Bonsoir,

Merci pour ton lien avec " la preuve… " qui m'a permis d'approfondir ma réflexion.
Je ne suis pas un pro en la matière et je ne souhaite pas rentrer dans une " querelle d'amoureux ". ( en tout bien tout honneur. )
Mais qu'un langage natif c'est à dire " direct machine ", soit moins rapide qu'un langage traduit même " juste à temps " ( JIT ), me laisse perplexe.
Le juste à temps, implique obligatoirement un intermédiaire qui va traduire même extrêmement rapidement un langage de haut niveau, ( par exemple Java ).
Par définition cet intermédiaire va occuper de l'espace et du temps par rapport à un langage compilé directement à la source ( natif ).

C'est comme un individu qui parle correctement une langue étrangère. Il n'y a pas de décalage ( temps perdu ) entre le mot prononcé et celui entendu. C'est la même langue.
Sinon il faut un interprète, un intermédiaire, qui, quoi qu'il fasse, intercalera un temps entre la parole prononcée et celle entendue par l'étranger.
Par contre si l'individu en question, parle mal la langue étrangère ( mauvaise compilation ) effectivement à ce moment là une traduction même lente, sera bien plus efficace qu'une mauvaise maîtrise de la langue étrangère.

Java (Byte-Code) --> JVM (JIT - Langage machine ) --> CPU.

Java (Natif) --> CPU… Pas d'intermédiaire…

Mais de part et d'autre il faut effectivement du bon Code. ( Byte-code ou natif.)

Mais pour revenir à " ta preuve ", je pense que la comparaison de rapidité d'exécution, ne doit pas se faire entre Java avec JVM et Java Natif ( qui n'existe pas encore correctement ), mais entre Java actuelle ( c'est à dire du Byte-Code + JVM ) et C++ compilé…

Un bon gros programme complet écrit en Java, le même écrit en C++, on compile ( le C++ ) et on compare.

Alors que la JVM actuelle soit plus performante que la compilation native actuelle de Java, oui, c'est fortement possible, puisque cette dernière n'existe pas encore.

Il reste donc à peaufiner une compilation native pour java, digne de ce nom... et refaire des tests, si nécessaire.

Amicalement et @ ++

Claude

[adiGuba]

Salut,

Mais qu'un langage natif c'est à dire " direct machine ", soit moins rapide qu'un langage traduit même " juste à temps " ( JIT ), me laisse perplexe.

Et pourtant... c'est possible (mais pas forcément obligatoire ni très important). Mais en général on obtient des temps très proche (le seul point noir étant le chargement de la JVM, point qui s'est relativement améliorer ces dernière années).


Le bytecode Java est proche du code natif, et comme il est déja compilé, il n'y a pas d'analyse lexicale/grammaticale à effectuer (contrairement à des langages de scripts). C'est nettement plus rapide qu'une compilation standard. De plus cette compilation peut prendre en compte toutes les spécificités du système (type de processeur, etc.).

Mais pour revenir à " ta preuve ", je pense que la comparaison de rapidité d'exécution, ne doit pas se faire entre Java avec JVM et Java Natif ( qui n'existe pas encore correctement ), mais entre Java actuelle ( c'est à dire du Byte-Code + JVM ) et C++ compilé…

Un bon gros programme complet écrit en Java, le même écrit en C++, on compile ( le C++ ) et on compare.

C'est peut-être facile à dire mais pas à faire. Si les deux langages sont bien des langages objects, ils utilisent des mécanismes relativements différents qui favorisent l'un ou l'autre selon les cas...
De plus cela neccessite d'avoir une bonne connaissance général des deux langages...

Alors que la JVM actuelle soit plus performante que la compilation native actuelle de Java, oui, c'est fortement possible, puisque cette dernière n'existe pas encore.

????
La compilation native de Java existe, tu le dis toi même dans ton premier post... et pour les performances tu le dit toi même :

Par contre, de ce que j'ai pu lire à droite et à gauche " JET 4.1 ", serait un produit très performant…

Sur les quelques tests que j'ai fait j'obtient des résultats proche de la JVM (plus ou moins rapide selon qu'on utilise la JVM client ou server).

Il reste donc à peaufiner une compilation native pour java, digne de ce nom...

Personnellement, je préfèrerais voir arriver les MVM (Multi-Tasking Virtual Machine), qui permettront d'utiliser une seule et unique JVM pour toutes les applications Java (au lieu d'une JVM par appli comme maintenant).

a++

[yesilay]

Moi aussi, j'ai eu besoin de créer une executable et j'ai effectué des recherches sur net.
finalement, j'ai décidé de créer une éxecutable avec dotnet 1.1 (je pense que il doit être installé sur tous les xP)
j'ai téléchargé sharpDevelop(gratuit)
en langage c#
j'ai mis juste ces codes suivant

public static void Main(string[] args)
{
System.Diagnostics.Process proc = new System.Diagnostics.Process();
// Nom de l'executable à lancer
proc.StartInfo.FileName = "javaw.exe";
proc.StartInfo.Arguments = " -jar nomdeJarAExecuter.jar";
proc.Start();
proc.Close();
}

SharpDevelopp vous permet de définir l'icon aussi( avec visual c++.net expresse, il est impossible).
Une fois que vous créez l'executable mettez le dans le dosssier de votre jar.
c assez performant.
Si quelq'un trouve un code pour lancer un Process avec MFC sans passer par dotnet, j'aimerais bien l'avoir aussi.

[adiGuba]

Si quelq'un trouve un code pour lancer un Process avec MFC sans passer par dotnet, j'aimerais bien l'avoir aussi.

Il y a plusieurs exemples dans la section "deployer" des outils : http://java.developpez.com/outils/developpeur/#deployer

Sinon j'avais fais cela il y a quelques temps (en C pour Windows seulement) : http://adiguba.free.fr/download/JarLaunch.zip (Source : http://adiguba.free.fr/download/JarLauncher-src.zip ).

Il faut renommer l'exécutable du même nom que l'archive JAR...
Pour changer l'icone il faut le recompiler (j'avais utiliser mingw pour cela).

a++

[Claude URBAN]

Salut,

Les liens que tu donnes renvoient sur des " lanceurs " ( de vrais faux éxecutables *.exe ) et non sur des " compilateurs ".

Pesonnellement et pour le moment, en attendant mieux, j'utilise launchj4 qui reste simple d'utilisation, facile et efficace.

Java Natif:
Bien que le sujet soit redondant, il n'en demeure pas moins toujours d'actualité et pour le moment......encore entier.

@++

Claude

[adiGuba]

Les liens que tu donnes renvoient sur des " lanceurs " ( de vrais faux éxecutables *.exe ) et non sur des " compilateurs ".

Je n'ai jamais dit le contraire : je répondais à la question de yesilay concernant son lanceur .Net...

Java Natif:
Bien que le sujet soit redondant, il n'en demeure pas moins toujours d'actualité et pour le moment......encore entier.

Tu as déjà cité les deux principaux compilateurs Java->natif : GCJ et JET.

Maintenant, il n'y a rien d'étonnant à ce qu'il n'y ait pas plus de compilateur natif pour Java : cela va à l'encontre de la philosophie de Java...

a++

PS : [HS] tu devrais éviter de mettre ton adresse email en signature... sinon tu as de grande chance de te retrouver avec plein de spam...

[seiryujay]

Si je peux me permettre (et j'espère ne pas faire de hors sujet), je cherchais comment pouvoir créer un ".exe" (et ne pas avoir à utiliser un ".bat" ou un ".jar") pour lancer mon appli, afin qu'un utilisateur "non-expérimenté" s'y retrouve.

Et j'ai trouve un petit exe : JavaExe.exe.
Il suffit de le renommer avec le nom du jar qu'on veut lancer, et d'éditer un fichier de config, et hop! Le tour est joué.
Il est possible de changer l'icône de l'exe...


Voilà, en espérant ne pas être tombé HS (j'ai un peu eu la flemme de lire le post en entier... )