古くはBeanshellやJythonのように、JVMの上で実行されるさまざまな言語には、JVM自身と同じくらい長い歴史がある。Javaのジェネリックス機能は、PizzaやGJのようなJavaを拡張した言語から生まれた。.NETでMicrosoftはSunと異なり.NET VMを複数の言語をサポートするように設計された共通言語ランタイム(Common Language Runtime:CLR)として市場に出した。初めはC#、VB.NET、CobolやEiffelSharp、続いてF#、IronPython、さらにDelphiなどの多くの言語をサポート(source)する。
JVMの上で実行される多くの言語(source)は、ほとんどがJythonやBeanshellのようなプロジェクトに注目し、その他の言語は一部の愛好家たち以外にはあまり知られていない。
Microsoftは動的言語ランタイム(Dynamic Language Runtime:DLR)(source)によって、CLRをさらに推し進めた動的な言語のための共通基盤を提供する。
これは残念ながらJVMに欠けていたものだ。ほとんどのJVM言語の実装者は、JVMの上であらゆるトリック、回避方法、解決方法を見付けるプロセスを繰り返してきた。
例えば永続的な世代ヒープ領域をメモリリークさせずにオンザフライでコードを生成する(source)など。
現状はJRubyのCharles Nutter氏がJythonやGroovyなどの他のJVM言語チームと話をすることによって変化しつつある。
その一歩はJVM言語の実装者が共通の問題や解決方法について議論するための共通フォーラムをGoogleグループ(サイト・英語)に作成したことだ。
これ自体にニュースとしての価値はないかもしれないが、最初のコラボレーションはすでに公開されている。JythonチームはJythonのパッケージキャッシングメカニズムのためのコードを提供(source)し、一般に利用できるようにした。このようなコードのための共通の場として、Java言語ランタイム(Java Language Runtime:JRL)(source)プロジェクトは発足し、すでにキャッシングのコードはソースリポジトリで利用できる。
JVM言語の将来の発展についてはメーリングリストで議論されるだろうが、DLRが提供するものからいくつかの方向性を見い出すことができる。
例えばバイトコードを生成するツールが必要だ。これにはソース言語の行番号を生成されたバイトコードの正しい位置にマップする、デバッグ情報のようなメタデータを生成するロジックが含まれる。
これは難しいことではないかもしれないが、すべての言語の実装で一から取り組まなければならない問題ではない。可変長引数によってオーバーロードされたメソッドをルックアップするためのロジックの実装(source)など、その他の共通するコードはJavaを統合するだろう。
それは単に基盤インフラによって、実装者の負担を減らせるということではない。それはまたグループが、動的メソッド呼び出し、クロージャ、あるいは継続などのさまざまな言語機能のために、最適なバイトコードを生成する方法を見付けることを可能にするだろう。それぞれの言語は異なるセマンティクスを持ち、どのくらい既存のコードベースを共有したり改良したりすることができるのか、現時点では不明だ。現在のJVMのバックエンドにおいて、バイトコードからネイティブコードを生成するJIT(Just In Time)コンパイラによって、適切に処理されることが明らかなバイトコードシーケンスと同様に、ワーキングコードやプロファイルドコードのサンプルはいまだに有益だ。
（この記事は2007年7月31日にリリースされました）