Java技術の登場から，9年以上が経った。その成長過程を記者として観察してきた筆者は，一時期こう思ったこともあった。「Java技術も成熟してきたし，もう一段落付いたのかな」と。ところが，それが思い違いだった。最近のJavaはどうも様子が違うのだ。Java技術の「次のイノベーション」は，今まさに起きているのではないか。それがこの記事の結論である。
何が「次」で，何が「イノベーション」なのかって？ たしかに結論だけでは何がなんだか分からない。Java技術の上に起きつつある変化について，順番に話をしていこう。
最初にお伝えしておくと，筆者は変化が起きているという事実だけでなく，「変化を起こすエンジン」が存在することが重要だと考えている。Java技術を変化させているものは何なのか。そうした視点を持ちつつ，まずJavaの変化を見ていきたい。
Javaの転換期は今
Java技術の歴史の中で，2004年から2005年にかけて，つまり「今」は転換期だったと，後から振り返って思うようになるだろう──それぐらいに大きな変化が起きている。Java技術とは，プログラミング言語（Java言語），実行環境（JVM：Java仮想マシン），フレームワーク（Java API群）から成り立っている。そのそれぞれの階層で，大きな変化が起きているのだ。
(1)プログラミング言語の変化：
Java言語仕様が大きく変わる。2004年9月に正式版をリリースしたJ2SE5.0（J2SE:Java2 Standard, Standard Edition，Java技術のコアとなる実行環境）では，Java言語仕様にGenericsとメタデータという大きな拡張が加わっている。「Java登場以来，最大の言語仕様の変化」（米Sun Microsystems）が起きようとしているのだ。この言語仕様の変化は，多くのJava APIに影響を与えている。エンタープライズAPIの新バージョンの多くが，メタデータに基づくアノテーション（プログラム中に記述する付帯情報）を取り入れ，短いコーディングで多くの情報を記述できるようになりつつある。
(2)Java実行環境の変化：
J2SE5.0では，JVMの管理機能やユーティリティを大幅に強化して，いわばJava実行用のOS（オペレーティング・システム）としての性格を備えた。例えば，従来はJ2EE（Java2 Platform, Enterprise Edition，エンタープライズ・システム構築向けのJava技術）分野で管理機能として使われていたアプリケーション管理フレームワークJMXを標準搭載した。それだけでなく，JVM自体のモニタリング機能（JSR 174: Monitoring and Management Specification for the Java Virtual Machine）を搭載する。JVMの実行時の状況，つまりメモリー使用量，スレッドの状態を常時監視することが，標準機能の枠組みの中で可能となった。
J2SE5.0で新たに追加された機能の中には，並行処理ユーティリティ（JSR 166）がある。ニューヨーク州立大学のDoug Lea氏が提供したライブラリに基づく。いわば「草の根」のライブラリが，標準仕様に採用されたのである。
(3)フレームワークの変化：
サーバー・サイドJavaのフレームワークが大きく変わろうとしている。エンタープライズ向けJava技術であるJ2EEの「使い方」を説明した文書である「J2EE Blueprint」では，Web層，EJB（Enterprise JavaBeans，トランザクション処理を含む業務ロジックをコンポーネント化するためのフレームワーク）層に分けてアプリケーションを構築するという考え方を記している。この両方の層で，フレームワーク交代の時期を迎えている。Web層の新フレームワークはJSF（JavaServer Faces，コンポーネントを組み合わせてWebアプリケーションを構築するためのフレームワーク），EJB層は，仕様案が公開されたばかりの次期EJB仕様「EJB3.0」である。
注目したいのは，フレームワークの変化を促したものが，「草の根」のオープンソース・ソフトウエアだったということである。
JSFに影響を与えたのは，オープンソースのWeb層フレームワークとして普及したApache Strutsである。JSFはStrutsの考え方を進化させた内容だし，JSFのSpec Lead（仕様策定リーダー）の一人であるCraig R. McClanahan氏はStrutsの作者でもある。
EJB3.0に影響を与えたのは，やはり「草の根」のオープンソース・ソフトウエアである。EJB3.0はDI(Dependency Injection，依存性注入)コンテナとPOJO（Plain Old Java Object）永続化という新機能を取り入れ，プログラミングの複雑性を大幅に軽減している。これらの概念は，PicoContainer，Springなどオープンソースの「軽量コンテナ」が実装して注目されたものだ。
背景には「現状のEJBが複雑すぎる」という批判がある。元々EJB批判派が作った設計思想とオープンソース・ソフトウエアが，EJB3.0の中心的な概念となるまでの影響力を持ったのだ。
(4)スクリプト言語：
Java技術仕様に，新たなプログラミング言語Groovyが加わった（JSR 241）。Java言語とシームレスに使えるスクリプト系の言語である。極力短いプログラムで済ませたい処理では威力を発揮しそうだ。「Java技術にJava以外の言語が加わる」と聞くと違和感があるかもしれないが，Java技術の資産を使えるスクリプト系へ言語への要望は以前からあった。Groovyは元々「草の根」のオープンソース・ソフトウエアだったのだが，それが認められて標準仕様として採用されたという経緯がある。
以上のように，Java技術の構成要素が，大きく変化している。少し前まで，サーバー・サイドJavaといえば「サーブレット，JSP，EJBが重要なAPIである」という説明が主流だったが，JSFとEJB3.0を駆使したアプリケーションは従来とは全く異なる「字面」のプログラムになる。さらに，短いプログラムやテスト時には，Java言語だけでなくスクリプト言語からJavaフレームワークを呼び出すような使い方も出てくるだろう。
これらの変化は，大きな視点で見ればオブジェクト指向のメリットをより引き出す方向への進化といえる。もちろん，開発生産性の向上，保守性の向上，運用管理の容易さという実務上のメリットがあることはもちろんだ。
そして，これらの変化の原動力は何なのか。
開発者コミュニティこそ「変化のエンジン」だ
ここで，なぜ「今」が「次のイノベーション」の時期なのか，という理由を記しておきたい。
Java技術の発展史の中で，1999年から2000年にかけての時期は大きな節目だった。J2EEのコンセプトは1999年に登場した。日本国内でのJ2EEの本格的な普及はさらに2～3年後のことになるが，技術体系は5年前に確立していたわけである。この5年前に作られた枠組みが変化の時期を迎えている。私たちの目の前に，次の世代のJava技術が姿を現しつつあるのだ。
2000年にはJCP（Java Community Process）2.0が登場した。会員制の組織でJava技術の仕様策定を進め，その舵取りは委員会方式によるものとした。ここで，特定の企業の都合だけに左右されない仕様策定の手続きが確立した。この仕組みが，5年近くの運用期間を経て「変化のエンジン」に成長しつつある。
J2EEは，今まで「Web層とEJB層のギャップが大きい」「EJBは複雑すぎる」といった批判にさらされてきたが，それは実際に使われる技術だったためでもある。JCPも，「完全にはオープンではない」「策定した技術仕様の知的所有権をSunが保持するのはおかしい」といった批判を浴びつつも，機能するコミュニティに成長してきた。
Java技術の変化を起こしている直接の当事者は，5年前に成立したコミュニティによる仕様策定プロセスJCPだが，JCPに議論や技術をインプットしているのは，Java技術への批判者も含めた広いJava開発者コミュニティである。彼らは，次の世代のJava技術のイノベーションを先行して取り入れる開発者でもある。ここから生まれる次の世代の技術は，2～3年の後には多数派の企業ユーザーに影響を及ぼすようになるだろう。
Java技術の「変化のエンジン」は開発者コミュニティだ。特定の企業の都合ではなく，Javaを必要としている多くの開発者達の議論，貢献がJava技術を動かし，進化させているのである。
（星 暁雄＝日経BP Javaプロジェクト）
