Compiler du code java en code natifFermé

Question

Bonjour à tous,

J'aurais besoin de compiler du code java en code natif et je ne parviens pas à utiliser GCJ (la doc n'est pas très claire me semble t-il).

J'aimerais donc savoir vous avez déjà effectué ce genre d'opération et surtout comment avez vous procédé ?

Je ne souhaites pas utiliser GCJ particulièrement, mais un logiciel gratuit.

Merci

Utilisateur anonyme · Answer

Bonjour

Demandez de l'aide à Twinuts ou bien prenez une version d'essai d'Excelsior.



















T.U.E.R (First Person Shooter créé par Julien Gouesse)

cs_Julien39 · Answer

Bonjour,

Merci pour ta réponse. J'ai finalement contourné le problème en demandant l'installation d'une JVM sur les postes sur lesquels je souhaitais installer le programme. Et malgré quelques réticentes, c'est maintenant fait.

a+

coucou747 · Answer

Histoire de répondre, on fait ça à prologin, 
https://bitbucket.org/delroth/stechec-2010/src/ffbf8fd5b787/stechec/scripts/files/rules.mk

C'est un peu imbitable et je ne sais pas si ça répond à la question : il me semble que ça compilait le java en .so, mais il est possible qu'on ai juste compilé le java en .class et linké une jvm pour avoir un .so qui lise les .class (mais j'en doute, on a fait ça pour beaucoup d'autres langages, comme php, javascript, perl, lua, python, .net, mais pour java, on a du faire plus sale et moins cool)

Il faut savoir que gcj ne compile pas bien le java : exemple, il transforme un nullPointerException en segmentation fault, c'est pas très pratique pour debuguer.

Utilisateur anonyme · Answer

Bonjour

Je me sens obligé de reprendre coucou747. GCJ compile relativement bien le Java, il n'en supporte pas les dernières fonctionnalités comme le projet est mort depuis environ 2 ans. Une NullPointerException est une exception de Java, ce mécanisme repose sur la machine virtuelle Java et sur son modèle mémoire. Il n'y a pas de mécanisme équivalent en C ou tout du moins il serait très difficile de mettre en place un mécanisme s'en rapprochant, il faudrait se servir de la pile de contexte (cf. setjmp, longjmp), contrôler de nombreux accès à des pointeurs, etc... (ou éventuellement se servir de la gestion des exceptions du C++ mais je ne suis pas certain que cela soit possible) et l'exécutable final serait beaucoup plus gros. C'est pourquoi toutes les solutions permettant de convertir du bytecode Java en code machine ne le font pas à ma connaissance, ce n'est pas une limitation de GCJ. On ne peut pas avoir le beurre et l'argent du beurre, les avantages de Java et les prétendus avantages de l'exécutable ne nécessitant pas de machine virtuelle. Je pense que de telles confusions existent dans l'esprit de développeurs qui n'ont pas compris que Java a sa propre gestion mémoire, il ne passe pas son temps à appeler malloc et free, il a son propre tas. Si on ne comprend pas ça, on ne peut pas non plus comprendre pourquoi les appels à méthodes et les allocations mémoire sont 2 à 4 fois plus rapides en Java (cf. Brian Goetz).

Je ne contredis pas coucou747 sur le fait que ce soit pénible d'avoir une segmentation fault qui ne dit rien du tout à la place d'une NullPointerException qui indique la ligne fautive. On peut limiter la casse avec un débogueur mais cela requiert d'avoir une idée du passage du code problématique pour pouvoir déboguer pas à pas.






T.U.E.R (First Person Shooter créé par Julien Gouesse)

coucou747 · Answer

Bonjour,

Je n'ai pas dit que ce choix technique était délirant, juste que ça ne te permet pas de compiler n'importe quel code java (en respectant le sens du code)

Pour prologin, GCJ était un mauvais choix, quand un candidat a un segfault, il est parfois incapable de trouver d'ou il vient, insulte les organisateurs, dit que le serveur est bugué, alors qu'en fait ça vient de son code :)

Cordialement,

Maxime

Utilisateur anonyme · Answer

coucou747, je dis simplement que ce n'est pas une limitation propre à GCJ et que vous auriez eu exactement le même problème avec d'autres solutions. Rien ne sert donc de pointer du doigt GCJ en particulier. Une telle limitation ne signifie pas que GCJ ne compile pas bien le code Java, cela signifie simplement que si on veut la sécurité d'une JVM, on se sert d'une JVM.




T.U.E.R (First Person Shooter créé par Julien Gouesse)

coucou747 · Answer

On est d'accord.

cs_GodConan · Answer

Salut ;o) 

En fait ;o) pour faire cours, il vaut mieux ne pas essayer de faire compiler du code interprété ;o) ... D'ou l'importance de l'etude préliminaire à tout projet ;o) ... Un language interprétéa ses avantages ET ses inconvéniants ;o) ...

GodConan ;o)

Utilisateur anonyme · Answer

Java est un langage précompilé interprété, ce n'est ni un langage purement interprété (sauf si vous désactivez le précompilateur JIT ou si vous n'en disposez pas sur une plateforme donnée) ni un langage compilé (mais une partie du bytecode est transformée en code machine à la volée). Je rejoins GodConan sur l'importance de l'étude préliminaire à tout projet. Par contre, les avantages et les inconvénients d'un langage ne dépendent pas seulement de la possibilité d'utiliser un compilateur ou un interpréteur, cela dépend plutôt de leurs implémentations respectives.





T.U.E.R (First Person Shooter créé par Julien Gouesse)

coucou747 · Answer

Techniquement, java est compilé, et c'est le bytecode java qui est interprété.
Les definitions de "compilation" sont claires la dessus, c'est dans les premiers chapitres du dragonbook.
Je ne pense pas que les gens étudient chaque implémentation de lisp (compilée ou non) pour rejeter ce langage pour de gros projets.

Il faut regarder un langage avec son écosystème : implémentations, éditeurs, plateformes, librairies, outils divers, le fait de pouvoir recruter des gens qui le connaissent, le fait que ce langage facilite la vie du developpeur avec une syntaxe claire, concise, pas trop verbeuse, avec des messages d'erreurs sympatiques et très stricts, etc...

Pratiquement tout les langages s'interfacent avec le C, donc quand on veut de meilleurs perfs qu'avec son langage, on fait un ptit algo en C, mais c'est plus la vitesse qui importe (la preuve, on fait du .net et du java sur des téléphones maintenant)

Malheureusement, la mode n'est pas aux messages d'erreurs stricts, on préfère actuellement développer des langages plus simples à apprendre, pour avoir plus de devs, et ça donne des programmes de moins bonne qualité, des bugs plus difficiles à trouver, et aussi des optimisations plus chiantes à faire.

Utilisateur anonyme · Answer

javac est un précompilateur, il traduit le code source en bytecode Java. Ce bytecode passe ensuite dans le compilateur JIT qui va véritablement compiler une partie du bytecode en code machine et le reste est interprété par la machine virtuelle à l'exécution. Je maintiens donc que Java n'est pas un langage compilé au sens strict du terme, il fait un peu des deux.

Je rappelle que Java a battu Fortran (sauf en terme de scalabilité) dans une étude sur le calcul haute performance mené par IBM donc C n'est pas toujours le langage de choix y compris quand on veut de bonnes performances. Je rappelle également que Jake 2 tourne 15% plus vite que son équivalent en C/C++ (c'était déjà le cas dès 2004 sur des machines de l'époque). Le fait que Java soit utilisé sur les téléphones n'en fait pas un langage de second choix qu'on prend quand on se moque de la vitesse, bien au contraire.

.NET et Java n'ont pas grand chose en commun, leurs machines virtuelles respectives sont très différentes. Ils n'ont rien à voir en terme de portabilité comme Mono diffère notablement de l'implémentation Microsoft de .NET alors que l'OpenJDK et la JVM Oracle sont très proches (elles partagent même une bonne partie du code) et que cette dernière ne tourne pas que sur Microsoft Windows.

Je ne vais pas refaire ici le débat sur "Java est-il adapté aux jeux vidéo?", il a déjà eu lieu sur developpez.net et j'avais battu en brèches les plus gros préjugés sur les performances de ce langage.

Java n'utilise qu'un sous-ensemble du C dans sa machine virtuelle (il avait failli s'appeler C++--), il permet moins d'optimisations de bas niveau (pas de vrais pointeurs mais des accès directs à la mémoire depuis la classe Unsafe), il est moins flexible pour le programmeur mais plus flexible pour lui-même (l'absence de pointeurs lui permet de faire des optimisations dynamiques inconcevables en C). Si vous vous croyez plus forts que les compilateurs et les machines virtuelles, n'utilisez pas Java, codez en assembleur mais personnellement, je ne monterai pas dans votre fusée.

Je suis désolé mais je maintiens qu'une belle trace d'exception me parle beaucoup plus qu'une erreur de segmentation et que cette facilité du langage ne me donne pas envie d'écrire du code de moins bonne qualité.

La lenteur de Java est devenue un mythe à partir de Java 1.4. Nous en sommes à Java 1.7, il est peut-être temps d'arrêter de porter atteinte à tort à cette technologie.

Il y aura toujours des gens qui programment mal dans tous les langages et de toute manière, celles et ceux qui croient pouvoir apprendre à programmer en quelques jours ou quelques mois se plantent. Cela prend des années.




T.U.E.R (First Person Shooter créé par Julien Gouesse)

coucou747 · Answer

Ce que je disais ne s'applique pas forcément au java, de plus, toutes les machines virtuelles n'ont pas les perfs que tu décris (cf dalvik...)

Au risque de me répéter :

Techniquement, java est compilé, et c'est le bytecode java qui est interprété. 
Les definitions de "compilation" sont claires la dessus, c'est dans les premiers chapitres du dragonbook.

Utilisateur anonyme · Answer

Dalvik n'a rien à voir avec la JVM d'Oracle, la DVM a un modèle mémoire basé sur les registres ce qui est très différent des JVM que ce soit sur J2SE, J2ME, J2SE For Mobiles et J2SE For Embedded. Si vous voulez des performances sur des machines équipées de processeurs ARM (voire même avec Jazelle), utilisez plutôt Java For Embedded. Google a voulu faire son propre Java et les performances posent problème, certains développeurs conseillent même d'écrire "salement" pour avoir de meilleures performances, par exemple en ne faisant aucune encapsulation des données (tout est en visibilité publique) car les accesseurs en lecture sont notablement plus lents que les accès directs à des attributs publics. JRockit, Oracle JVM et l'OpenJDK ont les performances que je décris, les deux dernières sont les plus utilisées.

Au risque de me répéter, une partie du bytecode Java est interprétée, une autre partie du bytecode Java est compilé en code machine (cf. compilateur JIT) donc je maintiens que Java est à la fois précompilé et interprété, c'est expliqué dans Wikipedia :
Notons que même s&#8217;il y a explicitement une première phase de compilation, le bytecode Java est soit interprété, soit converti à la volée en code natif par un compilateur à la volée (just in time, JIT).

Le code est ensuite interprété sur une machine virtuelle Java

Dire que le bytecode Java est uniquement interprété revient à faire comme si le compilateur JIT n'existait pas, c'était le cas il y a très très longtemps, avant Java 1.2. La compilation JIT est abordée dans la seconde édition du dragon book à ma connaissance.





T.U.E.R (First Person Shooter créé par Julien Gouesse)

Utilisateur anonyme · Answer

J'allais oublier un truc important. Java est capable de faire de la recompilation dynamique en fonction des paramètres d'exécution et de sa connaissance de l'environnement (ce qui est impossible dans un langage purement compilé, il ne peut faire que de l'optimisation statique). En d'autres termes, la JVM peut compiler une partie du bytecode Java en code machine par exemple si une portion est appelée très souvent puis reprendre l'interprétation du reste du bytecode. Ainsi, en utilisant la compilation JIT et la recompilation dynamique à l'exécution, Java tire partie à la fois des optimisations statiques et des optimisations dynamiques.









T.U.E.R (First Person Shooter créé par Julien Gouesse)

coucou747 · Answer

Merci, tu ne m'apprends rien.

Bon, C'est super drole, j'insiste juste sur le mot précompilé, qui pour moi ne veut rien dire... Il semble que pour toi, compiler = produire du code machine, or c'est totalement faux.

T'es gentil, ça fait trois posts que tu décris ce que c'est qu'un JIT, ou que t'expliques comment tourne dalvik, je bossais dans la compilation avant, maintenant, je fais du jeu android, je sais tout ça...

Je t'invite donc à lire : http://en.wikipedia.org/wiki/Compiler

[i]A compiler is a computer program (or set of programs) that transforms source code written in a programming language (the source language) into another computer language (the target language, often having a binary form known as object code). The most common reason for wanting to transform source code is to create an executable program.
/i
ou à lire le dragonbook.

ils disent bien que c'est "souvent" du code binaire, sauf que c'est assez vague :
gcc te fait un .o, c'est pas du langage machine : il manque l'édition des liens
javac te fait un .class, c'est pas du langage machine
en perl, tu commences par transformer ton perl en bytecode parrot

Bref, la production n'est pas toujours un langage machine.

La page wikipedia dit que le JIT est un compilateur, mais c'est discutable, voici pourquoi :
- le JIT peut ne pas terminer (si le programme ne termine pas, le JIT tourne toujours)
- le JIT n'est pas déterministe : il va utiliser des informations qui se baladent dans la runtime, comme des valeurs de variable, donc c'est pas du tout déterministe.
- on a aucun moyen de sauvegarder le résultat du JIT pour le réexécuter.
- le JIT transforme PARFOIS le couple (langage, statistiques de runtime) en code machine, il n'est pas obligé de le faire (si il manque d'infos, si la fonction n'est pas appelée souvent, ....)
- le JIT n'est pas une fonction de type : string -> string qui transforme un langage en un autre
- parmi les passes de compilations classiques, le jit n'utilise que le backend.

On dit que c'est un compilateur parce-que ça a un backend, mais ce n'est pas vraiment classable, JIT est une technique de compilation pendant l'interpretation, je ne vois rien de moins précis qui ne soit pas faux.

Je te reprends sur une definition, tu te mets à expliquer comment le truc marche en sortant des évidences.
Je te dis que dalvik est lent, tu m'expliques pourquoi (d'une façon incomplète) mais c'était hors du débat.

Depuis le début, on est d'accord sur tout, à part sur la definition de compiler, le fait que le langage java soit compilé (hey, javac correspond totalement à la definition de wikipedia...).

Bref, t'écoutes même pas ce que je dis, t'as pas lu le dragonbook ni la page wikipedia sur les compilers, je vais clore ce topic.

Compiler du code java en code natif

15 réponses

Discussions similaires