Discussion :

[L. Sierra]

Salut à tous,

Je sais que le fait de commander un exécutable est un sujet qui revient souvent ici

Mais moi j'aurais besoin de communiquer des informations entre l'exécutable et la partie Java (qui serait essentiellement l'interface graphique alors que l'exéc serait du code de calcul scientifique en C++).

Je suppose qu'il n'existe pas de meilleur moyen que d'écrire un fichier sur le HD qui sera alors lu par le code Java. J'imagine qu'il n'est pas possible de lancer un thread qui partage de la mémoire avec un code exécutable, histoire d'éviter les lenteurs des IO sur le HD.

Merci de confirmer/infirmer mes doutes !

[L. Sierra]

Entre-temps, j'ai trouvé la doc

http://ydisanto.developpez.com/tutor...e/runtime/#LIV

qui explique qu'on peut communiquer avec des flux avec les exec.

la méthode destroy() qui permet de tuer le processus de l'application externe,
la méthode exitValue() qui permet de récupérer la valeur de retour du processus de l'application externe,
la méthode getErrorStream() qui permet de récupérer le flux d'erreur du processus de l'application externe,
la méthode getInputStream() qui permet de récupérer le flux de sortie du processus de l'application externe,
la méthode getOutputStream() qui permet de récupérer le flux d'entrée du processus de l'application externe,
la méthode waitFor() qui met le thread courant en attente que le processus de l'application externe se termine.

Le problème, c'est que je ne vois pas bien comment Java saurait "quel" stream récupérer. Genre, dans mon code en C++, je pourais avoir plein de ostream en même temps, je ne vois pas bien comment Java ferait pour savoir lequel me renvoyer avec getOutputStream()

Voilà voilà, dsl mais je débute en threads...

[Sanguko]

Tu peux lire ceci

"Le" iostream de ton processus C++, récupéré en java, c'est la sortie standard.

[L. Sierra]

c'est la sortie standard

... Tu veux dire cin >> et cout << ??

[Sanguko]

... Tu veux dire cin >> et cout << ??

Oui

C'est ce qui est marqué dans la javadoc

The created subprocess does not have its own terminal or console. All its standard io (i.e. stdin, stdout, stderr) operations will be redirected to the parent process through three streams (getOutputStream(), getInputStream(), getErrorStream()).

[deltree]

Sinon, il y a aussi:
- Corba: un peu lourd à implémenter, mais permet l'apple d'objet à distance, avec passage de paramètres
- le JNI: pour appeler directement le code C++ en Java snas passer par programme.

Si Corba est trop compliqué à mettre en place, tu peut simplement ouvrir une Socket entre le Java et le C++ et établir ton propre protocole de communication.

[L. Sierra]

Ok, et j'imagine qu'on peut transmettre des données binaires ainsi ? Histoire d'éviter des erreurs d'arrondi pour transférer des données numériques...

[sinok]

Sinon tu as toujours la solution socket (et sérialisation pour les données binaires).

[deltree]

Oui, tu transmet tous les types de données primitifs, donc du double par exemple, ou du long, mais pas du unsigned long, qui n'existe pas en Java.
avec Corba, tu peux aussi éventuellement transmettre tes propres types d'objets qui sont sérializés/ désérializés à parrtir de ces types de base, mais c'est peut-être mieux de se limiter aux types de bases et aux String dans un permier temps.
En Socket, la réprésentation binaire des doubles ou des long doit-être la même entre C et Java.

[bulbo]

Oui, tu transmet tous les types de données primitifs, donc du double par exemple, ou du long, mais pas du unsigned long, qui n'existe pas en Java.
avec Corba, tu peux aussi éventuellement transmettre tes propres types d'objets qui sont sérializés/ désérializés à parrtir de ces types de base, mais c'est peut-être mieux de se limiter aux types de bases et aux String dans un permier temps.
En Socket, la réprésentation binaire des doubles ou des long doit-être la même entre C et Java.

Attention, attention..

Java assure que les donnees soient toujours envoyes de la meme facon quelle que soit la plateforme mais pas le C ou le C++.

En C l'envoi d'un long sur une socket donnera un ordre des bytes differents suivant la plateforme (Station Sun et PC par exemple) une recherche sur le little et le big endian t'en apprendra plus : http://fr.wikipedia.org/wiki/Endianness

Voila pour la precision,

Bulbo

[L. Sierra]

Java assure que les donnees soient toujours envoyes de la meme facon quelle que soit la plateforme mais pas le C ou le C++.

Donc si je veux une portabilité maximale, je fais mieux d'utiliser le cin et cout standard, et n'envoyer que des double, int, bool et string.

Pour moi ça va déja comme ça