>> Surtout je ne sais pas comment GCJ gerre les dépendance au jar java ?
Ouais, ben il faut se renseigner. L'objectif de GCJ , c'est de remplacer la jvm - complètement. En conservant la compatibilité des applications compilées en bytecode.
Exemple simple: tomcat. Distribué en binaire avec Fedora Core 2, peut charger des .war compilés en bytecode et les faire touner. L'utilisateur ne voit pas de différence.
Les dépendances? Si c'est du binaire, c'est comme en C/C++/Ada avec GCC, ça dépend de s bibliothèques au moment de la compilation et du loader. Si c'est du bytecode, c'est le CLASSPATH en plus du bootclasspath (défini lors de l'installation de GCC)
De plus il y a même un petit projet qui vise à créer une arborescence similaire à un JRE classique à partir des fichiers de gcj, grâce à un système de symlinks, rendant ainsi gcj utilisable par un soft qui requiert cette arborescence pour détecter une "JVM", notamment Openoffice.org et Eclipse.
Dernièrement, avec la version de GCJ qui va sortir avec GCC 4, on pourra charger des classes compilées en natif pendant que le programme tourne, comme avec dlopen(), et le dictionnaire de ces classes sera dispo pour introspection, comme avec des classes bytecode.
[^] # Re: Quelques questions d'avenir...
Posté par k. stephane . En réponse à la dépêche Solaris officiellement annoncé sous licence Open Source. Évalué à 4.
Ouais, ben il faut se renseigner. L'objectif de GCJ , c'est de remplacer la jvm - complètement. En conservant la compatibilité des applications compilées en bytecode.
Exemple simple: tomcat. Distribué en binaire avec Fedora Core 2, peut charger des .war compilés en bytecode et les faire touner. L'utilisateur ne voit pas de différence.
Les dépendances? Si c'est du binaire, c'est comme en C/C++/Ada avec GCC, ça dépend de s bibliothèques au moment de la compilation et du loader. Si c'est du bytecode, c'est le CLASSPATH en plus du bootclasspath (défini lors de l'installation de GCC)
De plus il y a même un petit projet qui vise à créer une arborescence similaire à un JRE classique à partir des fichiers de gcj, grâce à un système de symlinks, rendant ainsi gcj utilisable par un soft qui requiert cette arborescence pour détecter une "JVM", notamment Openoffice.org et Eclipse.
Dernièrement, avec la version de GCJ qui va sortir avec GCC 4, on pourra charger des classes compilées en natif pendant que le programme tourne, comme avec dlopen(), et le dictionnaire de ces classes sera dispo pour introspection, comme avec des classes bytecode.
GCJ, ça ROXOR! Merci RedHat
Stephane