Discussion :

[gagou7]

Bonjour,

J'ai un problème un peu particulier et j'aurais grand besoin de votre aide. Je développe un soft RMI en java avec une partie serveur devant tourner sous JamVM (+GNU Classpath) et la partie cliente dans n'importe qu'elle autre VM.

Pour l'instant, mon code client-serveur RMI utilise les classes Java officielles et fonctionne nickel lorsque les deux parties sont dans la jvm Java officielle. Seulement, il existe un problème avec le serveur lorsqu'il tourne sur JamVM... Apparemment le problème est connu bien que ignoré !

Tout ce que je sais, c'est que mon appli est développé avec les classes officielles de Java et que, si j'ai bien compris, JamVM utilise GNU Classpath et donc une implémentation non-officielle qui peut ne pas être compatible avec les classes officielles Java.

Ma question est la suivante: Si je remplace toutes mes classes Java (exemple java.rmi.Remote) par leur équivalent libre (gnu.java.rmi.Remote?), est-ce que ça résoudrait mon problème?

Et du coup, comment je fais pour utiliser le GNU Classpath? Etant sous debian, j'avais tout virer ce qui est IcedTea, OpenJDK, gcj car j'avais que des problèmes...

Je vous remercie d'avance pour votre aide :-)

[tchize_]

Jamais utilisé jamVM mais je vais quand même essayer de t'aider.

En RMI t'es très dépendant de la structure des objets, nottament de certains objets interne, donc je ne suis pas spécialement étonné du manque de compatibilité. Je pense effectivement qu'utiliser les même classe pour le transport RMI de chaque coté devrait beaucoup t'aider, mais seul un test te donnera la réponse.

Au delà de ça, il faut peut-être envisager de se passer de RMI et de plutot fournir un service de type webservice, Corba (bon courage) ou protocole personnalisé directement sur des socket. Au moins, avec le webservice, corba ou une protocole perso, tu aura tout le controle sur le comportement des applications.

[gagou7]

Merci pour ta réponse.

J'ai fait pas mal de recherche et voici ce que j'ai pu remarquer:

- Sur mon ARM embarqué, je peux pas utilisé le jdk officielle.
- JamVM, dans sa dernière version, est très performante et compatible OpenJDK et GNU Classpath.
- GNU Classpath semble manquer de pas mal de truc d'après la liste de compatibilité disponible sur leur site et mon problème de RMI apparaît avec lui.
- OpenJDK est agréé par Sun et semble très stable.

J'aurais besoin d'une petite explication sur la différence entre OpenJDK, GNU Classpath et les librairies officielles. Je ne comprend pas où ce situe la différence.

- Peut-on, sans modifier notre .java, l'exécuter avec des JVM différentes (chacune utilisant une des librairies ci-dessus)?
- Le bytecode du .class peut-il être lu dans n'importe qu'elle JVM?
- Si l'on prend trois VM lié à trois librairies différentes, vont-elles générer le même bytecode?

Au niveau de la cross-compilation pour ARM, GNU Classpath se compile sans problème. Par contre, pour OpenJDK, il y a apparemment des problèmes et je ne comprend pas pourquoi. J'aimerais compiler les librairies d'OpenJDK uniquement (oui parce que le nom OpenJDK comprend la JVM, les lib, etc) car j'ai réussi a compiler JamVM pour les librairies OpenJDK, mais je les ait pas...

Merci d'avance pour vos réponses. J'avoue que je suis un peu perdu après avoir fais de nombreuses recherches. Un nom qui revient souvent est celui de IcedTea qui est, si j'ai bien compris, une suite de logiciel libre pour créer OpenJDK sans le JDK officielle??? Bref, si une âme charitable veuille bien prendre le temps de m'expliquer, j'en serais très heureux

[hwoarang]

- Peut-on, sans modifier notre .java, l'exécuter avec des JVM différentes (chacune utilisant une des librairies ci-dessus)?

Un .java ne s'execute pas, c'est une source. C'est comme dire "est ce que je peux executer mon fichier .cpp ou .txt ?"

- Le bytecode du .class peut-il être lu dans n'importe qu'elle JVM?

Théoriquement oui. C'est d'ailleurs le principe original de java. Avoir un executable (.jar/.class) qui peut s'executer sur n'importe quelle JVM. A charge pour cette derniere de se debrouiller pour interpreter sur la machine cible.

- Si l'on prend trois VM lié à trois librairies différentes, vont-elles générer le même bytecode?

J'imagine que tu parles de bytecode java. Dans ce cas, une JVM ne genere pas de bytecode java. C'est le compilateur qui le genere. La JVM ne fait qu'interpreter le bytecode java sur la machine cible. Par contre, elle le compile à la volée en bytecode machine (concretement, c'est lui qui est executé par la machine). Et dans ce cas, le bytecode depend de la JVM, des librairies qu'elle utilise, de la machine cible, ...

Pour le reste, je n'ai jamais essayé, désolé

[tchize_]

Je précise aussi

gnu classpath n'est pas une jvm mais un librairies
jamvm, par son design n'est pas une jvm

java garanti que l'exécution est possible sur n'importe quel JVM *pour autant* que cette dernière respecte la spec java. Ce qui est le cas, à ma connaissance de openjdk 7, des jvm officielles d'oracle, de jrockit et autres jvm de ibm.

Ce n'est ni le cas de jamvm, ni de apache harmony, ni de l'implémentation gnu pur jus.