レベル: 中級 Genady Beryozkin (mail@genady.org), Software Developer, OCSolutions
2007年 8月 21日 Microsoft Visual Studio を使用する開発者にとって Eclipse は新しい世界であり、Eclipse を使い始める際には混乱しがちです。プラグインによるアーキテクチャーやワークスペース中心のプロジェクト構造、そして自動ビルドなどの新しい概念は、最初は直感に反しているように思えます。これらの概念について、またその他 2 つの環境の間でのさまざまな違いについて学び、Eclipse を気軽に使いこなせるようになりましょう。
IDE (integrated development environment: 統合開発環境) はどれも同じ目的のために作られているため、どの
IDE も似ています。しかし、それぞれの IDE の間には違いもあります。その一部はアプリケーションの領域での違いによるものですが、一部は IDE
の設計の違いによるものです。
当然ですが、Microsoft Visual Studio と Eclipse は異なっています。Java™ プログラミング言語は
C/C++/.NET と異なり、また Java は Eclipse でサポートされた最初の言語でした。両者の違いは、Eclipse が「すべてのものを対象に、特定のものに限定しない」IDE
を目的とし、汎用的でカスタマイズ可能な機能を導入していることにも理由があります。また Eclipse は、さまざまなオペレーティング・システムで利用可能です。しかしこの記事の目的は、Eclipse
と Visual Studio との間の違いをすべて列挙することではありません。
この記事では IDE の設計の哲学には深入りせず、この 2 つの IDE の間の主な違いを解説します。またこの記事は、これまで Visual
Studio を使ってきて Eclipse を使い始めた人なら誰もが対象です。ここでは Eclipse での Java プログラミングを教えるわけではなく、Java
専用の機能に焦点を絞るわけでもありません (Java 専用の機能については「参考文献」に優れたチュートリアルをあげました)。この記事では、両者の間の一般的な違いについて解説します。
Eclipse のワークスペース
 |
ワークスペースのディレクトリー
Eclipse のワークスペースはファイルシステムの中のディレクトリーであり、専用の .metadata サブディレクトリーを含んでいます。.metadata
ディレクトリーは、そのワークスペースのすべてのプライベート情報 (設定やキャッシュなど) を含んでいます。通常、.metadata ディレクトリーのファイルは、どれも変更してはいけません。またワークスペース・ディレクトリーは、Eclipse
の新しいプロジェクトのデフォルトの場所でもあります。
|
|
一般的な意味では、Eclipse のワークスペースは、Visual Studio のソリューションと同じ目的を持った役割を果たしており、最上位レベルにあるプロジェクト、フォルダー、そしてファイルを階層構造で体系づけています。しかし、両者の間にはいくつか大きな違いがあります。Visual
Studio のソリューションでは、ソリューションに含まれるプロジェクトを、相互依存関係や構成、バージョン管理情報などによって単純にリストするにすぎません。
Eclipse のワークスペースは、それよりもはるかに多くのことをし、プロジェクト以外の情報 (グローバル・プリファレンス (設定) やウィンドウの配置、検索やナビゲーションの履歴など)
の大部分を管理します。Eclipse はワークスペースがないと起動できず、また Visual Studio のソリューションを閉じるようにワークスペースを閉じることはできません。Eclipse
ではワークスペースを切り替えることはできますが、多くのユーザーは、すべてのプロジェクトを含む 1 つのワークスペースを使います。
プロジェクトの構造
|
Eclipse のプロジェクトの構造の起源
プロジェクトの構造とそのファイルシステムの配置が厳密に対応している点は、Java パッケージ群とファイルシステム上でのそれらの配置とが必ず対応している必要があることに影響されたもののようです。Java 言語では、クラス p1.p2.p3.Class1 はディレクトリー p1/p2/p3 になければなりません。
Visual Studio の言語 (C/C++/C#、そしてさらには J# も) は、そうしたディレクトリー構造を強制しません。その結果、プロジェクトの構造とファイルシステム上でのそれらの配置との対応は、Visual Studio ではそれほど厳密ではありません。
|
|
Eclipse のプロジェクトと Visual Studio のプロジェクトは、ベースとなるファイルシステムとの関係が異なります。Visual
Studio では、プロジェクトはファイルシステム上でのプロジェクトの配置に強く結びつけられていません。c:\temp\ のファイルを d:\work
にあるプロジェクトに追加することができ、そして Visual Studio は新しいファイルへの参照を記録し、新しいファイルを他の任意のファイルと同じように開くことができます。フォルダー
(例えば「ヘッダー・ファイル」など) は、ファイルシステムのフォルダー (内部的にはそうしたフォルダーはフィルターと呼ばれます) とは対応しません。
Eclipse では、プロジェクトの要素群の構造は、ベースとなるファイルシステムでの要素群の配置に対応している必要があります。例えば、Eclipse
のプロジェクト HelloWorld (図 1) が c:\eclipse\workspace\HelloWorld にあるとすると、README.TXT
は c:\eclipse\workspace\HelloWorld\src\README.TXT にあります。
図 1. 単純な HelloWorld プロジェクト
また Eclipse では、プロジェクトのディレクトリーの下にあるファイルとも同期する必要があります。Eclipse のファイルあるいはフォルダーを削除すると、そのファイルあるいはフォルダーはファイルシステムからも削除されます。しかし同じファイルを
Windows® Explorer を使って追加したり削除したりすると Eclipse の関連リソースは同期が失われ、一部の操作では
Eclipse の動作がおかしくなるかもしれません。そうした場合には、そのプロジェクトの右クリック・メニューから Refreshを選択し、手動でプロジェクトを更新する必要があります。自動的にファイルシステムと同期するように Eclipse に命令するには、Eclipse
のプリファレンス (設定) で Refresh automatically オプションを選択します。
Eclipse にリソースをリンクさせる
厳密なワークスペース構造が、すべての出発点でした。ワークスペース・ディレクトリーの外にプロジェクトを保存することはできますが、Eclipse
の初期のバージョンでは外部ファイルを開くことすらできませんでした (現在のバージョンでは File > Open File を使います)。UNIX® ユーザーはシンボリック・リンクを使うことで柔軟なプロジェクト構造をエミュレートできるので幸運でしたが、Windows
ユーザーにはそうした特権はありませんでした。今日では、Eclipse は IDE レベルでリンク・リソースをサポートしています。
Eclipse でのリンク・リソースは、UNIX のシンボリック・リンクとほとんど同じように動作します。例えば、テスト用の大きな入力ファイルを、元々の場所からコピーせずにプロジェクトに追加するためには、File > New > File を選択し、その結果開かれるウィンドウで Advanced をクリックします (図 2)。リンク・リソースが追加されると、それらのリソースのアイコンの上に小さな矢印が付きます (図 3)。
図 2. リンク・ファイルを追加する
図 3. HelloWorld プロジェクトのリンク・ファイル
ヒント: リンク・リソースを使ってパフォーマンスを改善する
|
リンク・フォルダーを Java 出力フォルダーとして使う
リンク・フォルダーを既存プロジェクトの Java 出力フォルダーとして使うためには、そのプロジェクトがソースと .class ファイルに別々のフォルダーを使っていることを最初に確認する必要があります (別々のフォルダーを使っていない場合には、ソース・ファイルを別のフォルダーに移動する必要があります)。次に Navigator ビューを開き、自動ビルドをオフにし、古い出力フォルダーを削除し、それと同じ名前で新しいリンク・フォルダーを作成し、再度自動ビルドをオンにし、そしてそのプロジェクトを Project > Clean を使ってリビルドします。
|
|
リンク・フォルダーは、リモートの場所にある大規模なプロジェクト (ファイル・サーバーや ClearCase の動的ビューなど) を扱う際に便利です。ソース・ファイルは、適切にバックアップされ、その他の管理も適切に行われるというメリットはありますが、生成される
.class ファイルをそうしたリモートのストレージに保存する理由はほとんどありません。ソース・ファイルが数百を超えるプロジェクトでは、生成されるファイルをローカル・マシンに保存することで、多くの操作のパフォーマンスを劇的に改善することができます。
Visual Studio の C++ プロジェクトでは、ローカルの場所に中間ディレクトリーを設定することでビルドのパフォーマンスを改善することができます。それと同じ効果を
Eclipse で得るには、ローカル・マシンのディレクトリーを指す、リンク出力フォルダーを使います。
「参考文献」には、これらの他に、変数を使って (例えば UNIX では /tmp、Windows では c:\temp の一時ディレクトリーを使って) プラットフォームに依存するリンク・ターゲットを定義する方法などをあげてあります。
ワーキング・セットを使って乱雑さを軽減する
先ほど触れたように、多くの開発者はすべてのプロジェクトを 1 つの Eclipse ワークスペースにロードします。こうすると便利ですが、乱雑になりすぎてしまうことがあります。それを防ぐためには、不必要なプロジェクトを閉じる他に、ワーキング・セット
(プロジェクトやフォルダー、クラスなど要素のグループ) を定義する方法があります。Eclipse は、さまざまなビュー (例えば Package
Explorer ビューなど) や操作 (例えば検索など) でワーキング・セットを使うことができます。詳しくは「参考文献」を参照してください。
ローカル履歴 (local history)
Eclipse で最も優れた機能の 1 つで Visual Studio にはない機能は、ローカル履歴です。ファイルやクラス、あるいはメソッドを変更するごとに、Eclipse
はその変更をローカル履歴に記録します。これによって、あるファイルを、数分前、数時間前、あるいは数日前の状態と比較することができます。もしファイルが削除されている場合には、そのファイルの親のコンテキスト・メニューから
Restore from Local History を呼び出すことで、そのファイルを元に戻すことができます。
ローカル履歴はバージョン・コントロールを置き換えるものではなく、履歴日数と割り当てられた保存容量の制限を構成できる、優れたアンドゥ・エンジンのようなものです。
プロジェクトを作成する
Visual Studio の方法では、1 つのプロジェクトが 1 つのプロジェクト・タイプ (C++/C#/J#) を持ちますが、これとは逆に
Eclipse のプロジェクトは、ゼロ、1 つ、あるいは複数のネイチャーを持つことができます。例えば、Eclipse の Java プロジェクトは
Java ネイチャーを持ち、動的 Web プロジェクト (Eclipse WTP を使って作成されます。「参考文献」を参照) は Java ネイチャーと、(例えとしての) Web ネイチャーを持ちます。プロジェクトのネイチャーは、プロジェクトのビルド中に実行されるビルダーのリストを定義します。例えば、Java
ネイチャーは Java ソース・ファイルを .class ファイルにコンパイルするビルダーを追加し、また Web ネイチャーは XML ファイルと
HTML ファイルを検証するビルダーを追加します。
プロジェクトを自動的に作成する
|
Java 以外のプロジェクトを作成する
Java プロジェクトにとって、自動ビルドは完璧です。内部のインクリメンタル・コンパイラー (Eclipse は javac を使いません) が小さなコード変更を素早く処理してくれるからです。ビルドはバックグラウンドで実行されますが、小さな更新によって長々としたコンパイルがトリガーされる場合もあるプロジェクト・タイプ (CDT プロジェクトなど) では、自動ビルド (Project > Build Automatically) をオフにしたいことがあるかもしれません。自動ビルドをオフにした場合には、手動でビルドを実行 (Project > Build All) するか、あるいはアプリケーションを実行する前に Eclipse にビルドさせます。
|
|
多くの人は Eclipse に初めて出会うと、Buildコマンドを探します。しかしそうした人達は驚くかもしれませんが、Build コマンドは見つからないか、あるいは無効にされています。これは、Visual
Studio や他のいくつかの IDE とは異なり、Eclipse には自動ビルド機能があるためです。Java プロジェクトの場合、Eclipse
は Java ファイルが変更されるごとに、その変更によって間接的に影響されるファイルを含めて、関連するファイルをコンパイルします。自動ビルドは、他のファイルに影響するコンパイル・エラーを素早く発見するための素晴らしい方法です。Java
検索など多くの操作は、これらのビルドの結果に依存しています。
カスタム・ビルド
Visual Studio のプロジェクト (主に C++ プロジェクト) は、カスタムのビルド手順を使って標準外ビルド・タスクを実行することがよくあります。カスタムのビルド・コマンドは
Visual Studio プロジェクトの単純なコマンドライン命令です。一方 Eclipse では、スタンドアロンのプログラムと Ant ビルド・スクリプトを実行します。例えば、Ant
スクリプトを使うことで、プロジェクトのクラスを含む JAR (Java Archive) ファイルをそのプロジェクトがリビルドされるたびにビルドし、デプロイすることができます。また、Ant
の build.xml ファイル用のエディターが含まれています。
プロジェクトの properties ウィンドウの Builders ページでカスタムのプロジェクト・ビルダーを構成することができ、また Run > External Tools を選択することで、グローバルなスクリプトを定義して実行することができます。
実行してデバッグする
|
言語とエントリー・ポイント
Visual Studio の言語 (C++/C#) は 1 つの実行可能ファイルに対して 1 つのエントリー・ポイントしか持つことができません (エントリー・ポイントはリンク時に決定されます)。Java プログラミング言語では、コンパイル時に複数のエントリー・ポイント (main メソッド) を持つことができます。エントリー・ポイントは、プログラムが起動する際にコマンドラインで決定されます。
|
|
Eclipse には Visual Studio とは違って起動プロジェクトの概念がありません。この違いを言語の違いによるものとすることもできますが、Visual
Studio はプロジェクトごとに 1 つの実行可能プログラムのみを生成し、また、異なるプロジェクト構成に対してのみ、異なる起動パラメーター
(コマンドライン引数など) を許可することで、さらにユーザーを制限しています。単に異なるコマンドライン引数を持つためだけに複数の構成を管理するという考え方は、ほとんどの状況では適切ではありません。
Eclipse は、アプリケーションを起動するために使用するパラメーターを、起動構成 (launch configuration) を使って収集します。Java
プログラムの場合、そうしたパラメーターは、main() クラスの名前とコマンドライン引数です。Eclipse のプロジェクトの中では、main() メソッドを持つ任意のクラスに対して別々の起動構成を持つことができます。新しい構成は、新しい
main クラスを持つアプリケーションを Run > Run As コマンドを使って起動する際に自動的に作成されます。また、Run ウィンドウ (Run > Run) を使って起動構成を作成、削除することもできます。
デフォルトで、起動構成はそのワークスペース専用であり、プロジェクトの一部ではありません。これはつまり、起動構成は他のチーム・メンバーとは共有されないということです。プロジェクトの中に起動構成を保存するためには、Run
ウィンドウの Common タブを使います (図 4)。
図 4. 起動構成の場所を変更する
Debug パースペクティブ
Eclipse にはデバッグ・モードがなく、他のパースペクティブと切り替えながら使用できる Debug パースペクティブしかありません。メインの
Debug ビューは、実行中の、あるいはデバッグ中の、すべてのプログラムをリストします。またこのビューを使うと、いくつかのプログラムを同時にデバッグすることができます
(これは Visual Studio ではもっと困難です)。Eclipse が提供するデバッグ機能の詳細を学ぶために、「Eclipse Platformを使ってデバッグする」(「参考文献」を参照) を読んでください。
Eclipse のプラグイン
Eclipse の最も重要な特徴は、無料でオープンソースの素晴らしい Java IDE であること (これが Eclipse の成功の大きな理由です)
に加え、アーキテクチャーがオープンで拡張可能なことです。Eclipse の機能の大部分は拡張可能であるか、あるいはプラグインによるコントリビューションを受け付けます。実際、Eclipse
の多くの機能が使用している拡張可能なアーキテクチャーは、一般的に利用可能なアーキテクチャーと同じです。
Eclipse が使用している、ビジネスにとって使いやすいオープン・ソースのライセンスによって、商用のプラグインやオープンソースのプラグインの開発が促進されます。それを考えれば、Eclipse
Plugin Central の正式なプラグイン・マーケットに 800 を超えるプラグインがリストされていることは驚くには当たりません。
既存の Eclipse システムに統合できるプラグインの他に、いくつかの会社が Eclipse をベースにした古機能の IDE を構築しています
(すべての IBM® Rational® ツールやCodeGear JBuilder 2007、そして Genuitec
MyEclipse など)。通常、これらの製品は、モデリングや Web 開発、ビジュアル・デザインなどのためのツールを提供しています。これらの製品やプラグインの一覧は「参考文献」を参照してください。
その他の Eclipse プロジェクト
Eclipse の基本的な SDK (software development kit) には、Java IDE しか含まれていません。他の言語
(C/C++ や PHP) のためのツールキットやモデリング・ツール、その他の拡張機能は、Eclipse という枠組みの中で開発されており、Eclipse
プラグインとしてインストールすることができます。「参考文献」には、2007年の上位 21 位までの Eclipse プロジェクトの最新同時リリースである Europa と、その前の、2006年の 6月に上位
10 位までのプロジェクトをリリースした Callisto についての情報をあげてあります。
アップデート・マネージャー
Eclipse を初めて、あるいはアップグレードとしてダウンロードすると、必ず単純な圧縮ファイルになっているので、これを空のディレクトリーに解凍します。何かを構成したりデスクトップにショートカットを作成したりするインストーラーはありません。しかし
Eclipse には、プラグイン用にUpdate Manager (Help > Software Updates) があり、これがインストールと更新の両方の処理を行います。またアップデート・マネージャーは、Visual Studio で Add-in Manager
が行うのと同じように、プラグインを有効にしたり無効にしたりすることもできます。
Update Manager は、プラグインのインストールあるいは更新を、(ローカルの、あるいは Web 上の) アップデート・サイトから行います。新しいプラグインをインストールするためには、そのベンダーの
Web サイトでアップデート・サイトの URL を見つけ、それを Update Manager のウィンドウに手動で入力する必要があります。(一部のベンダーは、背後でアップデート・マネージャーとやり取りするフル機能のインストーラーを作成しています)。
また、Update Manager による方法ほど充実してはいませんが、 Eclipse はプラグインを適当なディクトリーに手動コピーすることでインストールする方法もサポートしています。これは推奨の方法ではなく、この方法では
Eclipse の構成に矛盾が生じるおそれがあります。詳しくは「基本的なトラブルシューティング」を見てください。
ヘルプが必要な場合には
Eclipse が初めての場合には、いくつかの質問があるはずです。また Eclipse をしばらく使ってみると、いくつかのバグを見つけることや、あるいは新しい機能を提案したくなるかもしれません。このセクションでは、さまざまなサポート・オプションを調べます。
基本的なトラブルシューティング
誰もが知っているように、場合によると IDE の動作がおかしくなることがあります。Visual Studio では、コマンド・プロンプトで devenv /setup と入力すれば、すべてを工場出荷時の状態にリセットすることができます。Eclipse にも同じようなコマンドライン・スイッチがあります。コマンドラインで
eclipse.exe -clean を実行することで、インストールされたプラグインに関する大部分の情報がリビルドされます。-clean オプションは、新しいプラグインをインストールしたにもかかわらずそれが表示されない時に便利です。
Eclipse の動作がおかしい場合には、エラー・ログをチェックする必要もあるかもしれません。Error Log ビューを開くには、Window > Show View > Error Log を選択します。生のログは <workspace dir>/.metadata/.log ファイルの中にあります。
ニュースグループ
これまで Microsoft 製品を扱ってきた人であれば、MSDN (Microsoft Developer Network) のフォーラムやニュースグループでヘルプが得られることを知っているでしょう。Eclipse
コミュニティーには独自のニュースグループ (「参考文献」を参照) があり、Eclipse を常に使っている多くの人達が手助けしてくれます。
バグの報告と新しい機能の要求
Microsoft はカスタマー・サポートを提供するために Microsoft Connect Web サイトでフィードバック機能を提供していますが、Eclipse
Bugs はそれとは異なり、Eclipse 開発者が使用する実際のバグ追跡システムです。Eclipse Bugs ではバグに関する検索や報告、投票を行えるだけではなく、皆さん自身を
CC として他の誰かのバグ情報に追加し、誰がその修正を担当しているか、またバグを修正しなければならないバージョンなど、さまざまな情報を見ることができます。また、同じインターフェースを使って機能への要求も投稿することができます
(「参考文献」を参照)。
プレミアム・サポート
一部の会社では、Eclipse Bugs のオープンソース精神とコミュニティーによるヘルプに加え、その会社の開発チームのための商用レベルのサポートを必要とします。Eclipse
をベースに作成されている製品を購入する場合には、その製品のベンダーが、ベースとなる Eclipse コンポーネントを含めて製品のサポートを提供しているはずです。基本的な
Eclipse SDK を使う場合には、IBM Rational Elite Support for Eclipse プログラムが提供する、全世界向けの24
時間、週 7 日、年間 365 日のサポート・プランを検討してみてください。
まとめ
ここでは、IDE が持つ一般的な原則と機能を Eclipse がどのような方法で実現しているかを解説しました。ワークスペース中心の方法とプロジェクト構造という一面、そして非常に柔軟な
UI 設計と起動構成という、もう一方の面からわかるように、Eclipse の IDE の設計はユニークです。そしてオープンで拡張可能なアーキテクチャーによって、Eclipse
はサードパーティーによる非常に多様なプラグインや製品のプラットフォームとなります。
チュートリアル「Eclipse for Visual Studio developers」(「参考文献」を参照) をまだ読んでいない人は、ぜひ読んでください。このチュートリアルは、Eclipse での Java 開発を適切に紹介しています。まだこれを読んでいない人は、ぜひ読んでください。しかし
Eclipse は Java プログラミング言語専用ではありません。C++ の IDE などの、追加された Eclipse プロジェクトを調べるために、Callisto
リリースと Europa リリースをチェックしてください。そして Eclipse Plugin Central を訪れ、よく使われている Eclipse
プラグインをいくつかダウンロードしてみてください。
参考文献 学ぶために
製品や技術を入手するために
議論するために
著者について | 
| | Genady Beryozkin は 9 年以上の経験を持つソフトウェア開発者です。彼はさまざまな C++ プロジェクトや C# プロジェクトに
Visual Studio を使用したことがあり、また 2001年に最初の 1.0 がリリースされる以前から Java 開発に Eclipse
を使ってきています。2002年には Eclipse 用の RMI プラグインを作成しました。これを利用することで、Java の RMI (Remote Method Invocation) 技術を使用したアプリケーションの開発や、デバッグ、実行を効果的に行うことができます。彼はイスラエルの Haifa にある Technion
でコンピューター・サイエンスの学位 (summa cum laude: 最優等) と修士号を取得しています。 |
記事の評価
| 
