度重なる JSR の遅れ，Lambda Project と Project Coin コレクションリテラル (Collection Literals) の放棄，その結果として Plan B の採用，といった一連の出来事から一歩退いて，これらが Java 環境に及ぼす変化を見るのは興味深い。事態が思うほど単純ではないことが分かる。
実装アイデアの面から
“考えるのはたやすい，すべては行動” とはよく聞くが，Java 言語の変更にこれほど当てはまる言葉は他にない。Java 環境の中核部分を定義するのは，Java 言語仕様 (Java Language Specification) とJava 仮想マシン仕様 (Java Virtual Machine Specification) という２巻の資料である。これらを更新する代わりに新たな API (I/O に関してはさらに新たな(new new) API) によって拡張を実現する，という方法が Java 環境の安定性の一因となっている。言語自体が大きく変更された例としては，内部クラス(inner class) と 総称型(generics) の導入がある。いずれも初期段階においては，以前のバージョンとの非互換性は発生していなかった - ただしアノテーション導入時のように，新機能によってバイトコードのバージョン番号が無遠慮に更新された事はある。
Java言語の変更は結果的にこの２冊のどちらか，あるいは両方を修正することになる。それ自体が膨大な作業だ。Java言語仕様バージョン３は 647 ページあるが，構文定義はその中でわずか 12 ページに過ぎない。つまり新しい構文要素 (コレクションリテラルやダイヤモンド演算子，try-with リリースブロックなど) の追加は，言語文法の単なる変更には留まらない，ということだ。
Project Coin の提案する "文字列による switch 文" を例に取ってみよう。これはリテラル文字列をリテラル数値や文字と同じように使えるようにするものだ。そのためには，switch 文のシンタックスを修正してリテラル文字列を追加すればよい - 本当にそうだろうか？
Joseph Darcy 氏が JavaOne で，Project Coin の状況に関するプレゼンテーションを行っている。その時に氏は 上図で示した例 を使って，それが簡単な変更ではない，という事実を強調していた。図の３つのテキスト列は，JSR を記述する時に従う必要のある詳細項目の量を表している。Example のセクションはごく簡単だ。Spec の行数もごくわずかである。大部分がコンパイル機構 (つまり，それを可能な限り効率的な方法で，ランタイムコードに変換する方法) について言及した部分であり，それ以外には参照と互換性の記述が多少ある程度だ。
通常の(単純な)変換方法では，非常に効率が悪いことは明らかだ。そこで最初に String の hashCode( ) を求めて通常の switch ブロックで判定可能なステップを実行して，その後で文字列の等価比較を順次行う，という方法が考案された。もっと素直な方法で問題を解決できるかも知れない。しかし String が final クラスであるという事実と，hashCode( ) の値が不変であるという事実を利用すれば，本来ならば動的コールが必要な処理の多くを JIT がインライン処理することによって，実行時の効率向上が期待できる。
変換処理は(正と負の両方のケースで)テストを行う必要がある。興味深い実装方法ではあるが，コード変更の大部分はテストに関連するものだ。下の図は実装コードのスクリーンショットである。強調表示されている最初の１列半が変換に関する実装で，残る３列半がテストケースに相当する。
追加情報は Project Coin のプレゼンテーション資料 を参照して頂きたい。ところでこの資料は，どのような位置づけになるのだろうか？
Java 仕様要求 (Java Specification Request)
Java ライブラリに手を入れる(あるいは JVM 自体を変更する) 作業の中心は，Java 仕様要求(Java Specification Request) あるいは JSR から始まる。JSR にはそれぞれに通番が割り当てられていて，古いものほど小さな番号を持っている。最古のものは JSR1: Realtime Java であり，オリジナルの提案から決定までに８年程度を要している。ただし，すべての JSR が完結しているわけではない。JSR2: Boundary API は１年と経たずに取り下げられているし，JSR3: Java Management eXtension は約１年後に変更された。JSR すべて のリストがこちらにある (状態別に参照することも可能)。
JSR には明確な目的，チームリーダあるいは企業による支援，そして作業進行上のさまざまな賛否を議論する “専門家グループ” の構成が必要である。JSR の中には，別の JSR の単なる焼き直しもある。Java EE JSR などは，その大部分が他の JSR ( Servlet や JSP などを個々に定義したもの) への参照で占められている。Java TCK の入手に対して異議を唱え続けられている Apache 財団は，Java EE 6 など最近のエンタープライズ仕様に対して反対票を投じる行動を継続している - ただしTCK 提供に拒否票を投じた JCP 理事は，最終的には Sun だけだった。
Java 仕様要求を作成するには，実に多くの 事前計画手順 に従わなければならない。
- インスタンス化(Instantiation)。新規仕様を作成 (テンプレートが用意されている) して，審議を受けるために提出する。
- 初期ドラフトレビュー(Early Draft Review)。専門家グループが招集され，初期ドラフト仕様の完成作業に着手する。
- 公開ドラフト(Public Draft)。インターネットにアクセス可能であれば誰でも仕様を参照し，コメントすることができる。
- 最終承認(Final Approval)。執行委員会によって仕様投票が実施される。承認されれば JSR として受理される。
さらに JCP には厳格なタイムラインがある。各ステージには 30 から 90 日の範囲で，完了までのタイムラインを設定しなければならない。その後に数回のクーリングオフ期間がある。投票を実施したり (完了に数週間を要する) プロセスの進行について検討するにはいい機会だ。ところが Bob Lee 氏は昨年，Java へのアノテーション導入という野心的目標を持った JSR 330:Dependency Injection for Java を Java EE 6 仕様に先立って，５ヶ月足らずの間 に提出したのだ。
注意していなかったら見逃しているかも知れません。JSR 330，Java 依存性注入 (Dependency Injection for Java) は，Java 仕様要求として最短の開発サイクルで完了し，Java Community Process (JCP) プログラムにおける新記録を達成しました。Bob Lee 氏が今回実現するまでは，机上の空論とさえ思われていた快挙です。しかし JSR 330 の仕様リーダのひとりとして事を進める上で，Bob が特にアジリティ(敏捷性)を求めていたのではありません。“JSR 330 が迅速に実行されたことはうれしいのですが，それよりも私は，この仕様のクオリティを誇りに思っています。私たちはバーを上げたのです。” と氏は話しています。
Bob ともうひとりの仕様リーダである Rod Johnson 氏は，依存性注入に関わるコミュニティ全体の中から代表を選出して，JSR 330 専門家グループに参加させました。開発を早く進めるため，グループを小規模にまとめたのです。さらに公開メーリングリストを用意することで，公式な専門家グループに対して希望者全員の参加を求める圧力を回避しました。仕様リーダ以外の専門家の参加は，組織あたり１名に限定されました。
少数精鋭の専門家グループ組織と幅広く公開されたメーリングリストを用意することで，初期レビューとドラフトレビューを共に排除し，理論的な制限時間を短縮することができた。オープン性とアジャイル性の維持に加えて，ドキュメント管理にバージョン管理システムを導入したことで，大量の変更履歴資料を要せすに変更過程を理解可能にしたことも特筆すべき点だ。
さらに閉ざされた専門家グループには，発生した問題を公開して共同で対処する前に，専門家グループが協調して問題を解決できる利点もあった。多数の参加者によって意見が分散する事態を回避する上でも，グループの分離は不可欠だ。
最後に，JSR 330 で標準ライセンスを使用したことは，JSR の新たなアプローチの先駆けになった。それは手詰まりの産物と言っていいだろう。
例えば専門家グループと Sun の関係は，何よりも仕様ライセンスに関する問題で行き詰まりに達しています。専門家グループはリファレンス実装 (Reference Implementation，RI) や技術互換性キット (Technology Compatibility Kit，TCK) と同じように，広く認知されている Apache ライセンスの使用を希望していました。"JSR 330 だけではなく，今後の JSR 仕様にも Apache ライセンスを用いるべきだ，と私は強く主張しました。" と Bob は言っています。それに対して Sunは，TCK を通過していない実装に対して専門家グループの知的財産(IP)をライセンスする行為は JSPA の 5.B 章で禁止されているものだ，と主張しています。
最終的に RI と TCK がデュアルライセンス下で公開され，JSPA に加えて Apache ライセンスにも従うことになったのは周知のとおりである。
JCP は消滅するのだろうか？
JCP がこれまでのような独立した組織として存続するのか，あるいは独立した団体としてスピンオフされるのか，現時点では何も発表されていない。Oracle による Sun 買収以前には，中立性を高めるため JCP は広く (Eclipse や Apache 財団などに) 募集されていた。Oracle 自身も含まれていたのだ。しかし優位な立場になった (さらに重要なのは JCP の拒否権を持っていることだ) Oracle が，今でも以前と同じ意見を持っているとは考えにくい。
すでに崩壊してしまったコミュニティもある。OpenSolaris コミュニティは消滅し，理事会のメンバは辞任した。同じことが JCP にも起きるだろうか？ JCP の現状を維持するのか，あるいは何らかの方法で再構築するのか (あるいは完全に破棄するのか) に関して，Oracle は何ら計画を持っていない - Eclipse 財団のマーケティングディレクタである Ian Skerrett 氏は，確かにそう願っている。
しかしオープンソースコミュニティの構築や JCP の改革に関しては，何の言及もありませんでした。私の印象では，Oracle はソフトウェアベンダとして行動し，オープンソースを自社製品の改善に利用しつつ，強力な管理権限を維持しようとするように思われます。
筆者は無論，独立したベンダ中立なオープンソースコミュニティの存在を強く信じている。だからこれには失望を禁じえない。しかしながら，どのような体制にあっても Java は発展を続けるだろう。
JCP が今後どうなるかは，時が明らかにしてくれるだろう。舞台裏での交渉の噂は絶えないが，ドアの向こうですべてが決定されるまで，ニュースとしては何も出てこないようだ。
Thomas Kurian 氏 [Oracle サーバ技術リーダ] が JavaOne でプレスに対して語ったところによると，Oracle は実行委員会と協議中であり，JCP の今後に関して数多くの提案を行っている，ということです。提案の内容について，Kurian 氏は明らかにしませんでした。"解決策を得るまでは公式発表は行わない予定である"，と氏は語っています。