Eclipse (統合開発環境)

Eclipse（イクリプス、）は、コンピュータプログラミングにおいて使用される統合開発環境（IDE）である。ベースとなるワークスペースと、環境をカスタマイズするための拡張可能なプラグインシステムが含まれている。Eclipseは主にJavaで書かれており、主にJavaアプリケーションの開発に使用されるが、Ada 、ABAP、C 、C ++ 、C＃ 、Clojure 、COBOL 、D、Erlang、Fortran 、Groovy 、Haskell、JavaScript、Julia、 Lasso、Lua、NATURAL、Perl、PHP、Prolog、Python、R、Ruby（Ruby on Railsフレームワークを含む）、Rust、Scala、Schemeなどのプラグインを介して他のプログラミング言語のアプリケーションを開発するために使用することもできる。また，LaTeX(TeXlipseプラグイン経由)やソフトウェアMathematicaのパッケージを使ったドキュメントの開発にも利用できる。開発環境としては，JavaやScala用のEclipse Java開発ツール(JDT)，C/C++用のEclipse CDT，PHP用のEclipse PDTなどを含んでいる。
初期のコードベースはIBM VisualAgeに由来している。Java開発ツールを含むEclipseソフトウェア開発キット（SDK）は、Java開発者向けのものである。ユーザーは、他のプログラミング言語の開発ツールキットなど、Eclipseプラットフォーム用に書かれたプラグインをインストールすることで、その機能を拡張することができ、独自のプラグインモジュールを書いてコントリビュートすることができる。Eclipseのバージョン3でOSGi実装(Equinox)が導入されて以来、プラグインは動的に停止することができ、(OSGI)バンドルと呼ばれている。
Eclipse ソフトウェア開発キット （SDK）はフリーでオープンソースのソフトウェアであり、 Eclipse Public Licenseの条件に基づいてリリースされているが、 GNU General Public Licenseとは互換性がない。 これは、GNU Classpathで実行される最初のIDEの1つであり、IcedTeaで問題なく実行される。
歴史.
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をオープンソース化するとともに、他の組織 (ボーランド、MERANT、QNX Software Systems、ラショナルソフトウェア、レッドハット、SuSE、、) と共同で初期のEclipse.orgであるEclipse Board of Stewardsを設立する。公開されたEclipseはたちまちのうちに多くの開発者の興味を惹くこととなった。同年IBMはVisualAgeの後継製品として、EclipseをベースにWebSphere Studioを開発、リリースした。
また、2003年の終わりには、Eclipse Board of Stewardsの参加メンバーも80を越えている。
しかし爆発的人気の陰で、Eclipseは、IBM以外の他団体から新たなツールが提供されないという問題を抱えていた。それは、IBMがEclipseの制御権を握っているという認識によるものであった。IBM側にも「EclipseはWebSphere Studioの共通基盤であるWebSphere Studio Workbenchの一部を公開した物である」という認識が存在した。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上では公表されていない。
Eclipse 4.9以降はコードネームが廃止になり、3か月ごとのリリースになった。
Eclipseの機能.
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の両方が利用可能）。
JUnit連携.
Javaソースコードから、JUnitテストコードの自動生成、テスト実行を行うことができる。Eclipse 3.2からは、Java SE 5のアノテーションに対応したJUnit 4を使うことが可能になった。
Ant連携.
ビルドシステムAntと連携できる。Antは、Unix系のコマンドmakeを置き換えるプログラムで、Makefileに相当する各ソースコードの依存関係をXMLにより記述する。Antは、Javaで書かれており、ウェブサーバで知られるApache Software Foundationプロジェクトで開発されている。EclipseはAntをデフォルトで同梱している。
リファクタリング.
getter, setterメソッドの自動生成や、try-catchの自動追加、による文字列の外部化、クラス名・メソッド名・変数名の変更（それを参照している部分も自動的に書き換わる）、メソッドの移動や抽出などをウィザード形式で行ってくれる。
コード編集支援.
クラス名・メソッド名・変数名の補完や、自動整形、import文の整理・自動生成、必要なthrows節の自動追加、必要なメソッドスケルトンの自動生成などさまざまな編集支援機能を持つ。
Eclipse Compiler for Java (ECJ).
JavaDevelopmentToolsに使用されているEclipse独自のJavaコンパイラ。
この為EclipseはJDKが無くてもJavaファイルのコンパイルが可能である。
SWT.
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のみで記述されている。またAWTではソースの無いDLL中のエラーは基本的にデバッグ不能であるが、SWTでは生じた問題をネイティブAPIを呼び出す等価なCコードに書き換えることができ、問題の切り分けが容易である。
SWTはEclipseとは独立して、単独でJavaアプリケーションから利用することもできる。
JFace.
SWTの利用時において、生産性を上げるために、JFaceというクラスライブラリがある。Model View Controllerのプログラミングスタイルを支援する。SWTよりも、より抽象化されたデータの取り扱いを可能にする。JFace自体はPure Javaである。
Eclipseベースの製品.
プラグインによる高い拡張性と、後述するEclipse Public License (EPL) が完全なコピーレフトではなく再配布も認めている事から、生みの親であるIBMに限らず様々な企業、団体からEclipseをベースとした有償、無償の製品が公開されている。また、それらはIDEに限らない。
ライセンス.
Eclipse Public License (EPL) が適用される。EPLは、OSIオープンソース・コンソーシアムからオープンソースの認定を受けている。EPLはCommon Public License (CPL) から派生したライセンスである。