http://martinfowler.com/bliki/GroovyOrJRuby.html

現在、Java仮想マシン（JVM）上で動くスクリプト言語として、GroovyとJRubyはどちらが優勢なのかという議論が巻き起こっている。 この言語戦争の勝者はどちらなのか！？ 知りたいよねー。知りたいでしょ。 みんなは「プロジェクトに使うのはどっちだ？」とか「今から学習するならどっちだ？」とか気になっていると思う。

まず最初に押さえなきゃいけないのは、このレースの出走馬が2頭だけだと考えるのは公平じゃないってことだ。 JVM上のスクリプト言語の歴史は古く、Jython（JavaによるPython実装）なんてずっと昔から存在している。 他にもいろいろありすぎてよく分からない状況なので、ここではあえて列挙することはしない。「XXXがないじゃないか！」と怒られても困るしね。

JRubyは、Ruby（というかRails）が注目されたことによって、多くの注目を集めている。 ThoughtWorksにおいても、RubyやRailsの人気の急上昇っぷりには目を見張るものがあった。それにJRubyは、既存のJavaインフラにRailsアプリケーションをデプロイできるというメリットをもたらしてくれた。

Groovyは、他の言語と比べて、JVMとよりシームレスに動作するよう設計されていることで注目を集めている。また、早くからJSRとして標準化が提案されたことでも有名だ。

私も数年前に注目していたが、その頃のGroovyの開発は泥沼化の様相を呈していたので、手を出さずにいた。しかし、1.0がリリースされ、同僚からも好評の意見を聞くことが多くなったので、手を出してみたことがある。

それでは、共通点から見ていこう。 JRubyもGroovyも（もちろんJythonも）、現代的なオブジェクト指向スクリプト言語である。 スクリプト言語の簡潔さと、比較的大きなプログラムの構築のための構造の強さとがうまく融合されており、従来のスクリプトの用途にも大規模プログラムの用途にも適したものとなっている。 JRubyもGroovyも動的型チェックを備えている。 ただし、Groovyでは、いくつかの静的な機構も兼ね備えている。 両者とも、高い表現力を担う重要な機能であるClosureを備えている。 スクリプト言語ではぜひとも欲しい機能だ。

両者の最も大きな違いは、そのプラットフォーム哲学にある。 GroovyはJavaのスクリプト言語として設計されており、シンタックスはできるだけJavaと等価になるように配慮されている（switch文がデフォルトでフォールスルーする醜悪さも踏襲されている）。

Javaのクラスライブラリを直接触ることができるし、動的にメソッドを追加することもできる。これはクロージャを実現する上で必要不可欠なものである。

一方、JRubyは、RubyプラットフォームのJava実装である。 Rubyは現在、Cランタイムのある主要なOS上で動作することができる。 また、.NETのCLRでも動作し始めたところだ。 JRuby上でプログラムするときは、Javaで実装されたRuby言語のライブラリを使用することになる。また、Java言語のライブラリも利用可能だ。 Ruby言語のライブラリを使ったり、外部要素をラップしたりしておけば、RubyのプログラムをCやNETランタイムの他にJava上でも実行できるようになるわけだ。 つまり、JRubyを使って既存のRubyプログラムをJVM上で実行することもできるし、 JVMを制御するスクリプト言語としてJRubyを使うこともできるのである。 ★（訳注：まだなんか不自然。FIXME）

JRubyとJythonの大きな違いはライブラリ周りにある。 スクリプト言語をJVMに移行するときに厄介なのは、元の言語が、Cで実装されたライブラリと密接に統合されているという点である。 こうしたライブラリをJavaへ移行するには、Javaで書き直さなければならない。 Jythonではこうしたことをやらなかったので、多くのPythonアプリケーションはJython上では動作しない。 一方、JRubyでは当初からRailsアプリケーションを動かすことを目標に決めていたため、すべてのRuby標準ライブラリを移行する必要があった。

JRubyがJVM上のRubyプラットフォームということは、JRuby上には2種類のオブジェクトがあるということである——JRubyのオブジェクトとJavaのオブジェクトだ。 両者間でやり取りをしたり変換したりする方法はあるものの、やはり両者には違いがある。 JavaのStringなのかJRubyのStringなのか調べようと思ったら時間がかかる。 Groovyではそうした境目はない。すべてがJavaのオブジェクトなのである。

勝者が誰なのかを明言するには、まだ時期尚早である。というか、難しい。 どちらもまだ日が浅いし、ようやくJVM上で動作できるようになったところである。 個人的なレベルでは、どの言語を選択するかというのは、言語に何を期待しているかということと関係している。 JVM上で動作することだけに興味があるのであれば、Groovyがいいだろう。 Javaのライブラリやオブジェクトモデルを直接触ることができるし、シンタックスにもすぐ慣れる。 Rubyが好きなのは複数の実装があるからだ。 Rubyは様々な箇所で利用可能なツールである。 古参のRubyistとしては、確かに好きな言語ではあるのだけど、Groovyにはあまり興味が沸かなかったりする。

Railsは重要な要素である。Java界にはWebアプリケーションフレームワークが乱立しているが、Railsは一度使用した者から広く好まれている。 Grails（GroovyのWebアプリケーションフレームワーク）についてはまだそれほど多くの報告を受けていないので、あまり意見は申し上げられない。 ただ、JRubyの人気を上げたのは、Railsアプリケーションを簡単にデプロイできるようにしたことだというのは、想像に難くない。 もうひとつ着目すべき点は、テスティング環境の新機軸であるRSpecの台頭だろう。

どんなプラットフォームであっても、技術的要因と同じようにコミュニティに属する人についても考慮することが大切である。 優れた人であれば、技術的弱点も迅速に解決することができる。 活気のあるコミュニティは、大きなイノベーションの源泉である。 特に、RubyPeopleは活気のあるコミュニティを形成している。 そこでは、Rails、Rake、RSpecといったものが生み出されている。

JRubyとGroovyはJVMにとって重要になるのだろうか？ Jythonは大きな影響を与えられずにきた。 こうした言語に対するツールサポートは、Javaのそれと比べると惨々たるものだ。

我々はJavaの変曲点にあるのだろう。 最近までJavaはひとつのVMにOneLanguageをスローガンにしていた （ひとつのVMに複数の言語[C#やVB]のCLRとは対極である）。 これは、みんながJavaの限界に気づき、別の可能性を模索し始めたという変化ではないだろうか。 おそらく、いずれ複数の言語がJVMに密に統合される日がやって来るはずだ。

RailsやRubyの人気っぷりが嫌だという人も大勢いる。 しかし、Rubyのことが嫌いだとしても、この盛り上がりによって新たな言語への関心が再び高まってきたのは事実だ。 この盛り上がりがなければ、Groovyはこんなにも注目されなかったのではないかと思う。 それに、Jythonが眠りから目を覚ますこともなかっただろう。 Ruby/Railsの盛り上がりは、ちょっと変わったJVM言語の関心をも高めている。 これについては、JRuby ピープルがライバル言語を励ましていて実にすばらしい——複数言語のインターオペラビリティとイノベーションの促進がポイントとなると分かっているのだ。★

Comment:

  • 2007-12-01 (土) 02:19:16 たかはし : 単にJavaとかRubyとか書くのではなく、Java言語、Ruby言語と書くのがいいですかね？「JRubyでプログラムするときは、Javaで実装されたRuby言語のライブラリを使用することになる。ただし、Java言語のライブラリも、自己責任で使用することができるだろう。」とか。
  • 2007-12-01 (土) 02:39:22 たかはし : 「Ruby言語のライブラリを使ったり、外部要素をラップしたりしておけば、 そのRubyプログラムをCやJavaや.NETランタイム（これは間もなく登場）上でも実行することができる。」
  • 2007-12-01 (土) 14:11:03 名無しさん : 下から3番目のパラグラフ、「燦々たるものだ。」の「燦」は「光り輝く」という意味なので、文脈からすると「惨々たる」が適切ではないでしょうか？
  • kdmsnr:「燦々たる」→「惨々たる」にしました。
  • kdmsnr:＞たかはしさん ちょっと言葉を足して修正してみました。これは実際の動作と合ってるのかなあ？
  • 2008-01-15 (火) 21:48:37 keis : 「だからJRubyは、RubyプログラムをJVM上で実行する手段としても、JVMを制御するスクリプティング言語としても使えるのです。」言外には、Groovyは後者だけだよね、といことかと。