Version imprimable
Bonjour,
ne connaissant que C++, je voudrais en savoir un peu plus sur JAVA :
je sais que dans la majorité des cas il crée un code interprété (fichier jar...), mais existe t'il chez JAVA un compilateur qui crée de vrais exécutables (Windows : fichiers .exe), car se pose le problème de rapidité d'exécution avec ce type de code interprété...
Merci
Oui tu peut le faire, soit tu fais un lanceur .exe qui va lancer ton .jar et donc tu as besoin de la JVM, sinon, tu emploies un compilateur natif comme gcj (il n'est pas tout à fait complet) ou JET (mais pas bon marché).
Mais sache que tu ne gagneras pas en vitesse en faisant cela.
et aussi que tu perds la portabilité apportée par Java ;)Citation:
Envoyé par wichtounet
et en plus ton exe sera beaucoup (beaucoup) plus gros que si c'était un .jar -> ce topic
tiens ! 8O ,je suis étonné que l'on ne gagne pas en vitesse entre de l'interprété et du vrai compilé comme visual C++,VB etc !!!
Mais ne connaissant pas, je m'incline. C'est dommage qu'il n'existe pas plus de compilateurs créant du pur exécutable car le language à l'air bien comme C# à priori, sauf que l'on est pas lié à Bill.
Java n'est pas un langage interprété mais compilé !!!!Citation:
Envoyé par lucky
Contrairement aux langages interprété (comme Javascript, PHP ou les shellscript), les analyses lexicales, syntaxiques et sémantiques sont bien effectués à la compilation par javac, et génère du code objet (le bytecode).
La seule différence avec une compilation classic est que le code généré a besoin d'un JVM, qui s'occupera de l'édition de lien et de l'optimisation du code (en fonction de la machine cible ET de l'état de l'application). Le bytecode étant assez proche du langage machine ces étapes ne nuissent pas les performances de l'application.
Généralement les problèmes de performances des applications Java viennent plutôt de bugs ou d'erreurs de programmation (comme pour tous les langages).
Ben cela existe (voir le lien ci dessus avec GCJ ou encore Excelsior JET), mais cela apporte peut d'intérêt (a mon avis tout du moins)...Citation:
Envoyé par lucky
a++
Il existe tout de même de nombreux outils permettant de créer des exécutable à partir de ton jar, fait une petite recherche sur le forum le sujet à été abordé plusieurs fois ;).
De plus la "rumeur" qui consiste à dire que les applis java tournent moins vite que les appplis en natif, c'est totalement infondé pour les applis développées aujourd'hui compilée avec java 5.0 TIGER.
Des tests ont même été effectué avec la JVM serveur de TIGER et on démontré des applis java plus rapide que des applis natives entre 1,1 et 1,3 fois.
Le mythe de java = long vient des débuts du langage avec java 1.1 jusqu'à 1.3. Dès java 1.4 l'écart de temps d'execution s'était réduit considérablement. Aujourd'hui l'embarquement de HotSpot (qui compile en natif certaines parties du Byte code) dans la JVM participe à une execution aussi performante (parfois meilleure) que du code natif.
Bien le bonjoir...;)
c'est pas java qui est lent .. c'est swing !
C'est surtout le mauvais emploi que beaucoup de monde fait de Swing qui fait qu'il est lent ;)Citation:
Envoyé par kedare
Je plussoieCitation:
Envoyé par wichtounet
Swing recèle de nombreux "pièges" qui, s'ils ne sont pas évités, peuvent conduire à des performances catastrophiques, à l'inverse, certaines techniques permettent de les améliorer sensiblement ;).
Piège que le tutoriel de gfx sur les threads et Swing permet d'éviter pour la plupart.Citation:
Envoyé par le y@m's
Swing c'est juste long au chargement (surtout si on utilise un look&feel), mais après, c rapide... (si bien sûr on utilise correctement l'EDT)...