JVMとCLR ランタイムまとめ
スクリプト言語の処理系の実装にやる気を見せているJavaプラットフォームや.NETプラットフォームについて、それぞれのランタイムの現状を復習がてらまとめてみた。
言葉の整理
コンパイラ言語
インタプリタ言語
最近ではたいていの言語はこれらについて複数の方式を提供しているので選択したり、組み合わせて使うことができるため境界はあいまいで、要はどっちの方式が主流かというバランスの問題。たとえばJavaの場合、ソースコードを一度コンパイルし中間コード（Javaバイトコード）に変換してから、実行時にバイトコードをランタイム（インタプリタ）で解釈する方式を採っている。（Cと比較する文脈ではインタプリタ方式、スクリプト言語と比較する文脈ではコンパイラ方式と表現されることがよくある。）
Javaプラットフォームも.NETプラットフォームもコンパイラによって中間コードを生成し、それをJITコンパイル機能を備えたランタイムが解釈して実行するという方式が主流となっている。
以下Java、.NETについての詳細の説明。
ソースコード：Java、Rhino（SE6で標準サポート）、Ruby、Pythonなど
↓バイトコードコンパイラ（JDK）
中間コード（Javaバイトコード）
↓ランタイム（JavaVM）：Sun JVMの場合、対応プラットフォームはWindows、Solaris、Linux、Apple(OS X)
ネイティブコード
Ruby処理系のJava実装がJRuby、Python処理系のJava実装がJython。
JRubyでは、Rubyコードを初回読み込み時にJITコンパイルをおこない、可能ならばJavaバイトコードに変換しJVMが直接実行する。Javaバイトコードに変換できないところはJVMとの間にJRubyインタプリタが挟まる形で実行される。
.NET
ソースコード：VB、C++、C#、Ruby、Pythonなど。Javaに比べるとかなり以前から複数言語サポートの方向性を打ち出している。
↓バイトコードコンパイラ
中間コード（MSIL）
↓ランタイム（CLR、DLR）：対応プラットフォームはWindows。Linux用CLRもあるみたい。
ネイティブコード
Ruby処理系の.NET実装がIronRuby、Python処理系の.NET実装がIronPython。
DLR（Dynamic Language Runtime）はCLR（Common Lanuguage Runtime）が動的言語をサポートするための追加ライブラリ。動的言語は実行時にDLRによって中間コードに変換され、それをCLRがネイティブコードにJITコンパイルする。
Javaと.NETを比較すると、プラットフォーム非依存という意味ではJavaが優位、言語非依存という意味では.NETの方が現状では優位。
Java vs .NETとか、Ruby vs Pythonとか、選択肢が複数あって競争が発生してる状態っていうのは、ここ1年くらいの急な展開を見てもわかるとおり、テクノロジー的には良い状態なんだろう。使う側からすると、何でもいいから早く決着ついてくれってとこもあるけどね。
