先週報告したとおり，Oracle は Java 6u21 のブランド変更に関する問題に迅速に対応した。Java インストーラの再設計によって Windows マシン用の最新リリースビルドは 1.6.0_21-b07 になった。問題が影響するのは Windows のみであるため，Solaris 用と Linux 用はバージョン 1.6.0_21-b06 のままだ。
この問題に対する Oracle の素早い対応と解決は賞賛に値する。Eclipse のランチャーが非サポート API を使ってベンダを検出していたのが原因なのだから，本来 Oracle には解決する義務はない。それでも幸運なことに Oracle は，Eclipse がビルドを再設計するよりもずっと早く，この問題に対応することができた。Eclipse Foundation のマーケティングディレクタである Ian Skerrett氏はその状況を， "Oracle は Eclipse の修正において，素晴らしいコミュニティサポートを実演してみせた" という見出しで完璧に要約した。
残念なのは，Ed Burnette 氏が ZDNet ブログにおいて，もっと批判的な "Oracle の Java ブランド変更が Eclipse を破損した" というタイトルを使用して，これが Slashdot で繰り返し取り上げられたことだ。皮肉なことに，Ed のブログポストの内容では，(月曜日にリリースされた)フィックスによって問題が解決したことが実証されていた - しかし Twitter の 140 文字という制限のため，タイトルが Ed のポストを指し示すただひとつのメッセージになってしまったのだ。
Twitter などソーシャルネットワークの出現による情報展開の加速を示すこのエピソードには，いくつもの教訓が含まれている。
- 一見して無害なものでも，連鎖反応(knock-on effecr)を持つようになる場合がある。今回のような事態を JVM チームが予見することは，現実的には不可能だった。また Eclipse チームも，このようなブランド変更が起きるとは知るすべがなかった。しかしながら，"誰にも危害は加えないだろう" と思った小さな波及効果でさえ，予期せぬ結果をもたらすことがあるのだ。この件に関する最大のアドバイスは，マイナーリリースはバグフィックスのみに限定すること，不要な変更は次のバージョンへ回すこと，の２つだ。
- 見出しは、コンテンツよりも多く繰り返される 。とりわけ Twitter においては，内容すべてが見出しと言っても過言ではない。ひとたび見出しを参照して "つぶやく (tweet this)" ボタンを (ZDNet がやったように) 押したならば，それが内容そのものよりも早く広まることになる。内容を読まずにタイトルだけで推測する人も現れるだろう。
- ブランド変更は，いずれ JDK7で行われる。Oracle は多くの資金を使って Java の 権利を取得したのだから，JDK7 がリリースされたときには，当然ブランド名を変更するだろう。今回の件はその前触れと理解すべきだ。
- これは Eclipse Helios リリースだけの問題ではない。問題の発端は，この探索処理が取り入れられた Eclipse 3.3 の時点までさかのぼる。Eclipse のすべてのバージョンがこの問題に影響されるにも関わらず，フィックスが予定されているのは Eclipse Helios だけなのだ。
- Eclipse は単なる IDE ではなく，プラットフォームだ。したがって影響を受けるのは，最新かつ最大の JDT だけではない (いずれにしても，開発者はツールの更新に対する反応が早いものだ)。Eclipse には派生 IDE や，それをベースとする市販アプリケーションがたくさんある。IBM はツールの全スイートがそうであるし，Windriver や Oracle 自身も所有している。彼らの製品ロードマップは，Eclipse のリリーストレイン自体に丸一年遅れている場合もある。さらにこれらの企業は，Eclipse Foundation とその開発者にとってのスポンサーでもあるのだ。"使い続けるためには，最新のものにアップグレードしなければならない" と言うのでは恐喝も同然だ。
この変更に対する Eclipse の対応は後手に回っている。Oracle の迅速な発想とコミュニティ精神を持った対応がなかったならば，Eclipse 派生プロダクト (プラットフォームあるいは IDE) の開発者すべてが影響を受けていたことだろう。Eclipse がリリース手法として同期リリーストレインを毎年実施するようになってから，この６年の間は緊急の問題に対処する必要がなかった，という指摘もある。５番目あるいは６番目のマイルストンにおいて問題点をすべて解決してきた，というのだ (ただし Eclipse m5a あるいは m6a の再設計が必要になったことは度々あった)。それでも９月に計画されている 3.6.1 リリースでは，今回の問題への対応としてはあまりにも遅すぎる。Galileo の (最も早い場合で) 3.5.3 リリースでも同じことだ。立ち上げ直後に発覚した重大なバグに対処しなくてならない，という状況は，Eclipse にとっては未知の新領域である。自らには原因がないとしても，速やかに対応可能な立場であることが，ソフトウェア開発者としての彼らの責任の証明に他ならない。Microsoft の "火曜日パッチ" の批判者は，緊急性のあるパッチを次のリリーススケジュールまで残すのは容認しがたい，と言う。Eclipse のリリース手順についても同じことだ。
Oracle は当面の障害解決への対処では柔軟性を見せたものの，問題は解決せずに先送りされたままだ。最新の IDE 利用者のみならず，問題の生じるプラットフォーム上にソフトウェアを構築した開発者に対して，今後この問題を解決する責任があるのは Eclipse だ。