Eclipse（「イクリプス」または「エクリプス」）は、IBMによって開発された統合開発環境 (IDE) の一つ。高機能ながらオープンソースであり、Javaをはじめとするいくつかの言語に対応する。Eclipse自体はJavaで記述されている。名称のEclipseとは「食（蝕）」の意の英語で、日食や月食を指すが、Javaを開発した米Sun Microsystems（太陽）とは無関係である。Eclipseの歴史は1990年代後半から始まる。当時の状況は、JBuilder、、そしてIBMのVisualAge、PFUのteikadeなど第1世代のJava開発ツールが存在している。IBMは様々なプラットフォームの製品を抱えていることから、Javaのマルチプラットフォームの可能性に注目していた。単なるVisualAgeの代替ではなく、IBMや他社のツールを統合するための共通プラットフォームの開発という基本構想の下、1998年11月にIBMカナダでプロジェクトが開始された。開発に携わったのは、VisualAgeの開発を行ったObject Technology International (OTI) 研究所である。その後、IBMはこのプラットフォームに搭載するツールの開発のために組織の編成を行い、さらにオープンソース化することで新しい開発者の引き込みを図った。2001年11月、IBMはEclipseをオープンソース化するとともに、他の組織 (ボーランド、、QNX Software Systems、ラショナルソフトウェア、レッドハット、SuSE、、) と共同で初期のEclipse.orgであるEclipse Board of Stewardsを設立する。公開されたEclipseはたちまちのうちに多くの開発者の興味を惹くこととなった。また、2003年の終わりには、Eclipse Board of Stewardsの参加メンバーも80を越えている。しかし爆発的人気の影で、Eclipseは、IBM以外の他団体から新たなツールが提供されないという問題を抱えていた。それは、IBMがEclipseの制御権を握っているという認識によるものであった。Eclipseの勢いを止めないために、IBMとEclipseを切り離すことが必要とされた。2004年2月2日、Eclipse Board of Stewardsは、Eclipse組織の再構築を発表した。非営利組織Eclipse Foundationの結成と、Eclipseの全てをEclipse Foundationに移管することで、全ての団体や開発者を対等に扱うこととなった。このEclipse Foundationから、Eclipse 3.0、3.1、3.2がリリースされている。現在Eclipse Foundationは、115以上のメンバー企業、50以上のサブプロジェクトを抱えるオープンソース組織に成長している。2006年、Eclipse Foundationは、Eclipse 3.2に10のオープンソースプロジェクトを合わせたリリースを行った。この製品は、Eclipse Callistoと呼ばれている。現在では毎年6月に同時リリース (Simultaneous Release)、その後9月と2月にそれぞれSR1とSR2 (Service Release) が行われている。同時リリースにはコードネームが付与されており、3.4まではガリレオ衛星に因んだ名が付けられていたが、3.5で予定されていたIoはI/Oと誤認されるおそれがあるため、ガリレオ衛星発見者のガリレオ・ガリレイよりとった名称であるGalileoへと変更された。また、2010年リリースの3.6はHelios（ギリシア神話の太陽神であるヘーリオス）と名付けられている。なお、Galileoからは頭文字がアルファベット順となるような名称が投票で選ばれている。Eclipse 3.8は存在するが、3.7のバグフィクス版であること、すでに4.2のリリースが決まっていたことなどからWeb上では公表されていない。Googleは2015年6月に、Androidのアプリ開発を助けるプラグインであるADT (Android Development Tools) プラグインの開発とサポートを2015年末で終了しており 、Androidアプリの統合開発環境に関しては、EclipseからIntelliJ IDEAベースのAndroid Studioへ移行された。Eclipseの主な機能は以下のとおり。機能統合環境にプラグインとしてさまざまな機能を組み込むことができるよう設計されている。その拡張性は非常に高く、Java開発環境自体が標準添付のプラグインとして実装されているほどであり、プラグイン次第でC++やPHP、Perl、C#、D言語、TeX、Python、Ruby、JavaScript、COBOL、AspectJ、Mathematica など多様な言語への対応が可能となっている。プラグインはJavaで記述され、プラグイン開発環境自体もEclipseに標準で付属している。これは、Emacsがその主要機能を搭載したLISP言語で記述できることと対比できる。LISPの代わりにJavaを用いるEmacsのようなものなのだと例えられることもある。Eclipse 3.0より、プラグインの機構にはOSGiフレームワークの実装であるEquinoxを採用している（Equinox自身もEclipse Foundationの傘下にあるサブプロジェクトである）。このため、EclipseプラグインはOSGiフレームワークに規定されているbundle形式で配布される。この機構はEclipse RCP (Rich Client Platform) においても同様である。主なプラグインは後述する。EclipseにはJava Debug Interface (JDI) を用いたグラフィカルデバッガが含まれている。バージョン管理システムのCVSやSubversion、git等を使ってソースコード管理を行うことができる。EclipseのCVS機能はコマンドラインのCVSコマンドを呼び出すフロントエンドとして動作するのではなく、自前のコードで直接CVSサーバと通信する（ssh、pserverの両方が利用可能）。Javaソースコードから、JUnitテストコードの自動生成、テスト実行を行うことができる。Eclipse 3.2からは、Java SE 5のアノテーションに対応したJUnit 4を使うことが可能になった。ビルドシステムAntと連携できる。Antは、Unix系のコマンドmakeを置き換えるプログラムで、Makefileに相当する各ソースコードの依存関係をXMLにより記述する。Antは、Javaで書かれており、ウェブサーバで知られるApache Software Foundationプロジェクトで開発されている。EclipseはAntをデフォルトで同梱している。getter, setterメソッドの自動生成や、try-catchの自動追加、による文字列の外部化、クラス名・メソッド名・変数名の変更（それを参照している部分も自動的に書き換わる）、メソッドの移動や抽出などをウィザード形式で行ってくれる。クラス名・メソッド名・変数名の補完や、import文の整理・自動生成、必要なthrows節の自動追加、必要なメソッドスケルトンの自動生成などさまざまな編集支援機能を持つ。JavaDevelopmentToolsに使用されているEclipse独自のJavaコンパイラ。この為EclipseはJDKが無くてもJavaファイルのコンパイルが可能である。Eclipseは他のJavaで記述されたIDE（JBuilderやSun ONE Studioなど）と比べて動作があきらかに軽快である。この軽快さはGUIツールキットにJava標準のSwingやAWT (Abstract Window Toolkit) を使用せず、Eclipse独自のGUIツールキットであるSWT (Standard Widget Toolkit) を採用していることで得られている。SWTの位置づけはSwingではなくAWTに対応するが、AWTとSWTの違いは、AWTがオペレーティングシステム (OS) あるいはウィンドウシステムレベルの描画操作をネイティブメソッド群というレイヤ（つまりCあるいはC++で書かれたJNIメソッドのDLL・共有ライブラリエントリ）で抽象化し、それをさらにJavaのAPIで覆い、インタフェースが二重に重ねられているのに比べ、SWTではネイティブのウィンドウシステムのAPIとJNIメソッドがほぼ一対一に対応するように定義されており、JNIの層が量的・質的に非常に薄い、ということである。言い換えると、ネイティブのウィンドウシステムのAPIレイヤと、JavaのGUIツールキットクラスライブラリとしてのレイヤの間のセマンティックギャップを埋めるのに、AWTではCコードとJavaコードの両方を使用するのに対して、SWTではCの部分が僅少でありJavaコードが実質的に主体である。AWTにおいて、下位層のウィンドウシステムのAPIをOSを越えて共通のものにみせかけるための、DLLのエントリとして定義されるインターフェース層は、積極的な存在意義が無く、見通しを悪くしており、2回のセマンティクス変換が効率を悪くする可能性があり、柔軟性にかけ、拡張性に劣る。またJNIを使ったCコードというのは単なるCコードよりもはるかに可読性が悪く、デバッグも難しく、開発効率は極めて低い。SWTではこのセマンティックギャップ吸収、つまりネイティブレベルの機能とJava APIの間の機能マッピングロジックが見通しよくJavaのみで記述されている。またSWTでは問題の切り分けも容易である（AWTではソースの無いDLL中のエラーは基本的にデバッグ不能。SWTでは生じた問題をネイティブAPIを呼び出す等価なCコードに書き換えることができ、問題の切り分けが容易）。AWTとSWTのどちらが速いのかは実は良くわからないが、見た目や機能上の制約から現時点でAWTでアプリケーションを書くことはほぼありえない。したがって実用的な意味でSWTと速度比較すべきなのはSwingであり、その比較においては明らかにSWTの方が軽快であるし、アプリケーションがそれを実証している。"※注 J2SE1.4登場前の話。ハードウェアアクセラレーションが施されるようになった1.4.1以降はVMの高速化とJNIが相対的にネックになってきたSWTより快適な場合もわりと多くなってきた。"SWTはEclipseとは独立して、単独でJavaアプリケーションから利用することもできる。SWTの利用時において、生産性を上げるために、JFaceというクラスライブラリがある。Model View Controllerのプログラミングスタイルを支援する。SWTよりも、より抽象化されたデータの取り扱いを可能にする。JFace自体はPure Javaである。誤解されやすいが、SWTに対するJFaceは、AWTに対するSwingとは大きく異なる。Eclipse Public License (EPL) が適用される。EPLは、OSIオープンソース・コンソーシアムからオープンソースの認定を受けている。EPLはCommon Public License (CPL) から派生したライセンスである。

出典:wikipedia