新たな JVM 言語の開発

作者 Alex Blewitt , 翻訳者 吉田 英人 投稿日 2011年4月24日

セクション

設計/アーキテクチャ,

デベロップメント

トピック

JSR 292 ,

JRuby ,

JCP Standards ,

Scala ,

JCP ,

Java ,

Functional Programming ,

言語 ,

プログラミング ,

言語設計

共有 |

原文(投稿日：2011/04/18)へのリンク

先週の Ceylon の発表によって，JVM ベースの言語に注目が集まっている。Ceylon が最初の JVM ベース言語という訳ではないし，最後になることもないだろう。しかし，JVM ベースの言語はもともと，Bruce Tate 氏が 2005 年の自著 "Beyond Java" で提案したもので，それ以来 Java プラットフォームの注目を長く集めてきた。Wikipedia に記載された JVM 言語の一覧でも，それは裏付けられる。同氏はその成功の鍵を，コミュニティに見出していた。

相当な規模を持ったコミュニティの創出が必要でしょう。ユーザに対する相対的な安全性が担保されない限り，広範な採用など望むべくもありません。

Gavin (訳注: Ceylon の開発者 Gavin King 氏) は，Ceylon について氏が提示したポイント (Java を数学言語とみなすこと) を明確化するには，コミュニティによる取り組みが必要だった，と指摘した。Java のシンタックスが C (ないし Algol 系言語) を基本としている点を考えれば，このような比較は誤解の避けがたいものだったが，氏は謝罪を求めている。

今私は，この件で私を無知と呼んだすべての人々に対して，多大な謝罪を求めます。特に Scala ファン，あなた方に，ね ;-)

Lockster 氏は Ceylon について，違った意味で興味深い ("Ceylon, interesting for the wrong reason") と表明している。おそらく興味があるのは，RedHat が新しい言語の認知を得る必要がある，という点だろう。もしかするとこれは，Java 言語の現在の進化 (あるいはその欠如) に伴う問題なのかも知れない。JVM と invokedynamic バイトコードのパフォーマンスという問題は依然として残るが，別の言語を作り出すことで Java の落とし穴を逃れられるかも知れないのだ。

Ceylon の提案に関して大きな問題のひとつは，現時点で IDE (コンパイラなどのツールチェーンも) が欠如していることだ。言語にはコミュニティによるサポートが必要だ。そしてコミュニティによるサポートには，無償で使用可能(かつ強力)なツールは不可欠なのだ。Scala には Eclipse IDE のサポートがあり，JetBrains も IntelliJ で Scala をサポートしている。Sven Efftinge 氏もまた，新しい JVM 言語の開発を検討する 上でなすべきこと (ToDo) のリストを記している。

• 不要不急な変更を行わないこと
• 静的型付言語であること
• ジェネリクスに関与しないこと
• 型推論を用いること
• ツールサポートに留意すること
• クロージャ
• 使用されない古い概念は取り除くこと

氏はまた，IDE によってサポートされる DSL の生成方法として，Eclipse Xtext の使用を推奨する。Eclipse Xtext は文法生成のための Eclipse ツールのセットである。一連の IDE プラグインにより，生成された文法に従って記述されたスクリプトの編集や表示が可能になる。

興味深いことに，言語のごくわずかな変更が大きな影響を与える場合がある。Java 言語の開発が遅い理由の一端は，その下位互換性に関する問題によるものだ。これはライブラリに限らず，言語のシンタックス自体にも当てはまる。Brian Goetz 氏は昨年，Java 言語の変更選択に関する 定量的言語設計 (Quantiatative language design) という記事を発表した。そこで取り上げられたケースでは，数百万行に及ぶ Java コードを使用することによって，実装の選択 (記事ではダイアモンド演算子に対する型推論) が既存コードベースに対して与える影響の測定が実現できている。Java にはこのようなコードベースがすでに存在する – が，新しい言語では必ずしもそうではない。

JVM 上に移植された言語は，Pyton (JPython) や Ruby (JRuby)，Lisp (Clojure)，さらには Tcl (JTcl) まで数多い。これらの言語はすべて，JVM ベースのプラットフォーム上でも，既存のプログラム言語と同じような動作をして見せる。大部分の言語がネイティブな実装よりも高速に動作しているが，すべてがいつも可能なわけではない ("last flight of the unladen swallow" の記事を参照　– 訳注: unladen swallow は高速化を特に目標とした CPython のバージョンで，先日プロジェクトの中止が発表された)

次に，Scala や Gosu，Mirah などといった，まったく新しい言語がある。これらは Java プラットフォームと (ある程度) 互換性を持つが，実行上のシンタックスは Java に似通っていたり，あるいは大きく異なっていたりする。Ceylon が競合するのは，既存言語の移植よりもこちらの方になる。移植言語は，どこかで既に存在する言語のユーザを対象とするものだからだ。

ひとつ確実なのは，コンパイル時に Java に中間的に変換されるものであれ，バイトコードを直接生成するものであれ，JVM プラットフォームが実験的言語のために選択される場所になっている，ということだ。今のところ，Java の後継としてデファクトに達した新言語は存在しないが，すべての言語に成長の余地がある。上げ潮はすべてのボートを等しく持ち上げているのだ。

重要な問題は，言語が自律性を獲得するまで，どのようにコミュニティを成長させるか，にある。そのためには，言語に対する充実した IDE サポート (IDE が複数あればなお良い) や，普及を促進するための模範的フレームワーク (Ruby の Rails，Scala の Lift のような) の存在が欠かせない。JVM ベース言語の作成は文法ファイルから始まるが，それは長いプロセスの始まりでしかないのだ。