Java プロジェクト内で既存の C# ソースを使用したいと考えています。これまでのところ、Java Native Interface (JNI) などを使用するのは非常に簡単なので、これは大きな問題にはなりません。問題は、ソフトウェアが Windows 以外の OS でも実行されることです。そのため、C# ソースを Mono でコンパイルして、Linux などで実行可能にすることができます。しかし、Java 内での統合はどうでしょうか? JNI または C# <-> Java 相互運用性のための COM ベースのソリューションは OS に依存し、Windows などでのみ機能します。
考えられる解決策の 1 つは、Web サービスの実装です。この問題を解決する方法の別のアイデアはありますか? 代替の提案に非常に感謝します！
どうもありがとう！
よろしく
これはおそらく「答え」そのものではなく、同様の（私が思うに）状況をどのように見たかについてのもう少しの議論です。
私は C#/.Net ベースのクライアント/サーバー スタイル システムに多額の投資をしました。そのため、Android の「クライアント」アプリもサポートしたいと決めたとき、さまざまなオプションを検討しました。私にとって最も重要な要素は、C# クラスを、既存のシステムとこれから作成する Java Android アプリとの間のオブジェクト交換の定義クラスとして維持することでした。
私が最終的に落ち着いて、好みに合わせて微調整したのは、Google Protocol Buffers が交換メディアであるシステムでした。(それらに慣れていない場合は、一種の JSON のような交換形式です。) https://developers.google.com/protocol-buffers/
.Net の最後では、Marc Gravell によって書かれた ProtoBuf-Net を使用します (彼は SO で働いていると思います)。これには、.Net オブジェクトを取得して、プロトコル バッファの定義ファイルである .proto ファイルを生成する機能が含まれています。 https://code.google.com/p/protobuf-net/
Android 側では、David Yu によって書かれた ProtoStuff を使用しています。彼のコードには、.proto ファイルを取り、対応する Java クラスを生成する部分があります。 https://code.google.com/p/protostuff/
私が遭遇した問題の 1 つは、派生クラスである .Net クラス (ほとんどのクラス) でこれがうまく機能しないことでした。ここの回答へのコメントで説明されている回避策を作成しました: protobuf-net を取得して、.Net で継承されたクラスをフラット化および非フラット化する方法は?
これは今、私の満足に働いています。
Android アプリが Windows ベースのシステムにどのように接続し、どのように通信が行われるかについては、まったく説明していないことに注意してください。それは私にとって二次的なものでした。私の主な考慮事項は、C# クラス定義を決定的な定義にし、それらから Java クラスを自動的に作成し、次にオブジェクト間の交換を行うことでした。(私は自作の TCP/IP 通信リンクを使用していますが、実際の通信は何でもかまいません。おそらく Web サービスも同様です。)
お役に立てれば。
そこで、私はこのトピックについて多くの調査を行ったので、その結果を皆さんと共有したいと思います。
1 つのオプション (技術的な観点から非常に魅力的) は、Java と .Net の間の商用ブリッジを使用することです。確かに、最も人気のある製品はJNBridgeとJavanet です。. どちらの製品も非常に使いやすく、サポートも充実しており、非常に洗練されているようです。特に、JNBridge はすでに Java と Mono 間のブリッジもサポートしているため、上記の主な要件の 1 つである非 Windows OS への移植も可能です。Javaonet も Mono を統合したいと考えており、この機能を間もなくリリースする予定です。ただし、どちらのソリューションも商用であり、それぞれの機能とそれぞれのコストを比較検討する必要があります。それでも、純粋に技術的な観点から見ると、それらは見栄えがよく、Java と .Net 間の非常に高速な通信 (Web サービスよりも高速) を可能にすると述べています。
もう 1 つのオプションは、Java と .NET を COM 経由で接続することです。COM は一般にプラットフォームに依存しないように定義されているため、これは複数の OS で動作する可能性があります。EZJCOM、J-Interop、JACOB、JCOM など、このような実装に使用できるオープン ソース プロジェクトは多数あります。主な制限 (特に私たちのプロジェクトの場合) は、Mono が (まだ) Windows での COM 相互運用性のみをサポートすることです。したがって、これは私たちにとって実際には選択肢ではありません。しかし、Windows のみで Java と .NET の相互運用性を実現したい場合は、これが良い方法です。
Java と C# を統合する簡単な方法は、Java Native Interface (JNI) を使用することです。また、JNI をより使いやすくするさまざまな実装を見つけることもできます。最も人気のある実装は、おそらくjni4netであり、非常にアクティブで頻繁に使用されるプロジェクトのようです。しかし、カフェイン、エスプレッソ、csjni など、特定の長所と短所があるものもあります。最後に、JNI は 100% プラットフォームに依存しません。さまざまなプラットフォームに適用できますが、プラットフォーム固有のコードを生成する必要があるため、この目的には明らかに使いにくくなります。アプリケーションを Windows に制限する場合は、jni4net が非常に適しているようです。
3 番目のオプションは、共通言語ランタイム内で Java と .Net の両方の部分を実行することです。そのため、 Ikvm.netは 1 つの可能性があり、非常に人気のあるソリューションです (上記の Samuel Audet による説明)。このオプションの欠点は、JDK の機能と効率が失われることです。
最後で確実に最も一般的な代替手段は、Java と .Net の世界の間に Web サービスをセットアップすることです。このソリューションでは、オブジェクトを Java および .Net との間でシリアライズ/デシリアライズするための適切な方法を見つける必要があります。利用可能なそのための多様な可能な解決策があります。RenniePet は、Protocol Buffers に基づく洗練されたソリューションについて言及しました。http://java-cs-bridge.sourceforge.net/など、他にも存在します。このオプションには、通信の実行時間を考慮すると潜在的な欠点があるかもしれませんが、私たちにとっては良い方法かもしれません。
これが、将来同じ問題に直面する人に役立つことを願っています。