.NETが2000/2001年に最初にリリースされたとき、Javaコミュニティは言語、標準ライブラリともにJavaの"クローン"だと考えた。単純なコードサンプルを比べて見ると、その印象は確実なものとなった。しかし、MSはJavaと共にいた数年間も利益を得ており、さらに、Sunがたった今直面している問題もいくつか解決してきた。.NETとCLRがJavaよりも速く進化しているという印象は、Javaコミュニティも認識している。
Neil Bartlettによると、
Microsoft がCLR上でより早く革新を行っているのは明らかだと私は考えます。例えば:LINQは非常にパワフルな新機能です(付け加えるなら、Haskellのモナドをベースにしています)。ジェネリクスは、Javaよりも早く、しかもより良くC#でサポートされています(どちらもHaskellのポリモフィックタイプクラスから発想を得たような感じです)。CLRは、JVMよりも複数言語に対するより良いサポートがあります。そして今ではDLRがあります。DLRは恐らく、JVMで何か比較可能なものが提供されるよりも2年は先を行っているでしょう。
他の例としては、モジュール化とバージョニングを挙げることができる。.NETはクラスの集合体であるアセンブリを、基本的なデプロイ単位に選ぶことで解決している。アセンブリはバージョン情報などのメタデータを備えている。JavaのJarファイルに、バージョンメタデータが欠けているのとは異なる。これは、たくさんのライブラリを読み込む大きなアプリケーションでは、ますますトラブルの原因となる。OSGiはこの問題の解決策を現在は提供しており、SunはJava 7に同様の何かを追加するのに手いっぱいである。
Java言語は、ジェネリクスやオートボクシング、Enum型やアノテーションの追加などを行い、C#に追いつこうとし続けている。C#は現在、LINQテクノロジーに裏打ちされた形式の匿名式をサポートしている。LINQはXML、リレーショナルデータベース、任意のオブジェクトグラフといった多くの異なる種類のデータソースに対する、静的に型付けされたクエリ言語だと考えることができる。その間Javaでは、プロパティに対する言語のサポートや、言語に匿名関数を導入するための4つのタイプ など、言語の細部について議論している。
DLRのリリースにより、CLR上で動的/スクリプト言語をサポートするという領域においても、Microsoftは先行した。Javaにおいては、現時点では比較対象となるような取り組みがないのである。.NETのクリーンルームな実装であるMonoプロジェクトの創始者、Miguel de IcazaはDLRの機能を要約している。
- 動的言語に対する共通型システム
- 新しい動的言語を作成する際、言語開発者によって使われる共通の抽象構文木
- コンパイラ開発者のためのヘルパー/ユーティリティルーチン
- プログラムに汎用スクリプト言語インターフェースを埋め込み、開発者が一つ以上の動的言語でアプリケーションを拡張できるようにする、共通ホスティングインターフェース
- コンソールのサポート。対話的なプログラミングを行うための単純なコンソールインターフェースを持つことができる
共通型システムは、動的言語と対話し、オブジェクトのやり取りを行うことができるようにするための重要な要素である。Jim Huguninは、これについての論理的根拠を説明し、Javaにおける状況とDLRがどのように異なるアプローチをとっているかを見せている。 Jim Huguninがその違いについて知っているのは間違いない。何と言っても、彼はJVM上で実装されたバージョンのPythonであるJythonを開発しており、その後Microsoftに移籍し、CLR上で動くPythonであるIronPythonを実装している。Jim Huguninは、問題のうちの一つを次のように説明している。
ラッパーアプローチは、また、より深い問題を抱えています。一つのチャレンジとしては、単に、何のオブジェクトを渡すかを決めるというだけのことです。
例えば、PythonがPyStringという型を持っていたとして、Object型を期待するC#関数を呼び出すとき、PyStringを渡すべきなのか、
それともそれをラップ解除してStringにすべきなのでしょうか?こうした種類の微妙な型の問題に、良い解答というのはあり得ません。
さらに悪いことに、プログラマの知らないところでオブジェクトが暗黙的にラップ/ラップ解除されると、
オブジェクトのアイデンティティが失われてしまうことがあるというひどい問題があります。
この種の問題はJava界で明白なこととなっている。たとえば、JRuby 1.0がJavaとRubyの間でStringを受け渡しするための方法である。
- Java文字列がRubyに渡されるところではUTF-8にエンコードされる。これはつまり、文字列を受け取る側はそれをUTF-8のバイト配列として取り扱う必要があるということである。
- Ruby文字列がRubyを超えてJavaライブラリに渡されるとき、UTF-8であると仮定される。Java側から戻される文字列もその仮定に従う。
Javaはこれまで述べてきたような項目に対して実際何もしていない。Java 6で追加された、JSR 223という名前で呼ばれるホスティングインターフェース以外は、だが。これは基本的には、新しい言語の実行環境を追加し、初期化子、標準的な方法でそれらにアクセスするための単なる枠組みである。
Jim Huguninは、動的なメソッドディスパッチを処理する方法についてさらに詳細に述べている。それは拡張メソッドとその他既存のCLRシステムを利用するというものである。唯一比較可能な取り組みはJSR 292だが、新しいinvokedynamicバイトコードを追加する必要性のある他の物事に混じってしまっている。この取り組みはGilad Brachaによって始められた。彼はこのJSRを作成した後すぐにSunを離れた。現在では、このプロジェクトが何らかの短期的な解決策になる、とは信じられていない。
JSR 292はこれらの問題を導くために私が始めた取り組みです。私なしでもこの取り組みが継続することを望んでいますが、達成に至るには数年かかるでしょう (達成されるかどうかもわかりません)。率直に言って、これらの機能をに対するサポートをJVMに加えるのは、Strongtalkを安定させるよりも難しいです。
注意: Strongtalk はSmalltalkの実装で、そのVMはHotspotテクノロジーのベースになっており、SunのJVMには長らく搭載されている。
JSR 292のスペックリードであるDanny Cowardは、パフォーマンスの向上について自信を深めているようである。
動的言語エンジンの作者は、たとえば、RubyコードをJavaバイトコードに変換する必要があります。現在のJRubyエンジンでは、メソッド呼び出しをバイトコードに変換しようとするとき、その戻り値を表現するために合成されたインターフェースを作成する必要があります。それは開発者が作成したインターフェースではなく、純粋にJRubyエンジンが作りだしたものです。そのため、そうしたメソッド呼び出しをバイトコードに変換することができるのです。そして、それは戻り値についてのみではなく、メソッドパラメータと例外についても同じことが言えます。
JSR 292は、こうした合成インターフェースの必要性を排除します。現在、動的言語のインタープリタは、たとえばRubyコードを処理する際、 methodinvokeバイトコードを吐き出す必要があります。将来的にはJSR 292により、それらインタープリタはinvokedynamicを使うようになるでしょう。それ(JSR 292)はエンジンの実装を合理化します。なぜなら、今日のエンジンの多くは、新しい合成型を作成してそれらの維持しなければいけないのが悩みの種だからです: 7、もしくは8つの異なる箇所でメソッドが呼び出されると、全ての箇所でそうした合成型を再利用する必要があるのです。
重要なこととして、これらの変更がJVM仕様に入ってしまうと、それはハードコードされ、将来変更することが簡単にはできないということを意味している。ライブラリベースのアプローチには、これらのシステムを処理すより良い方法が見つかったときに、そちらを使うよう迅速に変更できるという利点がある。 JVMベースのアプローチは、これからも長い間同様であり続けるだろう。なぜなら、JVMは長期間同じものが使われがちだからである(参考までに、Java 1.3は今だに企業内で使われているのだ)。また、JVMは実際にこのバイトコードを使用し、本当に動的なメソッド呼び出しのスピードを向上するのか、はまだ分からない。
その他の問題としては、JVMベースの言語に対する公式なサポートと援助に関するものである。現在は、JRubyの開発者のうち二人がSunの従業員である。その一人であるCharles O. NutterはJythonやGroovyといったコミュニティに接触しはじめた。そうした取り組みが始まるかどうかはまだ分からない。(しかし) MSはIronPython、IronRuby、JavaScriptや動的なVBサポートなどと密接に協力するチームを持っていることを考えると、明らかに有利な位置にいる。結局のところDLRは、経験を共有した異なるチームによるプロダクトであり、共通のライブラリやナレッジベースとして結実している。ゆえに、JVMベースの言語チームは重要な教訓をよく学びなおすべきなのだ。
例えば、JRubyはJust In Time(JIT)コンパイラを機能として持ち、RubyコードをJavaバイトコードへの実行時に変換する。問題は:現在のバージョンでは、このコードは通常のset_trace_funcベースのデバッガ(デバッガの機能を実装するためにコールバックアプローチを用いる)が機能しないのだ。コールバックが呼ばれないのである。これが意味するところは、JRubyのデバッグに影響を及ぼすということである。同様のこうした問題は、あらゆる言語で解決され、対処されるべきであり、最低でも経験を、恐らくコードを共有することが、時間と作業の節約になる。
ちょっとした予想をつけ加えよう・MicrosoftのDLRはまもなくIronPythonとともにオンラインで利用可能となり、自らを証明するだろう。IronRubyはまだリリースされていない、その実効速度と汎用的な相互運用性がどうなるかはまだ分からない。Javaは依然として、.NETよりもオープンだと見なされ、. NETよりも多くのプラットフォームで動作可能だというメリットがあるが、Miguel de IcazaはMonoが今年末までにSilverlightをサポートできるようになるのは確実だとみている 。
（原文は2007年5月7日にリリースされました）