Discussion :

[balistick]

Bonjour,

L'objectif des langages managés, et de java en particulier, est de permettre une grande portabilité de l'application grâce à l'utilisation de bytecode, compilé à la volée par une machine virtuelle. Lorsqu'une JVM est installée sur un système, celui ne va plus changé. Pourquoi dans ces conditions ne compile t-on pas l'ensemble des librairies java une bonne fois pour toute en code natif sur le système ? Pourquoi ne fait-on pas pareil avec l'installation d'un programme java, c'est à dire qu'on compile l'ensemble du code en code natif au moment de l'installation sur un système donné ?

Merci pour vos réponses,

PS : si ce message se trouve dans la mauvaise catégorie merci de le déplacer.

[supersnail]

Bonjour,
effectivement ta question est intéressante,mais:

Le langage java est conçu pour justement être portable,et donc on doit pouvoir transférer un programme java d'un ordinateur à un autre sans problème de compatibilité.

Or,qui dit compilation dit dépendant de l'O.S,et ce n'est pas le but de java...

De toute façon,les APIs java reposent sur du code natif pour l'affichage,etc...

[T`lash]

Si je ne m'abuse, la JVM compile automatiquement une partie du bytecode lors de la première exécution pour que les suivantes soient plus rapides.

[tchize_]

tu t'abuse Compilation uniquement en mémoire vive.

La compilation JIT est complexe. Tout ton code java n'est pas compilé en natif. La jvm garde une trace des bouts de codes les plus réutilisés de ton programme, et au dela d'un certaine limite d'utilisation, estime qu'il est rentable de convertir cette méthode ou bout de code en code natif. On ne le fait pas sur fichier parce que ca n'a jamais été jugé utile. Les parties sur lequelles il y a gain notable sont déjà compilées à la volée. De plus ce code natif est visiblement très dépendant de l'état de la jvm, d'une exécution à l'autre il pourrait etre différent.
Enfin, mettre un fichier natif serait spécifique à l'OS (on pourrait toujours argumenter qu'il ne changera pas, mais ce n'est pas vrai dans tous les cas!) mais aussi spécifique à la version de la jvm utilisée -> bonjour les dégat si tu change de jvm sans réinstaller ton programme.

[T`lash]

Donc, je m'abuse, ou alors j'ai abusé...

N'empêche que Java est souvent considéré à tord comme un langage menant à des applications très lentes à l'exécution. D'accord, en tant que langage semi-compilé il est plus lent que du code natif, mais c'est négligeable par rapport aux nombreuses erreurs de conception des IHMs.
Si on jongle bien avec les Threads et qu'on n'utilise pas des méthodes synchronisées lorsque c'est totalement inutile le gain en perfs est impressionnant.

[tchize_]

tout a fait d'accord, la perte de perfs du à l'interprété deviens minime, par rapport au gain en temps de développement et debuggage par rapport à des language comme le C++. La plus grosse différence de perfs viens de ce que les gens comparent des choses non comparable, comme les méthode object C++ qui sont plsu rapide car finale par défaut alors que les méthode java sont surchargeables par défaut. Et personellement, c'est plus propre et rapide de programmer dans le deuxième cas