Eclipse Foundation は先週 Eclipse 4.0 アーリーアダプタ SDK をリリースした。ただし実用レベルの Eclipse Helios リリース (別名 Eclipse 3.6) と混同してはならない。今回のリリースはむしろ，将来の Eclipse の姿を垣間見せるためのものなのだ。
次回の Eclipse 同期リリース (コードネーム Indigo，あるいは Eclipse 3.7) は，これまでと同じ現行の 3.x コードストリームがベースになる予定である。4.1 ストリームビルドが準備されているにもかかわらずだ。ではなぜ今年のリリースと来年のリリースという，２つの公開バージョンをメンテナンスするのだろう？プロジェクトのページ では次のように説明されている。
Eclipse SDK 4.0 は，Eclipse ベースのツール，リッチクライアント，あるいはデスクトップアプリケーションを構築するための次世代プラットフォームです。新リリースでは Eclipse プラットフォームをベースとするアプリケーションやツールの開発と構築が，これまでより容易になっています。
今回の 4.0 リリースは下位互換性の確認，あるいはプラグインや RCP アプリケーションのマイグレーションを希望するアーリーアダプタを対象としたものです。Eclipse エンドユーザには，今後リリースされる Eclipse 4.x を採用して頂きたいと思います。
Eclipse 4.0 (以前は E4 と呼ばれていた) の開発期間は２年に及んでいるが，その間に公開されたリリースは 2009年7月の E4 0.9 のみだ。最初の E4 ホワイトペーパー には，Eclipse プラットフォーム自体を再考する必要性と，その背景となる考えに関する記述がある。その中で Eclipse 4.0 は，Eclipse ベース製品の第３世代プラットフォームである，と説明されている。
- 第１世代：Eclipse 1.0 から 2.1 まで。"本質的には統合プラットフォームであり，多くの作者による多様なプラグインを取りまとめ，一貫性と統一性のあるエンドユーザエクスペリエンスを備えた共通アプリケーションに統合することを主な強みとしていた。"
- 第２世代：Eclipse 3.x。"OSGi ランタイム搭載によってさらに強力な多目的コンポーネントベースアプリケーションとなり，ごく小さな組込アプリケーションから，大規模なリッチクライアントアプリケーションや Web サービスにまでスケールする。"
- 第３世代：Eclipse 4.x。"外部依存性と前提条件の低減によって，さらに多くの言語や技術をシームレスに統合可能とする。より広範囲のアプリケーションと環境に対応し，再利用性とカスタマイズ性をさらに高めたコンポーネントを容易に記述できるようになる。"
OSGi が Eclipse アプリケーションにとって大いに役立っている反面，大多数の Eclipse アプリケーションが OSGi アプリケーションとしてはあまりよく機能しない。これは主に歴史的な理由によるものだ。OSGi 対応以前の Eclipse には 神オブジェクト (God Object) としてふるまうシングルトンが数多く (Platform， PlatformUI，そして IDE) あった。これはオブジェクト指向的にアンチパターンであるだけでなく，OSGi の (動的な) サービスに対しても都合が悪い。
Eclipse 4.0 でこの問題を改善する方法のひとつが依存性注入 (Dependency Injection，別名 DI) である。これは Spring などのツールによって一般的になった，サービスをオンデマンドで有効にする手法だ。javax.inject アノテーションと OSGi の宣言型サービス (Declaretive Service，別名 DS) を組み合わせて使用すれば，次の例のように，依存性注入によって E4 や OSGi のサービスを自動的にコードに提供することさえ可能になる。
import javax.inject.Inject;
import org.eclipse.e4.core.services.Logger;
import org.osgi.service.packageadmin.PackageAdmin;
public class Example {
@Inject private Logger logger;
@Inject private PackageAdmin packageAdmin;
}
Eclipse 4.0プラットフォームは，サービスを使用する外部コードからのコントロールによって，サービスの注入処理を自動的に実行する （操作の必要がないサービスについては @Optional のようにマークしておくことも可能)。このため OSGi コンポーネント化されたサービスベースのアプリケーションにコンポーネントを統合する作業は，非常に容易なものになるだろう。現在，Eclipse アプリケーションサービス 案のリストが公開されている。
その他 Eclipse 4.0 の重要な変更として，UI 構築方法に関するものがある。Eclipse 3.x のユーザーインターフェイスの作成は定型的で，SWT (あるいは JFace) ウィジェットを生成してスクリーンに配置する，という処理を手書きで記述する。プラットフォーム固有のパフォーマンスと動作という点で SWT が Swing ベースのインターフェースより優れていることは間違いない。しかしこのツールキットの使用には，歴史的な理由による不安部分があった。システムリソースを開放するため終了時に dispose( ) のコールが必要である，というのはそのひとつだ。別に難しいことではないが，Java プログラムでは一般的な方法ではないため，これによるリークは珍しくない。しかも Eclipse のようなホスト環境においては，たったひとつのプラグインのリークが原因でシステムが停止する場合もあり得る。この種のリークを発見するためのツール (sleak など) も存在するが，心配の必要がなくなるに越したことはない。
先日 Google に買収された Instantiations には Window Builder Pro という製品があった。Eclipse Community Award も受賞 しているこの製品 は，RCP Designer との併用でドラッグ・アンド・ドロップによるユーザインターフェース作成を実現するものだ。コードを手書きするよりはるかに容易なだけでなく，メモリ処理を生成コード内で管理することで，プログラマがメモリ管理を心配する必要がなくなる，という利点もある。しかし先般の買収のため，これらの製品はもはや入手できない - それでも GWT blog によれば，数ヶ月内に GWT Designer として発表されることが期待できそうだ。
このことは Eclipse 4.x にどのように影響するだろうか？それはさておき，他にも重要な変更として，宣言ベースのユーザインタフェースの開発がある。HTML の UI は命令ではなく宣言で構成されているが，Eclipse 4.x のユーザインターフェースもこれと同じように，XAML あるいは XUL に似た形式で指定するようになる。これにはメンテナンスの容易化だけでなく，レンダリングエンジンが UI ウィジェットの構築を - そして破棄も - 管理するようになる，という利点もある。最終的には表示処理要求も外部化することによって，アプリケーションのテーマ設定をコード外部から行うことも考えられる。
HTML 的な手法に加えて，UI の外観指定には CSS の使用も可能である。フロントエンドを Web ベースにすることには，単一の定義から異なったスタイルのユーザインターフェースを生成するというシンプルな方法で，デスクトップインターフェースとの緊密な一致性を得ることができるメリットもある。
この機能の大部分は，アプリケーションやビュー，サービスなどを Eclipse Modeling Framework (EMF) を通じてオブジェクト化することで実現されている。UI の記述には，モデル化されたウィジェットとビューを使用する。JavaScript で Web ページの DOM を扱う要領で，モデルをあらかじめ作成しておいたり，実行時に生成，参照，操作したりすることも可能だ。
Ian Skerett 氏が記しているように，これはプラットフォームの新たな旅の始まりである。Eclipse 4.0 はアーリーアダプタ向けではある (そして既知の問題もある) が，その目標は Eclipse 3.0 のプラグインを，可能な限り少ない変更で Eclipse 4.0 にマイグレーション可能とすることにある。Mike Wilson 氏は Eclipse 4.0 の重要な点についての EclipseZone のインタビュー に答えている。また Lars Vogel，Tom Schindl 両氏は，それぞれのチュートリアルを公開している。