次の観点から、それぞれの長所と短所についてコメントしていただけますか。
- パフォーマンス（ベンチマーク？）
- Java の機能のカバレッジ
- クロスプラットフォームの互換性
質問する
1075 次
1 に答える
1
私は rjb を使用していませんが、概念的には、私が使用した Python-Java ブリッジである JPype に似ているようです。どちらも、JVM ランタイムを共有オブジェクトまたは DLL として、実行中の Python または Ruby インタープリターにロードしているように見えます。
私の経験では、このアプローチは機能しなくなるまで問題なく機能し、機能しなくなると壊滅的に失敗する傾向があります。私が JPype で遭遇した問題は、Java ランタイムと Python ランタイムが動作環境に関して行った異なる仮定に関連していました。懸念される分野は次のとおりです。
- ガベージ コレクション モデル。JVM のガベージ コレクション モデルは、Python や Ruby のものとは異なります。注意しないと、(理論上はとにかく) 問題が発生する可能性があります。
- スレッド。数年前に JPype を使用していたとき、これは私にとって本当の問題でした。JVM のスレッド モデルは Python のスレッド モデルと衝突し、奇妙な実行時エラーが発生しました。
私はそのアプローチで十分な悪い経験をしてきたので、私はそれを警戒しています。
ただし、rjbは JPype ではなく、Ruby は Python ではありません。Ruby のスレッド モデルは、Python のスレッド モデルよりも JVM とうまく共存できる可能性があります。また、私はこのようなテクノロジーを 2 年以上使っていないので、状況が変わっている可能性があります。
結論: うまくいくかもしれませんが、注意してください。
あなたの特定の問題に関して：
パフォーマンス
ここで推測を危険にさらすつもりはありません.どちらのアプローチのパフォーマンス特性も、あなたが何をしているかに大きく依存し、どちらのテクノロジーの使用目的を概説していないからです.
クロスプラットフォーム
純粋な Java (JRuby など) はすべて、Java VM があればどこでも問題なく移植できます。これは、 rjbソリューションには必ずしも当てはまりません。たとえば、互換性のない共有ライブラリの問題が発生する可能性があります。プラットフォーム上でrjbをビルドする必要があり、最初に他の多くのものをビルドする必要があることに気付くかもしれません。等。
一方、JRuby で遭遇する問題は、多くの gem が利用できないことです。Java の世界では、JNI (つまり、C または C++ コードへの橋渡し) は一般的に嫌われています。「最良の」コードは 100% Java です。Ruby の世界 (さらに言えば Python の世界) では、C API への橋渡しが一般的です。大量の gem がそれを行います (たとえば、データベース ドライバー、既存のオープン ソース C API を活用するいくつかの gem、本当に優れたパフォーマンスを必要とするいくつかの gem)。C-Ruby と C の間のブリッジは、Java と C の間のブリッジとはまったく異なります。C コードでリンクする C-Ruby 用に作成された Gem は、そのままでは JRuby では機能しません。そのため、C-Ruby から JRuby へのコードの移植には問題が生じる可能性があります。
Java の機能のカバレッジ
rjbは JVM を Ruby インタープリターにロードするため、JVM がサポートするものはすべてサポートできるはずですが、少なくともドキュメントによると、Ruby と Java の間のインターフェースは扱いにくくなる可能性があります。JRuby は実際には完全に Java で実装されているため、JRuby と Java の間のインターフェースは少し簡潔になる傾向があります。
于 2012-02-10T03:27:23.830 に答える