3.0 のメカニズムと API を採用する場合に必要な変更

このセクションでは、3.0 のメカニズムと、API を採用するように 2.1 プラグインを変更する場合に必要な変更について説明します。

org.eclipse.core.runtime.compatibility からの離脱

Eclipse 3.0 ランタイムは、著しく異なります。基礎となっている実装は、OSGi フレームワークの仕様をベースにしています。Eclipse 3.0 ランタイムには、2.1 API を維持する互換性レイヤーが (org.eclipse.core.runtime.compatibility プラグインの中に) 組み込まれています。 追加されているパフォーマンスと機能に関心のあるプラグイン開発者は、3.0 API の採用、および互換性レイヤーへの依存の排除について考慮する必要があります。 互換性コードは、以下の 3 つの場所に示されています。

以下に、互換性のためにあるクラスとメソッド、およびプラグインを更新する方法について詳しく説明します。

プラグインおよびバンドル

Eclipse ランタイムは、クラス・ロードおよび前提条件管理、および拡張/拡張ポイント管理の 2 つに リファクタリングされます。このように分けることによって、クラス・ロードおよび前提条件管理のための OSGi フレームワーク仕様を自然かつシームレスに採用できるようになります。 これにより、動的プラグインのインストール、更新、アンインストールから、セキュリティーや向上した 互換性までの範囲のランタイムの新機能が使用可能になります。

プラグイン についてさらに説明すると、新しいランタイムでは、プラグインは完全にバンドル されており、さらに拡張および拡張ポイントがプラスされています。 バンドル という用語は、OSGi フレームワーク仕様では、型とリソースと関連したバンドル内の前提条件情報のコレクションを指すものとして定義されています。 拡張レジストリー は、プラグイン・レジストリーの新しい形式で、拡張および拡張ポイントの情報のみを詳述します。一般に、拡張レジストリー API は、関係のあるプラグイン・レジストリー API と同じものです (詳しくは、『レジストリー』を参照)。

Eclipse 2.x ランタイムでは、プラグイン・オブジェクトに多数の役割と責任があります。

Eclipse 3.0 ランタイム・ピクチャーでは、これらの役割および責任は、いくつかのオブジェクトに明確に分けられます。

Bundle
Bundle は、モジュール性の OSGi 単位です。 バンドルごとに 1 つのクラス・ローダーがあり、Eclipse のような、バンドル間の クラス・ロード依存関係グラフを構成することができます。バンドルには、開始と終了のためのライフ・サイクル、および関心のあるパーティーへの OSGi フレームワーク・ブロードキャスト・バンドル関係のイベント (インストール、解決、開始、停止、アンインストールなど) があります。 Eclipse の Plugin クラスとは異なり、OSGi の Bundle クラスは拡張可能ではありません。つまり、開発者が独自のバンドル・クラスを定義することはできません。
BundleActivator
BundleActivator は、OSGi フレームワークによって定義されるインターフェースです。プラグインがその Plugin クラスを定義できるのと同様に、それぞれのバンドルは、バンドル・アクティベーター・クラスを定義することができます。 指定されたクラスは、フレームワークによってインスタンス化され、start() および stop() ライフ・サイクル処理をインプリメントするために使用されます。 ただし、このライフ・サイクル処理の性質に大きな違いがあります。 Eclipse では、Plugin クラスが初期化と登録の両方を行うのが一般的です (推奨ではありません)。OSGi アクティベーターは、登録のみを行う必要があります。 BundleActivator.start() で大量の初期化 (またはその他の作業) を行うと、システムの活性が低下する恐れがあります。
BundleContext
BundleContexts は、個々のバンドルに一般的なシステム機能を公開するための OSGi メカニズムです。それぞれのバンドルには、システム機能へのアクセスに使用できる、固有でプライベートな BundleContext インスタンスがあります (システム内のすべてのバンドルを発見するための getBundles() など)。
Plugin
新しい Plugin は、オリジナルの Eclipse の Plugin クラスにとてもよく似ていますが、以下の例外があります。Plugin オブジェクトは、ランタイムで不要または管理されなくなりました。また、さまざまなメソッドが推奨されなくなりました。基本的には、便利な機能およびメカニズムをホスティングする便利なメカニズムですが、絶対に必要なものではなくなりました。提供される機能の多くは、ランタイムの Platform クラスでも使用可能です。

PluginBundleActivator をインプリメントします。 これは、プラグインのライフ・サイクルおよびセマンティックを代表するオブジェクトが、中央に 1 つあるのが便利だと認識します。ただし、これは、今日のプラグインで一般的になっている、必要性の有無を考慮せずにデータ構造を初期化することを 是認するものではないことに注意してください。他のプラグインでクラスが検査されているときに、 関連性の低いクラスが参照されるために、プラグインが活動化される可能性があることに十分注意してください。つまり、プラグインが活動化されただけで、その機能が必要とされていることを意味しているとは限りません。また、別の BundleActivator クラスを定義するか、 またはバンドル・アクティベーターを全く持たないことができることにも注意してください。

2.x の Plugin クラスを Eclipse 3.0 に移植するために必要なステップは、そのクラスが何を行うかによって異なります。上で概説したように、開始時のライフ・サイクル作業のほとんどは、以下のカテゴリーのいずれかに入ります。

初期化
データ構造とモデルの初期化は、しばしば Plugin.startup() で行われます。 自然かつ明白なマッピングは、この作業を BundleActivator.start() で行うことです。 つまり、機能を Plugin に残すことです。これは全く推奨されません。 2.x プラグインと同様に、3.0 プラグイン/バンドルも、さまざまな理由からさまざまな環境で開始される可能性があります。
Eclipse 2.0 における実例で、このケースについて説明します。 11MB ほどのコード と何メガバイトもの大きなデータのロードを要求する大規模なモデルを初期化したプラグインが ありました。 非常に一般的なユース・ケースですが、ナビゲーター内に存在するプロジェクト・アイコンに特定のマークアップを付ける必要があるかどうかを調べるために、プラグインが活動化されました。 このテストには、startup() で行われる初期化は全く必要ありませんでしたが、 すべてのユース・ケースにおいて、すべてのユーザーが必要性の有無を考慮せずに初期化を行うことによって、メモリーと時間を犠牲にしていました。
代替アプローチとしては、このような初期化を従来の急がないスタイルで行います。 例えば、プラグイン/バンドルの活動化時にモデルを初期化するのではなく、それらが実際に必要になったときに (中央の model accessor メソッドなどで) 初期化します。 多くの場合、この方法でも時間的には変わりませんが、他のシナリオでこのアプローチを行うと、初期化は (おそらく無限に) 延期されます。2.1 プラグインの移植を行うときに、使用する初期化計画を見直すことをお勧めします。
登録
プラグインの開始時は、リスナー、サービスなどの登録、およびバックグラウンド・プロセス・スレッド (ソケットの listen など) の開始に適しています。Plugin.start() は、この作業を行うのに適している場合があります。 また、別のトリガー (例えば、特定の機能またはデータ・エレメントの使用) までこの作業を延期することが適している場合もあります。
プラグイン・グローバル・データ
Plugin クラスは、この役割を継続して果たすことができます。 主な問題は、Plugin オブジェクトはもはやシステム管理リストを介してグローバルにアクセスできないということです。Eclipse 2.x では、プラグイン・レジストリーを介して、すべてのプラグインの Plugin オブジェクトを見つけることができました。 これは、もはや可能でなくなっています。多くの場合、このタイプのアクセスは必要ありません。 登録によってアクセスされる Plugin は、ドメイン固有のメソッドを呼び出すよりも、多くの場合、汎用の Plugins として使用されていました。 対応する Bundle オブジェクトにアクセスし、操作することによって、同等レベルの機能を得ることができます。

レジストリーおよびプラグイン・モデル

新しいランタイムでは、プラグインの実行に必要な情報と構造、およびプラグインの拡張や拡張ポイントに関連する情報 と構造は分離されています。 前者は、OSGi フレームワーク仕様によって定義および管理されます。 後者は、Eclipse 固有の概念で、Eclipse ランタイム・コードによって追加されます。 したがって、オリジナルのプラグイン・レジストリーおよび関連するオブジェクトは、OSGi のバンドル と Eclipse の拡張レジストリー に分けられています。

実行の仕様に関係する IPluginRegistry のパーツ (例えば、IPluginDescriptor、ILibraryIPrequisite など) は推奨されなくなり、拡張と拡張ポイントに関連するその他のパーツは、IExtensionRegistry に移動されています。また、プラグイン・レジストリーに関連する、いわゆるモデル・オブジェクトは、全体として現在では推奨されていません。これらの型は、主に PDE などのツールをサポートするためのものであり、ランタイムによってインスタンス化されていました。 残念なことに、必要とされる情報のレベルがランタイムの能力または関心を超え (例えば、plugin.xml エレメントの行数の記憶など)、最終的に、ランタイムの情報の潜在的な利用者による独自の構造の保守が必要とされることが頻繁にありました。

新しいランタイムでは、ランタイムによって提供されていた機能を再評価し、 現在では、ランタイムの実行に欠かせないか、または他で行うのは非常に難しいものだけを提供するようになっています。 前述のように、プラグイン・レジストリー・モデル・オブジェクトは、プラグイン構文解析 API があるために推奨されなく なりました。新しい拡張レジストリーは、非常に重要な拡張関連の情報を保守します。新しい状態 (org.eclipse.osgi.service.resolver.State と関連情報を参照) の構造体によって、重要な実行関連の情報の操作が表され、使用可能にされます。

NL フラグメント構造体

Eclipse 3.0 では、NL フラグメント構造体は、さらに整合したものになるように更新されました。以前は、plugin.properties のようなファイルの変換は、フラグメントによって提供される JAR の内部にあるものと想定されていました。オリジナルのファイルは、関連するホスト・プラグインのルートにあるため、変換されたファイルのより一貫性のあるロケーションは NL フラグメントのルート内にあります。以下に例を示します。

  org.eclipse.ui.workbench.nl/
     fragment.xml
     plugin_fr.properties
     plugin_pt_BR.properties
     ...
     nl1.jar

ここでは、ファイル nl1.jar には、以前は plugin.properties から変換されたファイルが含まれていた可能性があることに注意してください。これらのファイルは、現在ではそのフラグメントのルートにあり、JAR にはホスト・プラグイン内の任意の変換可能なリソース (つまり、クラス・ローダーを通してロードされたファイル) が含まれます。

Eclipse 2.1 NL フラグメント構造体は、現在でも Eclipse 3.0 で実行される 2.1 ホスト・プラグインでサポートされています。 ただし、3.0 プラグインで 2.1 NL フラグメントを使用することはできません。 フラグメントを新しい構造体に更新する必要があります。

API の変更の概要

org.eclipse.core.boot (パッケージ org.eclipse.core.boot)

org.eclipse.core.boot パッケージ全体が推奨されなくなりました。 ブートとランタイムを分けることに意味がなくなったため、BootLoader は、org.eclipse.core.runtime.Platform とマージされています。 事実上、org.eclipse.core.boot プラグインは分割され、そのコードはすべて、新しいランタイムまたは互換性レイヤーに移動されたことに注意してください。

IPlatformConfiguration は、通常、Eclipse のインストール/更新コンポーネントによって定義された 型、かつそのコンポーネントのための型でした。 ランタイムの再編成により、この型をこれに適したホームへ帰すことができました。 このクラスのほとんどは未変更で、org.eclipse.update.configurator.IPlatformConfiguration として再パッケージ化されました。

IPlatformRunnable は、org.eclipse.core.runtime.IPlatformRunnable に移動されています。

IExtension および IExtensionPoint (パッケージ org.eclipse.core.runtime)

(両方のクラスの) getDeclaringPlugin() メソッドは、それぞれ拡張または拡張ポイントを宣言するプラグインへの上向きのリンクを提供します。 新しいレジストリー・モデルによって、プラグインの実行に関する局面が拡張/拡張ポイントに関する局面から 分離され、IPluginDescriptors が含まれなくなっています。 この API のユーザーは、IExtension および IExtensionPoint の両方にある新しいメソッド getParentIdentifier() について考慮する必要があります。

ILibrary、IPluginDescriptor、IPluginRegistry、および IPrerequisite (パッケージ org.eclipse.core.runtime)

オリジナルのランタイムでは、プラグイン・レジストリーは、ランタイム構成の全体像を保守していました。Eclipse 3.0 では、この全体像は OSGi フレームワークと拡張レジストリーに分割されています。したがって、これらのクラスは推奨されなくなりました。 非推奨に関する注意事項に、コードの更新方法の詳細が記載されています。

Platform および Plugin (パッケージ org.eclipse.core.runtime)

新しいランタイムでは、Plugin オブジェクトはランタイムによって管理されなくなっているため、 一般的に Platform を介してアクセスすることができません。 同様に、プラグイン・レジストリーは存在しなくなり、プラグイン記述子へのアクセスも提供しません。ただし、適切な置換メソッドが使用可能です。詳細は、これらのクラスの非推奨のメソッドに関する Javadoc に記載されています。

org.eclipse.core.runtime.model (パッケージ org.eclipse.core.runtime.model)

このパッケージのすべての型は、現在では推奨されていません。 詳しくは、『レジストリー』の説明を参照してください。

IWorkspaceRunnable および IWorkspace.run (パッケージ org.eclipse.core.resources)

IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) メソッドのクライアントは、このメソッドの使用方法を見直し、より高度なメソッドである IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) の使用を考慮する必要があります。 古い IWorkspace.run メソッドでは、IWorkspaceRunnable の実行中は、ワークスペース全体がロックされました。このことはつまり、このメソッドと共に行われる操作は、ワークスペースを変更する他の操作とは、並行して実行できないことを意味します。Eclipse 3.0 では、長期に渡る多くの運用がバックグラウンド・スレッドに移動されたため、このような操作の競合の可能性が大幅に増加しています。 形式指定のフォアグラウンド操作が長期に渡るバックグラウンド運用によってブロックされると、UI は、フォアグラウンド操作が完了するか、それらの操作のいずれかがキャンセルされるまでブロックされます。

推奨される解決策としては、スケジュール・ルール・パラメーターを使用する新しいメソッドを使用するように、 古い IWorkspace.run に対するすべての参照を切り替えます。 スケジュール・ルールは、その操作によるすべての変更のためのルールを含む最も詳細なルールです。操作によって スケジュール・ルールの範囲外のリソースが変更されようとすると、ランタイム例外が発生します。指定されたワークスペース操作が必要とするスケジュール・ルールが、正確に指定されず、指定されたプロジェクトにインストール済みのリポジトリー・プロバイダーに従って変更される可能性があります。 ファクトリー IResourceRuleFactory は、リソース変更操作のためのスケジュール・ルールの取得に使用されます。 必要に応じて、複数のリソース規則を指定するために MultiRule を使用したり、さまざまなリソース変更操作からの規則を組み合わせるために便利な MultiRule.combine メソッドを使用することもできます。

非ロック式が必要な場合は、null のスケジュール・ルールを使用します。 これにより、実行可能ファイルはワークスペース内のすべてのリソースを変更することができますが、他のスレッドが並行してそのワークスペースを変更することは回避されません。 ワークスペースに対する簡単な変更の場合には、これが最も容易で、最も並行性に適した解決策となります。

IWorkbenchPage (パッケージ org.eclipse.ui)

IEditorDescriptor (パッケージ org.eclipse.ui)

ISharedImages (パッケージ org.eclipse.ui)

IWorkbenchActionConstants (パッケージ org.eclipse.ui)

IWorkbenchPreferenceConstants (パッケージ org.eclipse.ui)

IExportWizard (パッケージ org.eclipse.ui)

IImportWizard (パッケージ org.eclipse.ui)

INewWizard (パッケージ org.eclipse.ui)

WorkbenchHelp (パッケージ org.eclipse.ui.help)

IHelp (パッケージ org.eclipse.help)

ITextEditorActionConstants (パッケージ org.eclipse.ui.texteditor)

IAbstractTextEditorHelpContextIds (パッケージ org.eclipse.ui.texteditor)

BasicTextEditorActionContributor (パッケージ org.eclipse.ui.texteditor)

TextEditorActionContributor (パッケージ org.eclipse.ui.editors.text)

annotationTypes 拡張ポイント (プラグイン org.eclipse.ui.editors)

現在、注釈タイプには明示的な概念があります。Annotation.getType() および Annotation.setType() を参照してください。 注釈のタイプは、その存続時間において変更することができます。 注釈タイプを宣言するための新規の拡張ポイント「org.eclipse.ui.editors.annotationTypes」が追加されました。注釈タイプには名前があり、宣言された別の注釈タイプのサブタイプとして宣言することができます。注釈タイプ宣言は、指定された型および重大度のマーカーが、テキスト・エディター内で特定の注釈タイプの注釈として表されるように指定するために、属性「markerType」および「markerSeverity」も使用する場合があります。 「org.eclipse.ui.editors.markerAnnotationSpecification」の属性「markerType」および「markerSeverity」は、使用できなくなっています。このため、マーカー注釈仕様は、マーカーから独立したものになりつつあり、それに伴って名前も誤解される可能性があります。ただし、後方互換性を確保するために、名前は保持されます。

AbstractMarkerAnnotationModel のサブクラスのインスタンスは、マーカーから作成する注釈の正しい注釈タイプを自動的に検出し、設定します。 指定されたマーカー、または指定された markerType と markerSeverity のペアの注釈タイプをプログラマチックに検索するには、org.eclipse.ui.texteditor.AnnotationTypeLookup を使用します。

注釈タイプの階層へのアクセスは、IAnnotationAccessExtension によって提供されます。指定された注釈タイプの場合、スーパー・タイプのチェーンを入手し、注釈タイプが別の注釈タイプのサブタイプかどうかを調べます。 DefaultMarkerAnnotationAccess は、このインターフェースをインプリメントします。

markerAnnotationSpecification 拡張ポイント (プラグイン org.eclipse.ui.editors)

注釈タイプは、関連するマーカー注釈仕様を検索するために使用するキーです。 注釈タイプは他の注釈タイプを拡張できるため、マーカー注釈仕様の間にも暗黙の関係があります。 したがって、指定された注釈タイプのマーカー注釈仕様は、その指定された注釈タイプのスーパー・タイプに指定されたマーカー注釈仕様によって完成されます。したがって、マーカー注釈仕様は、以前必要とされたように完全である必要はありません。 マーカー注釈仕様は、AnnotationPreferences によって検索されます。 org.eclipse.ui.texteditor.AnnotationPreferenceLookup を使用することによって、注釈スーパー・タイプ・チェーンに沿って設定を透過的に完成させる、指定された注釈タイプの注釈設定を検索することができます。

垂直表示域内の指定された注釈タイプのカスタム外観の定義を可能にするために、 マーカー注釈仕様は、3 つの属性が追加され、拡張されました。 これらの属性は、「icon」、「symbolicIcon」、および「annotationImageProvider」です。「icon」の値は、アイコン・イメージが含まれているファイルのパスです。 「symbolicIcon」の値は、「error」、「warning」、「info」、「task」、「bookmark」のいずれかです。属性「symbolicIcon」は、エラー、警告、通知、タスク、およびブックマークそれぞれを表すためにプラットフォームによって使用されるのと同じイメージで、注釈を表示する必要があることをプラットフォームに知らせるために使用されます。 「annotationImageProvider」の値は、フル・カスタム注釈表示を可能にする、org.eclipse.ui.texteditor.IAnnotationImageProvider を実装するクラスです。

垂直表示域は、関連する IAnnotationAccess/IAnnotationAccessExtension を使用して、注釈を描画します。 垂直表示域は、Annotation.paint を呼び出さなくなりました。 一般的に、注釈は、その注釈自身をドローしなくなりました。注釈を最終的に UI から独立させるために、「paint」および「getLayer」メソッドは推奨されなくなりました。 DefaultMarkerAnnotationAccess は、IAnnotationAccess/IAnnotationAccessExtension のデフォルトの実装として機能します。 DefaultMarkerAnnotationAccess は、注釈をペイントするために次の方針をインプリメントします。 注釈が IAnnotationPresentation をインプリメントすると、IAnnotationPresentation.paint が呼び出されます。そうでない場合は、注釈設定の中で、注釈イメージ・プロバイダーがルックアップされます。注釈イメージ・プロバイダーは、指定された場合、および囲むマーカー注釈仕様を定義するプラグインがすでにロードされている場合にのみ使用可能です。 注釈イメージ・プロバイダーがある場合は、呼び出しがそのプロバイダーに転送されます。 ない場合は、指定された「icon」がルックアップされます。 「symbolicIcon」は、最終フォールバックとして使用されます。 注釈のドローには、注釈表示レイヤーが関係します。DefaultMarkerAnnotationAccess は、次の方針を使用して、表示レイヤーをルックアップします。注釈設定で表示レイヤーが指定されている場合は、その指定されたレイヤーが使用されます。レイヤーがなく、注釈が IAnnotationPresentation を実装する場合は IAnnotationPresentation.getLayer が使用され、そうでない場合はデフォルトの表示レイヤー (0) が戻されます。

annotationTypes 拡張ポイントへのマイグレーション (plug-in org.eclipse.ui.editors)

以下の注釈タイプは、org.eclipse.ui.editors プラグインによって宣言されます。

   <extension point="org.eclipse.ui.editors.annotationTypes">
<type
         name="org.eclipse.ui.workbench.texteditor.error"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="2">
      </type>
<type
         name="org.eclipse.ui.workbench.texteditor.warning"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="1">
      </type>
<type
         name="org.eclipse.ui.workbench.texteditor.info"
         markerType="org.eclipse.core.resources.problemmarker"
         markerSeverity="0">
      </type>
<type
         name="org.eclipse.ui.workbench.texteditor.task"
         markerType="org.eclipse.core.resources.taskmarker">
      </type>
<type
         name="org.eclipse.ui.workbench.texteditor.bookmark"
         markerType="org.eclipse.core.resources.bookmark">
      </type>
   </extension>

定義済みの markerAnnotationSpecification 拡張は、「markerType」および「markerSeverity」属性を提供しなくなりました。これらの属性は、「symbolicIcon」属性とそれに伴う値を定義します。したがって、MarkerAnnotation.paint および MarkerAnnotation.getLayer は呼び出されなくなりました。つまり、これらのメソッドをオーバーライドしても、影響はありません。 影響を受けるクライアントは、IAnnotationPresentation をインプリメントする必要があります。

ILaunchConfigurationType (パッケージ org.eclipse.debug.core)

3.0 で拡張可能な起動モードが導入されたため、1 つの起動構成型に対して複数の起動代行が存在することができます。3.0 より前のリリースでは、起動構成型ごとに 1 つの起動代行しかサポートされていませんでした。メソッド ILaunchConfigurationType.getDelegate() は、現在では推奨されていません。代わりに、メソッド getDelegate(String mode) を使用して、特定の起動モードの起動代行を検索する必要があります。 推奨されないメソッドは、run モードの起動代行を戻すように変更されています。

ILaunchConfigurationTab および ILaunchConfigurationTabGroup (パッケージ org.eclipse.debug.ui)

起動タブ・グループおよび起動タブは、起動が完了時に通知されなくなりました。 インターフェース ILaunchConfigurationTab および ILaunchConfigurationTabGroup の中のメソッド launched(ILaunch) は、推奨されなくなり、呼び出されなくなりました。 タブは、起動ダイアログから起動が実行された場合にのみ存在するため、起動機能に関してこのメソッドに依存することは、常に問題でした。また、バックグラウンド起動の導入で、結果の起動オブジェクトが存在しないうちに起動ダイアログが閉じられるため、このメソッドは呼び出されなくなりました。

ILaunchConfigurationTab および AbstractLaunchConfigurationTab (パッケージ org.eclipse.debug.ui)

ILaunchConfigurationTab インターフェースに、活動と非活動の 2 つのメソッドが追加されました。これらの新しいライフサイクル・メソッドは、それぞれ、タブの入力時と終了時に呼び出されます。デバッグ・プラグイン (AbstractLaunchConfigurationTab) によって提供される抽象クラスのサブクラスである ILaunchConfigurationTab の既存の実装は、そのメソッドが抽象クラス内に実装されるためバイナリー互換です。

以前のリリースでは、タブが活動化されたときにはメッセージ initializeFrom が、非活動化されたときには performApply がタブに送信されていました。 この方法により、起動構成タブのフレームワークは、(タブの終了時に現行の属性値で構成を更新し、新しく入力されたタブを更新することによって) 起動構成を介したタブ間の通信を提供していました。しかし、多くのタブはタブ間の通信を行わないため、この方法が非効率である場合があります。また、活動化されているタブと、初めて選択された起動構成を表示しているタブを区別する方法はありませんでした。新しく追加されたメソッドにより、タブは、活動化と初期化、および非活動化と現行値の保管を区別できるようになりました。

抽象タブによって提供される activated のデフォルトの実装は、initializeFrom を呼び出します。また、deactivated のデフォルトの実装は、performApply を呼び出します。新しい API の利点を活用しようとするタブは、必要に応じてこれらのメソッドをオーバーライドする必要があります。 一般的に、タブ間の通信を行わないタブに推奨される方法は、これらのメソッドが何も行わないように再実装することです。

launchConfigurationTabGroup 拡張ポイントの型 (パッケージ org.eclipse.debug.ui)

以前のリリースでは、起動構成属性 ATTR_TARGET_DEBUG_PERSPECTIVE および ATTR_TARGET_RUN_PERSPECTIVE を介して、起動構成でパースペクティブ切り替えが指定されました。3.0 で拡張可能な起動モードが追加されたため、この方法はスケーリングされなくなりました。 パースペクティブ切り替えは、現在では、起動構成型がサポートするそれぞれの起動モードごとに、起動構成型を基にして指定されます。特定の起動モードの起動構成型に関連したパースペクティブを設定および取得するために、DebugUITools に API が追加されています。

launchConfigurationTabGroup 拡張ポイントに追加のオプションの launchMode エレメントが追加され、提供されたタブ・グループが、起動構成型およびモードのデフォルトのパースペクティブを指定できるようになっています。

ユーザーは、Eclipse ユーザー・インターフェースから、起動構成ダイアログを開き、(個々の構成ではなく) ツリー内の起動構成型ノードを選択することによって、起動構成型に関連するパースペクティブを編集することができます。タブが表示され、ユーザーは、サポートされる各起動モードでパースペクティブを設定できます。

[JDT のみ] IVMRunner (パッケージ org.eclipse.jdt.launching)

VMRunnerConfiguration クラスには、環境変数の設定および検索をサポートするためのメソッドが 2 つ追加されています。IVMRunner の実装は、VMRunnerConfiguration.getEnvironment() を呼び出し、その環境を実行 JVM に渡します。DebugPlugin.exec(String[] cmdLine, File workingDirectory) を使用するクライアントは、代わりに DebugPlugin.exec(String[] cmdLine, File workingDirectory, String[] envp) を呼び出すことによってこれを行うことができます。getEnvironment() の結果を渡すだけで十分です。

[JDT のみ] VMRunnerConfiguration およびブートストラップ・クラス (パッケージ org.eclipse.jdt.launching)

以前のリリースでは、VMRunnerConfiguration にはブート・パスを記述する単一の属性がありました。その属性は、-Xbootclasspath 引数で指定される、Strings のコレクションです。JVM をサポートするために、VMRunnerConfiguration には、ブート・パスの前および後に付加できる 3 つの新しい属性が追加されています。 追加された新しいメソッド/属性は、以下のとおりです。

旧属性 getBootClassPath() もまだ存在し、3 つの新属性と同等の完全なパスが含まれます。ただし、新しいブート・パス・オプションをサポートする VMRunners は、新規属性の利点を活用します。

[JDT のみ] 作業用コピーの改善されたサポート (パッケージ org.eclipse.jdt.core)

Java モデルの作業用コピー機能は、3.0 では機能性が大幅に向上するように作り直されています。 3.0 より前の Java モデルでは、コンパイル単位の個々の作業用コピーを作成できました。 作業用コピーに変更を加え、後でコミットすることができました。 他の Java モデルのコンテキスト内での、作業用コピーの限定された分析がサポートされていました。ただし、これらの分析を、複数の作業用コピーに同時に行う方法はありませんでした。

3.0 で行われた変更によって、コンパイル単位の作業用コピーのセットを作成および管理し、セット内のすべての作業用コピーの存在を分析することができるようになりました。 例えば、現在では、JDT リファクタリングのようなクライアントは、変更が考慮されている 1 つ以上のコンパイル単位の作業用コピーを作成してから、その作業用コピー間の型参照を解決することができるようになっています。以前は、これは、 コンパイル単位の作業用コピーに対する変更がコミットされた後でのみ可能でした。

Java モデル API は、この改善されたサポートを追加するために、以下の 2 つの点において変更されています。

(1) 以前は IWorkingCopy にあった機能および ICompilationUnit から継承された機能は、ICompilationUnit に統合されました。 IWorkingCopy インターフェースはこの 1 か所でのみ使用され、必要以上に一般化されていました。この変更によって、API が単純化されます。IWorkingCopy は推奨されなくなりました。 IWorkingCopy がパラメーターまたは結果タイプとして使用される API の他の場所も、推奨されなく なりました。IWorkingCopy の代わりに、置換 API メソッドでは、ICompilationUnit が記述されます。

(2) インターフェース IBufferFactory は、WorkingCopyOwner に置き換えられました。 作業用コピーの改善されたサポートは、作業用コピーを所有するためのオブジェクトを必要とします。 IBufferFactory は正しい場所にあるにもかかわらず、その名前は、新しい作業用コピーのメカニズムがどのように作用するかを十分に伝えていません。WorkingCopyOwner は、これよりもずっと示唆的です。 また、WorkingCopyOwner は、インターフェースとしてではなく、抽象クラスとして宣言され、作業用コピーの所有者の概念が将来進化できるようにしています。 IBufferFactory の単一のメソッドは、影響されずに WorkingCopyOwner に移動します。WorkingCopyOwner は 、IBufferFactory が過去のものであることを明確にするために、IBufferFactory を実装しません。IBufferFactory は推奨されなくなりました。 IBufferFactory がパラメーターまたは結果タイプとして示される API の他の場所も、推奨されなくなりました。IBufferFactory の代わりに、置換 API メソッドでは、WorkingCopyOwner が記述されます。

これらの変更は、バイナリー互換性を損ないません。

マイグレーションする場合、型 IWorkingCopy へのすべての参照は、代わりに ICompilationUnit を参照します。 IWorkingCopy の唯一の実装は、ICompilationUnit もインプリメントします。 つまり、型 IWorkingCopy のオブジェクトを ICompilationUnit に安全にキャストできることを意味します。

IBufferFactory をインプリメントするクラスは、WorkingCopyOwner のサブクラスで 置き換えられる必要があります。WorkingCopyOwnerIBufferFactory 自体は インプリメントしませんが、IBufferFactory をインプリメントする WorkingCopyOwner の サブクラスを宣言して、新旧間を橋渡しします (IBufferFactorycreateBuffer(IOpenable) を宣言し 、WorkingCopyOwnercreateBuffer(ICompilationUnit) を宣言し、ICompilationUnitIOpenable を拡張します)。

IWorkingCopyIBufferFactory が関与する変更は、相互に影響するため、両方を同時に扱うことをお勧めします。 非推奨の詳細は、以下のとおりです。

org.eclipse.help プラグインの再構築

org.eclipse.help プラグインは、以前はヘルプ・システムを提供および拡張し、ヘルプを表示するための API と拡張ポイントを保持していましたが、現在は、ヘルプ・リソースを提供し、 ヘルプ・リソースにアクセスするための API と拡張ポイントだけが含まれています。そのプラグインに含まれるデフォルトのヘルプ UI 実装部分は、その実装を拡張する API と一緒に新規プラグイン org.eclipse.help.base に移されています。 ヘルプ UI の提供およびヘルプ表示のための API と拡張ポイントは、org.eclipse.ui プラグインに 移されています。この再構築によって、アプリケーションのヘルプ・システムに関する柔軟性が大幅に向上しています。新しい構造によって、汎用のワークベンチに基づいたアプリケーションでは、独自のヘルプ UI やヘルプの実装を提供したり、ヘルプ・システム全体を 省略できるようになります。

影響を受ける拡張ポイントおよび API パッケージは、ヘルプ・システム自体による使用のみを目的としていたため、 既存のプラグインがこの変更の影響を受けることはほとんどありません。念のために、これらの拡張ポイントおよび API パッケージを以下に示します。

新規検索 UI API

3.0 では、カスタム検索をインプリメントする新規 API が追加されています。オリジナルの API は 3.0 では 推奨されておらず、クライアントは、パッケージ org.eclipse.search.ui および org.eclipse.search.ui.text 内の 新規 API に移植することをお勧めします。

クライアントは、ISearchQueryISearchResult、および ISearchResultPage の実装を作成する必要があります。ISearchResultPage の実装は、その後、 新しい org.eclipse.search.searchResultViewPages 拡張ポイントに組み込む必要があります。

ISearchResult および ISearchResultPage のデフォルトの実装は、 パッケージ org.eclipse.search.ui.text で提供されます。

MessageBox および DirectoryDialog のヌル・メッセージ (パッケージ org.eclipse.swt.widgets)

3.0 より前では、SWT の DirectoryDialog.setMessage(String string) または MessageBox.setMessage(String string) を、 ストリングにヌル値を使用して呼び出すと、ダイアログのタイトルにテキストが入りませんでした。 この振る舞いは指定されたものではなく (ヌルを渡すことは許可されていませんでした)、ヌルを戻すことが 許可されていない getMessage に関する問題が生じます。 3.0 では、ヌルを渡すと IllegalArgumentException 例外がスローされ、これを記載するように仕様が変更され、 スーパークラス Dialog.setMessage のメソッドを使用して行に反映されています。 Dialog.setMessage を使用する場合は、渡されるストリングが絶対にヌルにならないように確認してください。ダイアログのタイトルにテキストを入れない場合は、単に、空ストリングを渡します。

モーダル進行フィードバックの改善

並行操作をサポートするには、より高度な方法でモーダル進行を表示する必要があります。応答性に関する改善の一部として、追加の進行サポートがクラス IProgressService でインプリメントされました。ProgressMonitorDialog を使用した 既存の進行表示方法もまだ機能します。ただし、ユーザーの経験の向上のために、新しい IProgressService に マイグレーションすることをお勧めします。

新しい IProgressService に移行する方法については、文書 『Eclipse 3.0 でのモーダル進行の表示』を参照してください。

除去されたデバッグ・アクション・グループ

デバッグ・アクション・グループ拡張ポイント (org.eclipse.debug.ui.debugActionGroups) は除去されました。 Eclipse 3.0 では、org.eclipse.platform.ui.activities 拡張ポイントを介したアクティビティーのサポートが、 ワークベンチに導入されています。このサポートは、デバッグ・アクション・グループが提供していたものをすべて提供し、 使用方法もより簡単になり (すべてのアクションを完全に指定するのではなく、パターンをサポートします)、 それをサポートするためにプログラマチック API を所有します。 古い拡張ポイントへの参照を除去できなくても、障害が生じることがありません。 拡張ポイントへの参照は、単純に無視されます。 製品ベンダーは、ワークベンチ・アクティビティー・サポートを使用して言語固有のデバッガー・アクションと言語固有のアクティビティーを関連付けることが奨励されます (例えば、C++ のデバッグ・アクションは、「C++ の開発」と呼ばれるアクティビティーと関連付けられる場合があります)。

BreakpointManager の使用不可化

IBreakpointManager は、メソッド setEnabled(boolean) および isEnabled() を定義するようになりました。ブレークポイント・マネージャーが使用不可になると、デバッガーはすべての登録済みのブレークポイントを無視します。デバッグ・プラットフォームも、新規のリスナー・メカニズム、IBreakpointManagerListener を提供します。これにより、クライアントは、 使用可能性が変更されたときに通知されるように、ブレークポイント・マネージャーに登録することができます。ブレークポイント・ビューは、この API を新規のトグル・アクションから呼び出します。 このアクションによって、ユーザーは、「すべてのブレークポイントをスキップ」することができます。このため、ブレークポイント・マネージャーの使用可能性を受け入れない デバッガーには、ユーザーがこの機能を使用として何か失敗したように見えます。

[JDT のみ] Java 検索 Participants (パッケージ org.eclipse.jdt.core.search)

Java に近い言語 (JSP、SQLJ、JWS など) は、Java 検索に使用できます。 特に、それらの言語の実装では、以下のことが可能です。

このような実装は、検索 Participants と呼ばれます。これは、SearchParticipant クラスを拡張します。 検索 Participants は、検索照会に渡されます (SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) を参照)。

一致を索引付けまたは検出する場合、検索 Participants は、getByteContents() または getCharContents() のいずれかをオーバーライドすることによって文書の内容を検索できる SearchDocument のサブクラスを定義する必要があります。 このサブクラスのインスタンスは、getDocument(String) で戻されます。

一部の文書を索引付けする検索 Participants は、SearchParticipant.scheduleDocumentIndexing(SearchDocument, IPath) を使用して、指定された索引内への指定された文書の索引付けのスケジュールを作成します。 文書の索引付けの準備ができると、基礎となっているフレームワークが SearchParticipant.indexDocument(SearchDocument, IPath) を呼び出します。 検索 Participants は、その後、文書の内容を取得し、構文解析して、SearchDocument.addIndexEntry(char[], char[]) を使用して索引の項目を追加します。

索引付けが終了したら、索引の照会、および SearchEngine.search(SearchPattern, SearchParticipant[], IJavaSearchScope, SearchRequestor, IProgressMonitor) を使用した一致の検出が可能になります。 これは、まず最初に SearchParticipant.selectIndexes(SearchPattern, IJavaSearchScope) を使用して、 検索 Participants に、この照会に必要な索引を要求します。 指定されたパターンと一致する索引項目ごとに、検索 Participants に要求することによって、検索文書が作成されます (getDocument(String) を参照)。 これらの文書すべてが検索 Participants に渡されるため、locateMatches(SearchDocument[], SearchPattern, IJavaSearchScope, SearchRequestor, IProgressMonitor) を使用して一致を検出することができます。 検索 Participants は、acceptSearchMatch(SearchMatch) を使用し、SearchMatch のサブクラスのインスタンスを渡すことによって、SearchRequestor に検索での一致を通知します。

検索 Participants は、その作業の一部をデフォルトの Java 検索 Participants に委譲することができます。このデフォルトの Participants のインスタンスは、SearchEngine.getDefaultSearchParticipant() を使用して取得します。 例えば、一致の検出を求められた場合、SQLJ Participants は .sqlj 文書から .java 文書を作成し、 その .java 文書をデフォルトの Participants に渡すことによって、その作業をデフォルトの Participants に 委譲することができます。