J'ai vu que recement, Sun avais (enfin) mis les sources de la jre a disposition :
C'est possible de telecharger les sources sur la page, a cote de la ou l'on telecharge la JRE.
Donc, a partir de la, il devrais etre possible de compiler la JVM pour d'autres plateformes sous linux. Ca serais bien utile sur les architectures ARM, pour les Ipaq par exemple, ou les solutions Java existantes sont plutot en version 1.2 (A ma connaissance, il n'y a pas de JRE 1.4 ou 1.5 existante en libre). Ca empeche d'utiliser JINI entre autre....
C'est clair que il y a du boulot, mais maintenant on ne peux plus accuser Sun d'obscurantisme.
Une autre question, c'est a propos du bytecode :
Ca n'est rien de plus qu'un code assembleur pour un processeur virtuel, non ?
Dans ce cas, pourquoi ne peut-on pas creer un outil bytecode -> asm x86,PPC,ARM,etc....
Je parle ici d'un convertisseur de fichier, qui en sortie donnerais un fichier .o qu'il serais possible de lier comme tout autre programme, sasn doute via un petit bootstrap qui contiendrais un main().
L'assembleur, bien que ca soit tres lourd a ecrire a la main, c'est relativement simple et "automatique" comme language, non ?
J'imaginerais meme comme ca pouvoir transformer un programme compile pour PPC en version x86, ARM, ou nimporte quoi d'autre....
C'est sur, il n'y a pas le meme nombre de registres, l'espace memoire est pas fait pareil, etc.... Et je pense bien que le resultat ne serais pas optimal.
Mais ca pourrais marcher, non ?
# 2 question bete a propos du java
Posté par C. OB (site web personnel) . En réponse à la dépêche Accord entre la FSF et les développeurs OpenOffice au sujet de l'utilisation de Java. Évalué à 1.
C'est possible de telecharger les sources sur la page, a cote de la ou l'on telecharge la JRE.
Donc, a partir de la, il devrais etre possible de compiler la JVM pour d'autres plateformes sous linux. Ca serais bien utile sur les architectures ARM, pour les Ipaq par exemple, ou les solutions Java existantes sont plutot en version 1.2 (A ma connaissance, il n'y a pas de JRE 1.4 ou 1.5 existante en libre). Ca empeche d'utiliser JINI entre autre....
C'est clair que il y a du boulot, mais maintenant on ne peux plus accuser Sun d'obscurantisme.
Une autre question, c'est a propos du bytecode :
Ca n'est rien de plus qu'un code assembleur pour un processeur virtuel, non ?
Dans ce cas, pourquoi ne peut-on pas creer un outil bytecode -> asm x86,PPC,ARM,etc....
Je parle ici d'un convertisseur de fichier, qui en sortie donnerais un fichier .o qu'il serais possible de lier comme tout autre programme, sasn doute via un petit bootstrap qui contiendrais un main().
L'assembleur, bien que ca soit tres lourd a ecrire a la main, c'est relativement simple et "automatique" comme language, non ?
J'imaginerais meme comme ca pouvoir transformer un programme compile pour PPC en version x86, ARM, ou nimporte quoi d'autre....
C'est sur, il n'y a pas le meme nombre de registres, l'espace memoire est pas fait pareil, etc.... Et je pense bien que le resultat ne serais pas optimal.
Mais ca pourrais marcher, non ?