Visual Studio向けRuby in SteelでのJRubyサポート

Ruby in Steel (サイト・英語)(Visual Studio向けRuby IDE) は、ここしばらくの間によく使用されるようになっており、高速なCylon Rubyデバッガ(source)のような機能の提供が望まれていた。また最近では、IronRuby用のRuby in Steel(source)がアルファ版としてリリースされた。


間もなく、JRubyデバッガサポートが新機能として発表される予定だ。これは、特に高速デバッグに焦点を絞っている (Ruby in SteelのJRubyサポート(サイト・英語)と混乱しないようにしてください)。 このJRubyサポートが何を含み、これがなぜ追加されたのかを理解するため、この新機能のリリースに先立ってHuw Collingbourne氏に話を聞いた。

InfoQ: Visual StudioにおけるJavaサポートはどのようになっていますか？JRubyでのクロス言語アプリケーションの開発を可能または簡単にするために何らかのサポートを追加しますか？(「クロス言語」とは、JRubyコードを使用して既存のJavaライブラリをスクリプト化することを指しています。)

 Huw Collingbourne氏: VS 2005のJavaサポートは、すばらしいと言えるほどのものではありませんでしたが、OKと言えるレベルではありました。当然ながら、Javaサポートは、VS 2005に付属のMicrosoftの「Java dialect」(J#) を介して提供されています。これは、構文の色分け表示およびIntelliSenseを可能にします。しかしVS 2008では、MicrosoftはJ#を取り除いています。これは、Javaサポートを一切得ることができなくなることを意味します。JavaコードをVS 2008に読み込んだ場合には、単なるテキストエディタで作業を行うしかありません。VS 2008にJavaを色分け表示するパッケージを組み込むのは難しいことではないでしょう。これは、私達が行おうとしていることとは異なりますが、理論的には私達でも実現可能です。デバッガのサポートとなると、もう少し困難なものとなるかもしれません。やはり、本格的なJava開発にはVisual Studioはお勧めしません。もっとすばらしいツールが他にあります。

InfoQ: クロス言語デバッグ: デバッグにおいて、RubyコードとJavaコードを混在させることができますか？つまり、Javaソースのメソッドを呼び出すRubyメソッドを中断した場合、スタックビューは、JRubyおよびJava両方のスタックトレースを表示しますか？

Huw Collingbourne氏: いいえ。デバッガはRubyのみです。

InfoQ: SapphireSteel内の開発者やあなたは、jruby-debug (トレースベースのJRubyデバッガ。高速化のためにruby-debugと同様にJavaで作成されている) などの既存のテクノロジを基本として開発しているのですか？

Huw Collingbourne氏: 私達のデバッガは、混合言語で、一から作成しています。jruby-debugに基づいているわけではありません。このJRubyデバッガの中には、Javaで作成されている部分もありますが、そうした部分は、高速化のため、JNIインターフェイスを介してCコンポーネントを呼び出します。遅い部分 (例えば、ユーザ入力の処理など) は、Rubyで作成されています。高速な部分は、Javaで作成されています。さらに高速な部分は、CおよびX86アセンブリ言語で作成されています。JRubyの標準イベント取得メソッドを使用して、JRubyに接続しています。ちなみに、JRubyの興味深い点の1つは、そのデバッグおよびトレースシステムの互換性が高いという点です。このデバッガは、標準のMatz Ruby (MRI) バージョンとまったく同じではありませんが、類似性がとても高いので、どのように処理が行われているかを簡単に理解することができます。実際には、必要なインターフェイスを取得するためにインタープリタ内部で面倒なことを行う必要がないので、MRIトレースシステムよりも簡単に使用できます。また、JRubyの内部インターフェイスは、ほとんどドキュメント化されていない状態でも、簡単にそれに従い、使用することができます。

InfoQ: 速度に関してどのようなメリットがありますか？他に比べて目立って高速な部分はありますか？

Huw Collingbourne氏：現在のところ、jruby-debugと比較して評価することはまだできません。私達のマシン上ではできないことですし、とにかくまだベータ版です (私達はそう考えています)。このため、ベンチマークを行っても公平な比較にはならないでしょう。しかし、jruby-debugは、元のC ruby-debugをJavaへそのまま移植したものであるため、私達の実装も、ruby-debugからjruby-debugの場合と同程度の高速化 (50%から100%) をjruby-debugに対して達成できると予想しています。JNIコンポーネントを使用しているので、もう少し多く高速化が可能かもしれません。私達独自のMRI Cベースデバッガ (Cylon) に対しては、比較評価することができます。しかしながら私達のJavaバージョンのデバッガは、MRI Cylonよりも約2～3倍遅いと思われます。この原因は、主に、JRubyトレース関数と、MRIのCトレース関数呼び出し速度の差です。JRuby自体は、全体的には、MRIと同じか少し速い速度で実行されるように見えますが、これは当然のこととも言えます。私達は、JRubyがMRIに勝っているのは、ネイティブスレッドの実装のすばらしさだと考えています。これは、サーバアプリケーションにとって重要なことです。

InfoQ: JRuby 1.1: このデバッガは、解釈済み、JIT済み、およびAheadOfTimeコンパイル済みのコードを処理できますか？

Huw Collingbourne氏： JRuby 1.1では何の問題も検出されていません。これは、(JNIコードを除いて) 標準Javaです。しかし、私達は、最適化に取り組んでいたときに興味深いことを発見しました。CまたはC++で効果のある最適化の仕掛け (つまり、コードを高速化するもの) にはほとんど効果がないということです。実際、場合によってはJavaでは逆効果となることがありました。私達は、これの原因はJava HotSpotオプティマイザではないかと考えています。単純さを保つために、それに処理を行わせているように思えます。

InfoQ: JRuby on Railsアプリケーションの配置を簡単にするためのツールは何か含まれますか？

Huw Collingbourne氏： 現在、Rails向けには、汎用的な統合開発ツールのセットを提供しています。例えば、コマンドプロンプトに移動することなくスクリプトを保存および実行するためのさまざまなユーティリティなどがあります。しかし、現在のところ、JRuby On Railsアプリケーションの配置専用のツールは用意していません。

InfoQ: これは、無償バージョンですか？ (私の記憶が正しければ、IronRuby用のものは無償でした。)

Huw Collingbourne氏： 現時点では、JRubyサポートは、私達の商用製品 (Ruby In Steel Developer) の中でのみ提供することを考えています。あなたのご記憶のとおり、最近、IronRuby用IDEのアルファ版を無償でリリースしました (IronRubyはまだアルファ版に達していない状態ですが)。IronRubyの完成バージョンがリリースされた後も、IronRubyのみのIDEは無償で提供を続ける予定です。現在は、JRubyのみのIDEを提供する予定はありません (正直に言えば、そのようなIDEに十分な需要があるのかわかりません)。

InfoQ: JRuby固有の機能のための編集サポートはありますか？GUIによる構築サポートの計画はありますか？

Huw Collingbourne氏： 現在のところは、Ruby開発にのみ焦点を絞っており、Javaサポートまで拡張する予定はありません。前に述べたように、すばらしいJava IDEは既に十分に存在しています。私達の開発努力は、できるだけ最高のRuby IDEを完成させることに傾けるべきであると考えています。GUIサポートについても同様です。今までは、主に、編集およびデバッグツールを提供することを中心に考えてきました。JRubyは、分析的なIntelliSense、ブレークポイント、ステップインやステップオーバー、変数のドリルダウン表示をもつ早いデバッガなど、既存のすべての機能を利用できます。
しかし最近は、さまざまな種類のビジュアルなデザインツールのサポートに向けた動きも始まっています。既に私達の顧客の中には、Railsのドラッグアンドドロップのデザイン環境 (Visual Rails Workbench) のベータバージョンを使用している人もいます。これは、3月末にリリースを予定しているものです。この環境は、JRubyでも、標準Rubyでも同じように正常に機能します。このため、コードでERb (Embedded Ruby) テンプレートを記述する代わりに、画面上で完全なページのレイアウトを設計することができます。また、IronRuby用IDEにもビジュアルフォームデザイナを組み込むことを予定しています。これを使用すれば、IronRubyプログラマは、スタンドアローンなデスクトップアプリケーションをC#やVisual Basicと同様の方法で作成することが可能になります。私達がJRuby専用のビジュアルツールのサポートを行うかどうかは、そのようなツールへの要求がどの程度あるかによって決定されることになります。

InfoQ:  JRuby IDEの市場に思い切って進出する理由はなんですか？JRubyの使用を検討するVisual Studio開発者という市場は存在しますか？

Huw Collingbourne氏： 単純に答えれば、ユーザに、特定の1つのバージョンのRuby以外にも開発の選択肢を提供したいからということになります。数年前は、考えられるRubyインタープリタは1つ (標準Matz Rubyインタープリタ) しかありませんでした。しかし私達は、最近のJRubyの発展には感心しており、とても無視できるものではないと思っています。
さらに私達は、ユーザが特定のベンダからの特定の技術に「閉じ込められている」と感じないようにすることを常に考えています。ユーザには、可能な限り幅広い選択肢を提供したいと思っています。現在は、JRubyを、MRIに対する最高の代替手段とすることを考えています。また、JRubyは、現在も積極的に開発が進められています。1、2年後にどれほどその重要性が増しているかを正確に予測できる人がいるでしょうか？私達は、それがわかるまで待とうとは思っていません。これが、私達がJRubyをサポートすることに決めた理由です。

編集部注： Ruby in Steelサポート内のJRubyデバッガは正式にリリースされました。

原文はこちらです：http://www.infoq.com/news/2008/03/jruby-support-ruby-in-steel