GCJ compile le bytecode en .o sur pas mal d'architectures.
Le problème de GCJ, c'est les bibliothèques, pas la compilation, ça c'est au point.
Tu peux même compiler directement un .jar: gcj -shared my.jar -o lib-my.so, et la JRE de GCJ peut même charger ton .jar compilé au runtime avec Class.forName(), il y a une convention à respecter pour le nom de la lib et il faut que la lib soit dans le $LD_LIBRARY_PATH
Donc oui, théoriquement, tu peux prendre un programme Java Bytecode et le compiler en natif pour une plateforme supportée par GCJ et pour laquelle il n'y a pas de JVM proprio dispo, comme Linux PPC par exemple... Mais il faut que ce programme soit "pur" Java (pas de code natif JNI) et n'utilise que ce qui est supporté par Classpath. Tu peux alors avoir Tomcat sur Linux PPC, par exemple.
Attention cependant: GCJ ne supporte pas toutes les architectures de la même façon et en supporte moins que GCC.
[^] # Re: 2 question bete a propos du java
Posté par k. stephane . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 2.
Le problème de GCJ, c'est les bibliothèques, pas la compilation, ça c'est au point.
Tu peux même compiler directement un .jar: gcj -shared my.jar -o lib-my.so, et la JRE de GCJ peut même charger ton .jar compilé au runtime avec Class.forName(), il y a une convention à respecter pour le nom de la lib et il faut que la lib soit dans le $LD_LIBRARY_PATH
Donc oui, théoriquement, tu peux prendre un programme Java Bytecode et le compiler en natif pour une plateforme supportée par GCJ et pour laquelle il n'y a pas de JVM proprio dispo, comme Linux PPC par exemple... Mais il faut que ce programme soit "pur" Java (pas de code natif JNI) et n'utilise que ce qui est supporté par Classpath. Tu peux alors avoir Tomcat sur Linux PPC, par exemple.
Attention cependant: GCJ ne supporte pas toutes les architectures de la même façon et en supporte moins que GCC.