先週Eclipse財団は、この夏の複合リリースに向けたマイルストーンであるEclipse Juno M5のリリースをアナウンスした。これでは、潜在的なnullポインターの逆参照と (Java7はリソースのクリーンアップが可能なtry、Java6は標準的なtry/catchハンドリングの両方で)リソースのリークのような新しい機能を提供する。
最初は、E4をベースにした複合Eclipseでリリースされる。ここで重要なのは、Eclipse UIインフラがコードの代わりに、EMFベースの宣言型モデルで書き直されたことである。モデルは、実行時に変更することができ、必要な時にビューステートが保存される自動永続化が提供され、変更がウィンドウ内で即座に描画される。
ユーザーインターフェイスで宣言モデルを使う大きな利点は、ユーザーインターフェイスの機構を表示から切り離すことができることである。ユーザーインターフェイスのスタイルにCSSを使うことが可能で、コードのユーザーインターフェイスコンポーネントをマニュアルで管理する必要がなく、破棄されていないリソースによるメモリリークも回避した。
その他のE4の改善は、必要なサービスの取得に依存性注入を使用することである。以前は、(他のビューに切り替えたときに情報を提供するSelectionServiceのような)頻繁に使われるプラットフォームサービスで静的アクセサが使われていた。このサービスは、Eclipseプラットフォームのリリース当初から提供されていたが、Eclipse 3.0でOSGiランタイムに移行したにもかかわらず、サービスはOSGiサービスとして公開されていなかった。E4では、これらのベースプラットフォームサービスは、OSGiサービスとして提供されており、EclipseとOSGiクライアントの両方から利用することができる。
一般的にシングルトンのサービス– ワークベンチ選択サービス、ロギングサービスなど– の取得を容易にするために、Eclipseプラグインは、必要なサービスに注入ポイントを宣言することができる。E4では、プラグインの開始と読み込み時にどのサービスが必要かを決定して、実行中のプラットフォーム上でそれらを接続する。これは、Springを使ったことがある人にはなじみのあるモデルだが、代わりに、それが実行されているプラットフォームのコンテンツをベースとしたApplication Contextの設定が必要である。注入は、per-fieldやper-method呼び出しを基本として、標準のjavax.inject.Injectアノテーションで完結している。
サービスを探すメカニズムについては、以前のEclipse 3とEclipse 4の間で大幅に変更されているが、下位互換レイヤは古い環境を対象にした同じAPIを提供する。APIは以前の実装を完全に置き換えており、早期バージョンには現在のバージョンには存在しないバグや機能が含まれていることに注意が必要である。
E4への移行は徐々にひとつになっている。SDK 4.0の最初のリリースは、3.6 Heliosの後であり、Eclipse開発者向けの改良版SDK 4.1は、3.7Indigoリリースの後にリリースされた。まもなくリリースされるJunoは、最終版の3.8ビルドが存在しているが、4.2プラットフォームに移行することが期待されている。
しかしながら、Eclipseプロジェクトは長年にわたって徴収している。Eclipseプラットフォームは、もともとIBMによって開始しており、IBM社員によって常に重視されている。ダッシュボードには、多くのIBMと元IBMメンバー、そして少数の外部コミッターがリストされている。クロスプロジェクトリストへのEメールにおいて、Mike Wilson氏 (EclipseプロジェクトのPMC)は、親会社による自然減によってプラットフォームUIプロジェクトの開発者が残り3人になってしまったことを協調した。 これにより、4.2がJunoに間に合うかどうかの懸念が広まった:しかし、Mike氏は、これを遅らせることは、“私たちのコミュニティの崩壊”に繋がると主張している:
単純にJunoには3.8をリリースして、4.xの波は次のリリースに回せばよいと考えるかもしれません。実際の所、これは私たちのコミュニティを崩壊させることになります。Junoとの同時リリースは、Eclipseのはじめての長期サポートと、超長期サポートの両方を提供する基礎になるでしょう。加えて、Eclipse全体の成熟度と、参加している大規模な組織の要求は、Junoリリースに取って非常に重要になります。もし私たちがJunoで4.2を提供できなかった場合、コミュニティの大部分はそれが提供する新しい機能を利用することができなくなりますが、それよりも重要なのは、私たちが置き換える必要があると思っているコードベースを使って、彼らが開発を進めてしまうことです。結局の所、それは4.xの作業を始める原動力でした。これは文字通り、(私たちが構築するための)プラットフォームが、デスクトップアプリケーションとして、最新のニーズに対応するために変更することができない可能性があることを意味しています。そしてこれは、デスクトップ上のEclipseの将来を危うくしています。
彼は、少なくてもコミッタ－の面では、単一企業がEclipseプロジェクトのスポンサーであることが問題であるという認識がある:
最後に、EclipseプラットフォームUIチームのすべてと、Eclipseプロジェクト全体で、さらにIBM以外のコミッターが*必要*であることは明かです。そして、さらに*アクティブに* "SDKに取り組むことは、コミュニティに取っての利益"になります。Eclipseプロジェクトの多様性の欠如に関する主張は、古巣に帰ることに繋がります: IBMのEclipseコミッタ－は、SDK全体をサポートするには少なすぎることが明らかになりました。
Eclipse財団のエバンジェリストであるWayne Beaton氏は、オープンプロジェクトでベンダー中立なのは、本質ではないと考えているが、Eclipseの規約が必要であると考えている:
Eclipse技術は、オープン開発プラットフォームで、フレームワークと、模範的で拡張可能なツール(“Eclipseプラットフォーム”)をベンダーに中立に提供しています。
最後にEclipse財団は、来年のリリース名は、Eclipse Keplerにすることを決定した。以前にKeplerという名前のプロジェクトが提案されたが、プロジェクトが軌道に乗ることなくアーカイブされ、直後にこれが提案された。Eclipse Keplerは、Eclipse 4.3上に構築され、2013年の夏に登場する予定である。