Apache Harmony Project
結局のところ、このプロジェクトが何を目指しているのかが極めて不明瞭なのが一番の問題だろう。PROPOSAL*1によればこのプロジェクトの目的は
となっている。
1.に関して、まず第一になぜこんなことをしなければならないのかが分からない。Apacheの人々はSunの提供するJ2SE 5に何か不満があるのだろうか？確かにフリーな実装があるのはいいことだが、それは既にKaffeをはじめとした様々な独立プロジェクトが既にやっていることだ。それらがApache v2ライセンスでは無いにしても。ここから始まるスレッドを読んでも理解できない。
また、仮に完全互換な実装を作成するにしても問題はある。特に標準クラスライブラリに関しては実質的にGNU ClasspathかSunのJDK付属のクラスライブラリ以外に選択肢は無い。標準クラスライブラリをゼロから実装しなおすのはあまりにも非現実的だ。従ってこの点に関しての今後の問題点はライセンス問題のみとなる。ApacheがGNUかSunとライセンスの擦り合わせができればOK、できなければ終わり。ただそれだけだ。
VMの実装に関しては多少の実現性はあるだろう。つまり、Apacheライセンスの元でJ2SE 5互換なVMをゼロから実装するのは一応可能ではある、ということだ。それに何の意味があるのかは疑問だが。既存のフリーなVMには無い、何か新しい技術的なアイデアを投入して世間の興味を引くものになることを願う。（JITコンパイラでなく）VM実装自体の最近流行りのトピックとなるとVMプロセス間のヒープの共有化とか、VMプロセスの永続化とかか？なんか面白さとしてはイマイチだが。
2.に関して、VM内部のモジュール間のインタフェースを定義したい、というのはこの分野の人間なら誰しも考えることだし、今回のHarmonyの提案の中で一番意味があるのはこの点だろう。特にクラスライブラリのネイティブ側インタフェースやベリファイアなどは独立性が高いのでインタフェース策定の対象として適している。しかし、JITコンパイラ、インタプリタ、メモリ管理、スレッド管理のそれぞれはお互いがお互いの実装に微妙に依存しあっているので一般的なインタフェースを切り出すのは難しい。Kaffeはこの点でわりと良くモジュール化されているが、それは例えば「GCがオブジェクトをコピーなどで移動したりはしない」などの仮定を置いているからできることだ。また、性能を出すためにもモジュール間がお互いの実装に依存することは必要となる。
結論として、まだ提案段階とはいえ現時点のHarmonyにはそれほどの面白さは感じない。しかし、Apacheプロジェクトのある種の政治力というか、人目を引く力というのはこの業界において無視できないものだ。何か面白い展開があるといいのだが。これまでどおりKaffeやGNU Classpathの周辺をウロチョロしながら横目で見ていく感じになるだろう。
