JavaEEの終焉と、OSS主導への回帰

ここ数日、DIをめぐるダブルスタンダードが取りざたされていますが、
これらを見るとどうもJCPを主体とした組織による仕様規定とOSSの回帰が見受けられます。

率直に言えば、これはJavaEEの終焉の始まりなのかもしれません。
そもそも、火種はたくさんありました。

大きな一つがTCK（仕様を満たすかどうかのテストキット）の非公開があげられます。
JCPは仕様としてオープンにはなっているものの、各仕様についてTCKが公開されていないので
これについては元々不満をもっていた人はたくさんいたはずです。
例えば、Apache ファウンデーションはJCPへのvoteを全て不参加にするなどの措置をとっています。
たしかJDKとHarmony絡みだったと推測。
かくいう私もTCKは本来オープンにされるべきじゃないかと思う一人です。
仕様を満たせているか満たせていないかが明確に誰がやってもわかるのは仕様を実装する方としては
とても重要な事です。そのオープンさこそが必要だと思います。

もう一つ考えられる原因が、JCPのプロセスによって仕様として定義されるのがとても時間がかかることです。
これはきっちりしたプロセスなので仕方の無いことなのかもしれませんが
現実のビジネスの世界はそれよりも変動が早く、どちらかといえばスピード重視なことが求められる最近の傾向に
おいて、残念ながらJSRで定義されることよりも実際に使える事が重きをおかれるのは当然と言えます。
また各社ベンダの思惑も入るため、仕様が決定するのはどうしても遅くなります。

これらを鑑みると、今回のDIの標準などのように、どうしても今のままのJCPのプロセスで上手くやっていけるのかは
はなはだ疑問です。GoogleはそもそもJavaEEを全然使っていないので正直なところ驚きはあまりないです。
GuiceのMLなどをみても、JSR299ではなく、Guice固有のAPIを使ってシンプルに開発すればいいんじゃない？と
Guice開発者の人も言っているので。また、SpringSourceもTomcatをベースにしたAPサーバを作ったりと、
最近はJavaEEとの決別をしている気がします。

実案件に身をおく達人やOSSに身をおく人達にとって、JavaEEの全てが必要だとはとても思えません。
なので、JavaEE6のWebプロファイルに期待をしていた人はかなり多いはずです。GoogleとSpringSourceも
きっとそうだったに違いありません。WebプロファイルにJSFやEJBも入ってしまったのが
ターニングポイントになった可能性は十分にあります。

JavaEE5はOSSからの良い点を自分達の標準に反映して、JSFやEJB3を作りました。
これら標準はそれなりに受け入れられている気はしますが、TCKの問題や仕様に反映されるスピードの問題などを
考えると現時点以上の発展は望めないかもと思います。もしかしたらOracleがSun主体のJCPのやり方よりも
良いやり方を提示してくるかもしれませんね。例えばTCKは全て開示するとか。これには期待。

また、JavaのOSSでそれなりのポジションを獲得しているSpringSourceとGoogleがそろってJCPと決別し、
新たにOSSにおけるJavaの標準を作ってしまう可能性も十分にあります。
例えばJavaEE6のプロファイルを作ってしまうようなある程度標準にあわせた動きから、全く別個に標準を立ち上げる
ことだって可能性としてないわけではありません。それが自分達のビジネスやOSSの発展につながるなら。
このようなダイナミックな動きが仮にあるとすれば、まさしくOSS主導・スピード重視で行われていくでしょう。
もしかしたらそれがJavaEEの終焉（とJavaSE回帰）、そしてJavaのOSSによる本当に必要な標準の提起につながるかもしれません。

最近良くJavaは終わったようなことを国内外でよく聞きますが、OSS主導への回帰によって
再度Javaがもう一段盛り上がるのではないかなと期待しています。