ここ1,2週間，Java の世界では多くの事が起きている。Oracle は沈黙を守り続けているが，その静かさには耳が痛いほどだ。
事の起こりは IBM の OpenJDK への参加 と Harmony の (事実上の) 解散だった。JVM の一方が落ち，一方は続くことになる。Apache ソフトウェア財団 (Apache Software Foundation) の理事会は後に，IBM のこれまでの協力に感謝するとともに，他の貢献者による Harmony の継続を強く望む，とする 見解を発表している。
これに対して各方面からの反応があった。Eclipse の Mike Milinkovich 氏は，自身らが最終的に Java 7 を採用するに至った見解 を寄せている。その一方で，既存のデファクト標準とモジュール化層での整合性を確保するため，現状の Java 8 提案には再考を要する，とする立場も表明している。
JCP を詳細に調査した Stephen Colebourne 氏は当初，Java SE コンポーネントが JCP における投票による決定よりも，むしろ Oracle が単独でコントロールする部分が大きいことを明確にするために，JCP を２つに分割すること を提案していた。しかし後になって，古くからの顧客である Hologic を JCP 理事に迎えることで Oracle が票の水増しを行っている，と主張している。Hologic という名前は，Java コミュニティの大部分が始めて耳にするものだ。他に Oracle が推薦したのは Apache と Red Hat であり，それ以外の再選候補には Google と Eclipse がある。
Doug Lea 氏の JCP からの離脱に関して，Stephen はむしろそれを認める立場だったが，もっともダメージを受けたのは恐らく Douq が JCP を離れる理由に関する氏の発言 だろう。
JCP は仕様標準化団体として信頼できるものではなく，EC の学術研究コミュニティが独立した支持者として担うべき役割は残っていない，と考えています。
氏の見解によると，JCP は本来 Java のプラットフォームとエコシステムの進歩を持ち寄る，アイデアとコラボレーションのるつぼを目指すものだった。しかし今日，Java 開発者たちが利用するツールの多くは JCP を経由していない。例えば Servlet は後になって JCP に加えられたが，当初は外部で設計されたものだった。依存性注入を一般的なものにした Spring はコミュニティが開発主体だ。Apache は主要なオープンソース Java ツールセットを現在もホストしている。彼らのデファクト Java ビルドツールである Ant と Maven はいずれも JCP 標準でないが，開発では日常的に利用されている。テスト用フレームワークのデファクト標準である JUnit も (あるいは知名度では劣るものの，機能は確実に上である TestNG も)，JSR を目指したことはない。そして同じくらい確実なのは，JSR が生み出したものが多くの面で凡庸であることだ。Logging API for Java を嫌って，代わりに Commons Logging か，あるいは同じ API を使った互換性レイヤを採用する例は数多い。(Apache Commons が存在するということ自体，標準重視の開発が汎用ユーティリティライブラリを見落とすミスを犯しやすい，という事実を裏付けている。) Doug は JCP を，Orcale による形だけの組織以外の何物でもない，と評している。
ルールを変更したり違反行為を止めるのではなく，Oracle は今，単にそれらを無視しようとしているのです。彼らが本当にそのとおり行動するなら，JCP は Oracle が支援する構想の承認団体以上の存在には二度となり得ないでしょう。
何らかの取り組みのために，他のグループ／組織／団体で行われるような，提案仕様へのコンセンサスを進める目的で JCP JSR プロセスを使用することは，私には推奨できません。いっそのこと私は，提案の数がもっと少なくなって，JCP よりもよい場所があることに人々が気付いてくれないかと思っているのです。
Neil Bartlett 氏は，JCP よりもよい Java 標準化団体はすでに存在する，と指摘している。
しかし Java の世界にも，信頼に値する仕様標準化団体が存在するのです。ここではそれ [OSGi] を活動と呼ぶに留めたいと思いますが，その優れた特徴についていくつか指摘しておきます。
- 素晴らしい品質の仕様を策定していること。
- 競合企業同士がコラボレーションする場として， 10年以上にわたって効果的に機能していること。
- Oracle が非常に活発なメンバであるが，それを所有してはいないこと。すべてのメンバは確実に同じ権限を持っている。
- すべての仕様が公開され，メンバからの特許非係争誓約がなされていること。
- TCK (Test Compatibility Kit/互換性テストキット)が無償利用可能なオープンソースプロジェクトである上に，RI (Reference Implementation/参照実装) の大半もすでにオープンソースであること。
この状況の中，Oracle は沈黙を守り続けている。あるいは11月1日の立候補締め切り後に投票される JCP 選挙の結果を待って，公式な回答をするつもりなのかも知れない。一方で Eclipse 財団 (Eclipse Foundation) の Ian Skerrett 氏は，Oracle はコミュニティを顧客として以外の方法で扱うやり方の 手がかりを必要としている，と受け止めている。
言いたくないことですが，あなた方には Java コミュニティの援助が必要です。根本的な問題は，人々があなた方を信用していないこと，あなた方がコミュニティ構築を苦手としていることなのです。事実，あなた方はコミュニティマーケティングが上手ではありません。
たくさんの人々が Java を話題にする一方で，あなた方は空虚な沈黙を続けています。対話が行われているのにあなた方が参加しないので，人々は憶測と仮説を重ねています。これは信頼を構築する上で望ましいことではありません。
このことは，Apple が Mac プラットフォームで Java を廃止予定にしたために表面化している。自社オペレーティングシステムの現行ないし将来のバージョンにおいて，Apple がJava を非推奨とする，と強く示唆した件である (同社は Flash を同梱しない，という事をすでに実行している)。 Steve Jobs 氏のものとされる電子メールには，Apple が JVM を出荷するのは最善の方法ではない，と記されている。他のプレイヤ(Oracle など)が行うのがより望ましい，という趣旨の主張だ。Apple のディスプレイパイプラインの緊密な統合と先日リリースされた高速シャットダウンのフックは，プラットフォーム外のプログラムによって阻害される可能性がある，と考える者は多い。
Mac プラットフォームが Java を失ったとしても，Oracle がそれを気にしない可能性はもちろんある。クライアント上の Java アプリケーションはもともと相対的に数が少ないし，Mac OSX をサーバにしようとする Apple の努力に反するような，Apple の伝説的な秘密性や非公開のハードウェアロードマップなどは，大部分のサーバベースの購買要求に適合しないものなのだ。Oracle も同社のデータベース製品を Mac 向けには出荷していない。ただしツールのいくつかは Eclipse ベースであるため，(今のところは) OSX 上でも動作する。
理由が何であれ，Oracle がこの問題に対して沈黙を保つことは，同社にとって何の役にも立たない。Doug Lea 氏の JCP に対する罵倒と Ian のコメントを考え合わせると，Oracle は Java プラットフォームをコントロールしているが Java コミュニティとのコネクションを失っている，とも言える。さらに OSX はマイナーなプラットフォームである (Eclipse サイト訪問者の 10% 未満に過ぎない) とはいえ，Apple はテクノロジリーダであり，技術が陳腐化を始めたときに枯れ木を切る役 (フロッピドライブ，パラレルポート，そして現在は組み込み光学ドライブとハードドライブ) として認められているのだ。
私たちは Oracle にコメントを求めたが，彼らはその呼びかけを辞退している。
Oracle は自身と JCP の間に何が起こっているのかを明らかにし，OSX から Java が削除される件についてコメントする必要がある。現在ならばまだ態度を変えることができる。沈黙は自身を不利にするだけだ。Oracle は Java の権利を買収したのかも知れないが，Java コミュニティをも手中にした訳ではないのだから。