Discussion :

[WebPac]

Bonjour,

je dois développer en C# et les assemblies réalisées doivent être utilisables en Java. Hors je ne connais pas bien Java et je dois faire un projet Java qui réutilisera une assembly .Net fort simple, mais je ne sais pas encore comment m'y prendre.
Et pour corser le tout, il faut aussi que ça ne fonctionne pas que sous Windows mais aussi sous linux. J'ai bien trouvé des tutos qui parlent de JNI et JNI4NET mais le premier passe par du code en C++ natif et le second n'est pas encore porté sous mono.

Merci pour vos conseils.

[sinok]

Si les données à faire transiter ne sont pas trop volumineuse, des Web Services pourraient t'offrir une solution relativement propre.

[WebPac]

Utiliser un WebService ne veut pas dire qu'on doit installer un serveur web sur la machine ?
N'est-ce pas un peu lourd alors que le but n'est pas de faire communiquer les 2 applis sur 2 postes différents mais en local sur le même poste ?

[sinok]

Pas forcément besoin d'un servlet container. Il suffit juste d'avoir une socket à disposition. Donc les web services marchent bien en dehors d'un contexte web.

Cf: http://java.sun.com/developer/techni...J2SE/jax_ws_2/

Cela peut sembler un peu lourd, toutefois ce sera amplement plus simple à maintenir que N couches de code natif utilisant des API plus ou moins stables.

[WebPac]

Ton article est un peu (beaucoup) compliqué pour quelqu'un qui ne s'y connait pas bien en Java.
Mais si je ne m'abuse, il ne faut pas faire les WebServices en Java mais en .Net et l'appli Java utiliserait ces WebServices.
Il faudrait donc que je trouve comment faire fonctionner des WebServices en .Net sur un serveur linux sans avoir à installer un serveur web ?
Bien que je sois d'accord que d'avoir une couche native intermédiaire entre une couche managée et la couche Java soit assez usine à gaz et source d'incompatibilités, ta solution est aussi assez complexe à mettre en oeuvre.

Je la garde sous le coude si besoin mais j'aimerais vraiment pouvoir trouver une solution où le déploiement entre autre serait plus simple.

J'ai entendu dire que JNI permettait d'utiliser du code natif soit windows, soit linux, soit mac sans avoir besoin de faire 3 versions du code.

[merill]

Une solution simple:
Le java exécute ton programme .net (en fait la machine virtuelle via exec) et utilise les pipes d'entrée-sortie standard pour dialoguer.

[WebPac]

Je ne m'y connais pas super bien, mais en faisant ainsi, on travaille bas niveau et du coup, ce n'est que du procédural, on na pas de typage fort de la POO, ni vérification des types à la compilation.

Je suis en train de faire des tests en utilisant JNI, j'arrive à utiliser du code C++ compilé sous linux, il faut encore que je trouve comment mapper l'assembly .Net avec le code natif C++.

[WebPac]

Bonjour,

finalement la solution d'utiliser JNI sur linux n'aboutit pas. J'ai un problème sur le projet C++ natif intermédiaire, je n'arrive pas ré-utiliser une assembly .NET, on dirait que ce n'est pas encore implémenté dans mono/monodevelop.

Finalement, je me suis intéressé à la solution WebServices, mais je me demande si cela peut répondre au besoin car j'ai l'impression que les WebServices ne permettent que de faire du procédure avec des types primitifs comme string, int, ... et ne permet pas de faire de la POO, ce qui serait fort limitant.

[sinok]

Les webservices peuvent parfaitement correspondre à des données complexes sans le moindre problème.

En effet tu peux utiliser tes propres Objets qui seront mappés en tant qu'éléments XML.

Genre un truc dans le style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
public class Maclasse {
   private int toto;
   private String machin;
   private BigDecimal duTexte;
 
 
   public int getToto() {
       return toto;
   }
 
   public void setToto(int toto) {
       this.toto = toto;
   }
 
   //et ainsi de suite pour les autres accesseurs get/set machin et duTexte
}

Avec une classe englobante du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
public class MaClasseEnglobante {
   private MaClasse maClasse;
   private String autreChaine;
 
   public MaClasse getMaClasse() {
      return maClasse;
   }
 
   //et ainsi de suite pour les autres accesseurs get/set maClasse  et autreChaine
 
}

Sera mappée en xml sous la forme:

Code xml :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
<MaClasseEnglobante>
   <MaClasse>
      <toto>0</toto>
      <machin>truc</machin>
      <duTexte>azertyuiop</duTexte>
   </MaClasse>
   <autreChaine>poiuytreza</autreChaine>
</MaClasseEnglobante>

Ce qui correspond bien aux notions d'objets. Tu peux également mapper des collections ou tout autres choses de cette façon.

[WebPac]

Mais cela implique que celui qui consomme le WebService sera obligé de redéclarer toutes les classes pour qu'il puisse lui aussi faire de la POO ?

Je n'arrive pas à voir comment côté client, on peut récupérer un objet et les propriétés d'un objet, il devra forcément désérialiser l'objet depuis le noeud XML ? Comment pourra-t-il appeler la méthode d'un de ces objets ?

[sinok]

Les WebServices sont bien basés sur les concepts de sérialisation/désérialisation.
Ensuite il te faut te renseigner sur le concept de descripteur de web services (le fichier wsdl) qui permet à des outils du framework utilisé de générer dynamiquement les classes correspondant à la sérialisation/désérialisation que tu pourras utiliser dans tes devs.

[tchize_]

pour être clair, le client java ne va faire que consommer ou il va appeler des méthodes, interagir avec ces objets. Si oui, je "craint" que les seuls protocoles standard entre tes deux soient au choix:
un webservice bien concu, avec du SOAP
un export CORBA de ton objet .net, avec des descripteurs .IDL pour les récupérer dans d'autre language (comme java).


Dans tout les cas, c'est un gros boulot.

[WebPac]

En fait j'ai besoin de trouver une solution afin qu'un programmeur Java puisse réutiliser ce que je réalise en .NET et le tout sous windows et sous linux.

Sous windows, j'ai trouvé la solution avec JNI, ce n'est pas (trop) lourd et fonctionne pas mal.
Malheureusement, je n'ai pas réussi à le faire fonctionner sous linux et cherche une solution de contournement donc pas forcément WebServices et ce que tu me dis ne me rends guère optimiste.

[sinok]

Bah sinon quel est ton problème avec JNI sous linux?

[WebPac]

Mon problème n'est pas côté Java. Avec NetBeans, j'ai réussi à utiliser une classe faite en C++, mon problème est plutôt d'arriver à faire une application en C++ qui va réutiliser un assembly .NET.
Le projet de test trouvé dans le tuto possède :

• un projet Java qui fonctionne avec netbeans windows et linux.
• un projet C# qui génère l'assembly fait avec VisualStudio pour Windows mais tourne bien avec MonoDevelop sous linux.
• le projet intermédiaire en C++ fait avec VisualStudio mais pas accepté par MonoDevelop.

J'ai trouvé ceci sur le site de mono :

Once this stage is done, there are two extra stages that are fairly complex:
Add Managed C++ support to the C++ front-end (this is required if you want to share objects between .NET and C++)

Et donc à priori, ce n'est pas possible pour le moment.

Par exemple, j'ai ce bout de code en C++ :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
using namespace System;
using namespace System::Runtime::InteropServices;
using namespace HelloWorldDotNet;
 
#include <string>
 
std::wstring assemblyPath;
 
System::Reflection::Assembly ^ MyResolveEventHandler( Object^ sender, ResolveEventArgs^ args )

J'ai une erreur sur using namespace System; car 'System' n'est pas un namespace-name et donc je ne peux pas avoir de type Assembly, ce qui est assez bloquant.

[sinok]

Là il n'est pas grand chose que les gens du forum java puisse faire pour toi .

Essaie de voir dans le forum .net s'ils n'auraient pas une solution sous la main.

Mais bon après une recherche rapide, dans la FAQ de mono, il existe tout de même des solutions à priori:

I have a C++ library that I would like to call from Mono, what can I do?
There are a few possible approaches:

• Use a code generator such as SWIG that parses the C++ code and generates C wrapper functions and C# code which DllImports the C wrappers.

Pro: This permits use of C++ code from C# Con: Not terribly elegant; Extra layer of C code may impact performance.

• There was work on a WHIRL-to-IL compiler, which would compile C (and probably C++) into CIL which Mono could execute.

Long term solutions that require a lot of work might be possible:

• Modify GCC's to produce CIL.

[tchize_]

j'ai surtout l'impression que vous êtes occupé de vous orienter vers une solution qui va être une belle s*** a maintenir. Il serait plus sage, je pense, de faire comme suggérer plus haut: invoquer l'application .net depuis java et utiliser les input/output stream pour dialoguer.

[WebPac]

Mais bon après une recherche rapide, dans la FAQ de mono, il existe tout de même des solutions à priori:
I have a C++ library that I would like to call from Mono, what can I do?

En fait, c'est l'inverse, j'ai une bibliothèque faite en C# que je voudrais pouvoir accéder en C++.
Mais je vais toujours demander sur le forum .NET pour voir s'ils ont une solution, j'avais juste écrit ce code car tu me demandais pourquoi je bloquais.

j'ai surtout l'impression que vous êtes occupé de vous orienter vers une solution qui va être une belle s*** a maintenir. Il serait plus sage, je pense, de faire comme suggérer plus haut: invoquer l'application .net depuis java et utiliser les input/output stream pour dialoguer.

Je suis désolé mais je ne vois pas du tout pourquoi ce serait plus simple, il faudrait que j'implémente une sorte de serveur qui pourrait communiquer par exemple en TCP/IP avec une application cliente et devrais gérer l'ensemble des possiblités d'accès aux objets, propriétés et méthodes, sans parler que côté client, ils n'auraient pas de POO car en TCP/IP, ce n'est que du string.
Vraiment, je n'ai pas l'impression que ce soit plus adapté à mon besoin, mais peut-être que je me trompe.

[tchize_]

ce n'est pas "facile". En voulant absolument faire interagier une application .net avec une application mono, vous n'avez clairement pas choisi la voie facile. La voie facile et raisonnable aurait, a mon avis, été de tout faire en .net ou tout en java. Déjà, vouloir utiliser du .net en multiplateforme, vous êtes fortement dépendant de l'implémentation mono, qui n'est pas complète de toutes façons.

L'utilisation de compilation native, de librairie native .NET + de librairie natives java + de C entre les deux, vous êtes bien conscient qu'à chaque mise à jour de mono, à chaque mise à jour de la JVM, vous serez probablement bon pour devoir recompiler? Vous allez vous retrouver avec un quirielle de .dll / .so pour vos clients, avec une installation qui sera loin d'être facile. Sans compter que vous allez vous retrouver dans une même espace mémoire avec deux machine virtuelles, deux garbage collector, etc. Et, de toutes façons, ne vous leurrez pas. Vos objet vous devrez les coder, au final, 2 ou 3 fois. Vous allez devoir coder une structure qui récupère en C les donnée .NET + une classe native en JAVA qui va utiliser ces structure pour exposer un objet java. Donc pour tout objet .NET que vous désirerez exposer à java, il y aura une classe java correspondante et un code C correspondant. Trois fois le travail. Je ne vois pas en quoi c'est plus facile que d'avoir en .NET une classe qui dialogue sur les inpout/outputstream standard, et d'utiliser ce canal poru dialoguer avec l'application java (qui aura de toutes facon son objet propre de son coté). Au mois, là, vous n'avez aucune compilation native, un simplification de l'interaction, et quelque chose de standard (ca fait des année qu'on fait dialoguer des applications sur cette base). Et non, vous n'avez pas besoin de TCP/IP là dessus.

[WebPac]

Salut, mon but n'est pas de faire une application hybride a moitié faite en .NET et à moitié en Java, je dois réaliser des applis en .NET mais valider qu'on peut diffuser une sorte de "SDK" qui soit réutilisable par des partenaires qui utilisent d'autres langages dont le Java, c'est pour ça que j'essaie de valider cette partie là.
Ce n'est pas qqch qui sera systématiquement fait, mais il faut que ce soit possible et que j'apporte la solution pour que ça marche.

tchize_ pour que je comprenne mieux ce que tu veux dire, tu aurais un lien vers un tuto qui présenterait ta solution ?