このセクションでは、3.0 のメカニズムと、API を採用するように 2.1 プラグインを変更する場合に必要な変更について説明します。
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 ランタイム・ピクチャーでは、これらの役割および責任は、いくつかのオブジェクトに明確に分けられます。
Plugin も BundleActivator をインプリメントします。 これは、プラグインのライフ・サイクルおよびセマンティックを代表するオブジェクトが、中央に 1 つあるのが便利だと認識します。ただし、これは、今日のプラグインで一般的になっている、必要性の有無を考慮せずにデータ構造を初期化することを 是認するものではないことに注意してください。他のプラグインでクラスが検査されているときに、 関連性の低いクラスが参照されるために、プラグインが活動化される可能性があることに十分注意してください。つまり、プラグインが活動化されただけで、その機能が必要とされていることを意味しているとは限りません。また、別の BundleActivator クラスを定義するか、 またはバンドル・アクティベーターを全く持たないことができることにも注意してください。
2.x の Plugin クラスを Eclipse 3.0 に移植するために必要なステップは、そのクラスが何を行うかによって異なります。上で概説したように、開始時のライフ・サイクル作業のほとんどは、以下のカテゴリーのいずれかに入ります。
新しいランタイムでは、プラグインの実行に必要な情報と構造、およびプラグインの拡張や拡張ポイントに関連する情報 と構造は分離されています。 前者は、OSGi フレームワーク仕様によって定義および管理されます。 後者は、Eclipse 固有の概念で、Eclipse ランタイム・コードによって追加されます。 したがって、オリジナルのプラグイン・レジストリーおよび関連するオブジェクトは、OSGi のバンドル と Eclipse の拡張レジストリー に分けられています。
実行の仕様に関係する IPluginRegistry のパーツ (例えば、IPluginDescriptor、ILibrary、IPrequisite など) は推奨されなくなり、拡張と拡張ポイントに関連するその他のパーツは、IExtensionRegistry に移動されています。また、プラグイン・レジストリーに関連する、いわゆるモデル・オブジェクトは、全体として現在では推奨されていません。これらの型は、主に PDE などのツールをサポートするためのものであり、ランタイムによってインスタンス化されていました。 残念なことに、必要とされる情報のレベルがランタイムの能力または関心を超え (例えば、plugin.xml エレメントの行数の記憶など)、最終的に、ランタイムの情報の潜在的な利用者による独自の構造の保守が必要とされることが頻繁にありました。
新しいランタイムでは、ランタイムによって提供されていた機能を再評価し、 現在では、ランタイムの実行に欠かせないか、または他で行うのは非常に難しいものだけを提供するようになっています。 前述のように、プラグイン・レジストリー・モデル・オブジェクトは、プラグイン構文解析 API があるために推奨されなく なりました。新しい拡張レジストリーは、非常に重要な拡張関連の情報を保守します。新しい状態 (org.eclipse.osgi.service.resolver.State と関連情報を参照) の構造体によって、重要な実行関連の情報の操作が表され、使用可能にされます。
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 フラグメントを使用することはできません。 フラグメントを新しい構造体に更新する必要があります。
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 に移動されています。
(両方のクラスの) getDeclaringPlugin()
メソッドは、それぞれ拡張または拡張ポイントを宣言するプラグインへの上向きのリンクを提供します。
新しいレジストリー・モデルによって、プラグインの実行に関する局面が拡張/拡張ポイントに関する局面から
分離され、IPluginDescriptors が含まれなくなっています。
この API のユーザーは、IExtension および IExtensionPoint の両方にある新しいメソッド getParentIdentifier() について考慮する必要があります。
オリジナルのランタイムでは、プラグイン・レジストリーは、ランタイム構成の全体像を保守していました。Eclipse 3.0 では、この全体像は OSGi フレームワークと拡張レジストリーに分割されています。したがって、これらのクラスは推奨されなくなりました。 非推奨に関する注意事項に、コードの更新方法の詳細が記載されています。
新しいランタイムでは、Plugin オブジェクトはランタイムによって管理されなくなっているため、 一般的に Platform を介してアクセスすることができません。 同様に、プラグイン・レジストリーは存在しなくなり、プラグイン記述子へのアクセスも提供しません。ただし、適切な置換メソッドが使用可能です。詳細は、これらのクラスの非推奨のメソッドに関する Javadoc に記載されています。
このパッケージのすべての型は、現在では推奨されていません。 詳しくは、『レジストリー』の説明を参照してください。
IWorkspace.run(IWorkspaceRunnable,IProgressMonitor) メソッドのクライアントは、このメソッドの使用方法を見直し、より高度なメソッドである IWorkspace.run(IWorkspaceRunnable,ISchedulingRule,int,IProgressMonitor) の使用を考慮する必要があります。 古い IWorkspace.run メソッドでは、IWorkspaceRunnable の実行中は、ワークスペース全体がロックされました。このことはつまり、このメソッドと共に行われる操作は、ワークスペースを変更する他の操作とは、並行して実行できないことを意味します。Eclipse 3.0 では、長期に渡る多くの運用がバックグラウンド・スレッドに移動されたため、このような操作の競合の可能性が大幅に増加しています。 形式指定のフォアグラウンド操作が長期に渡るバックグラウンド運用によってブロックされると、UI は、フォアグラウンド操作が完了するか、それらの操作のいずれかがキャンセルされるまでブロックされます。
推奨される解決策としては、スケジュール・ルール・パラメーターを使用する新しいメソッドを使用するように、
古い IWorkspace.run に対するすべての参照を切り替えます。
スケジュール・ルールは、その操作によるすべての変更のためのルールを含む最も詳細なルールです。操作によって
スケジュール・ルールの範囲外のリソースが変更されようとすると、ランタイム例外が発生します。指定されたワークスペース操作が必要とするスケジュール・ルールが、正確に指定されず、指定されたプロジェクトにインストール済みのリポジトリー・プロバイダーに従って変更される可能性があります。
ファクトリー IResourceRuleFactory
は、リソース変更操作のためのスケジュール・ルールの取得に使用されます。
必要に応じて、複数のリソース規則を指定するために MultiRule を使用したり、さまざまなリソース変更操作からの規則を組み合わせるために便利な MultiRule.combine メソッドを使用することもできます。
非ロック式が必要な場合は、null のスケジュール・ルールを使用します。 これにより、実行可能ファイルはワークスペース内のすべてのリソースを変更することができますが、他のスレッドが並行してそのワークスペースを変更することは回避されません。 ワークスペースに対する簡単な変更の場合には、これが最も容易で、最も並行性に適した解決策となります。
selection
から filteredSelection
を計算する必要があります。IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
IStructuredSelection filteredSelection = selection;
List selectedResources = IDE.computeSelectedResources(currentSelection);
if (!selectedResources.isEmpty()) {
filteredSelection = new
StructuredSelection(selectedResources);
}
if (selection.isEmpty()) { IWorkbenchWindow window = PlatformUI.getWorkbench().getActiveWorkbenchWindow(); if (window != null) { IWorkbenchPart part = window.getPartService().getActivePart(); if (part instanceof IEditorPart) { IEditorInput input = ((IEditorPart) part).getEditorInput(); if (input instanceof IFileEditorInput) { selection = new StructuredSelection(((IFileEditorInput) input).getFile()); } } } }
IActionBars actionBars= getActionBars(); if (actionBars != null) { actionBars.setGlobalActionHandler(IDEActionFactory.ADD_TASK.getId(), getAction(textEditor, IDEActionFactory.ADD_TASK.getId())); actionBars.setGlobalActionHandler(IDEActionFactory.BOOKMARK.getId(), getAction(textEditor, IDEActionFactory.BOOKMARK.getId())); }
現在、注釈タイプには明示的な概念があります。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 は、このインターフェースをインプリメントします。
注釈タイプは、関連するマーカー注釈仕様を検索するために使用するキーです。 注釈タイプは他の注釈タイプを拡張できるため、マーカー注釈仕様の間にも暗黙の関係があります。 したがって、指定された注釈タイプのマーカー注釈仕様は、その指定された注釈タイプのスーパー・タイプに指定されたマーカー注釈仕様によって完成されます。したがって、マーカー注釈仕様は、以前必要とされたように完全である必要はありません。 マーカー注釈仕様は、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) が戻されます。
以下の注釈タイプは、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 をインプリメントする必要があります。
3.0 で拡張可能な起動モードが導入されたため、1 つの起動構成型に対して複数の起動代行が存在することができます。3.0 より前のリリースでは、起動構成型ごとに 1 つの起動代行しかサポートされていませんでした。メソッド ILaunchConfigurationType.getDelegate()
は、現在では推奨されていません。代わりに、メソッド getDelegate(String mode)
を使用して、特定の起動モードの起動代行を検索する必要があります。
推奨されないメソッドは、run
モードの起動代行を戻すように変更されています。
起動タブ・グループおよび起動タブは、起動が完了時に通知されなくなりました。
インターフェース ILaunchConfigurationTab
および ILaunchConfigurationTabGroup
の中のメソッド launched(ILaunch)
は、推奨されなくなり、呼び出されなくなりました。
タブは、起動ダイアログから起動が実行された場合にのみ存在するため、起動機能に関してこのメソッドに依存することは、常に問題でした。また、バックグラウンド起動の導入で、結果の起動オブジェクトが存在しないうちに起動ダイアログが閉じられるため、このメソッドは呼び出されなくなりました。
ILaunchConfigurationTab
インターフェースに、活動と非活動の 2 つのメソッドが追加されました。これらの新しいライフサイクル・メソッドは、それぞれ、タブの入力時と終了時に呼び出されます。デバッグ・プラグイン (AbstractLaunchConfigurationTab
) によって提供される抽象クラスのサブクラスである ILaunchConfigurationTab
の既存の実装は、そのメソッドが抽象クラス内に実装されるためバイナリー互換です。
以前のリリースでは、タブが活動化されたときにはメッセージ initializeFrom
が、非活動化されたときには performApply
がタブに送信されていました。
この方法により、起動構成タブのフレームワークは、(タブの終了時に現行の属性値で構成を更新し、新しく入力されたタブを更新することによって) 起動構成を介したタブ間の通信を提供していました。しかし、多くのタブはタブ間の通信を行わないため、この方法が非効率である場合があります。また、活動化されているタブと、初めて選択された起動構成を表示しているタブを区別する方法はありませんでした。新しく追加されたメソッドにより、タブは、活動化と初期化、および非活動化と現行値の保管を区別できるようになりました。
抽象タブによって提供される activated
のデフォルトの実装は、initializeFrom
を呼び出します。また、deactivated
のデフォルトの実装は、performApply
を呼び出します。新しい API の利点を活用しようとするタブは、必要に応じてこれらのメソッドをオーバーライドする必要があります。
一般的に、タブ間の通信を行わないタブに推奨される方法は、これらのメソッドが何も行わないように再実装することです。
以前のリリースでは、起動構成属性 ATTR_TARGET_DEBUG_PERSPECTIVE
および ATTR_TARGET_RUN_PERSPECTIVE
を介して、起動構成でパースペクティブ切り替えが指定されました。3.0 で拡張可能な起動モードが追加されたため、この方法はスケーリングされなくなりました。
パースペクティブ切り替えは、現在では、起動構成型がサポートするそれぞれの起動モードごとに、起動構成型を基にして指定されます。特定の起動モードの起動構成型に関連したパースペクティブを設定および取得するために、DebugUITools
に API が追加されています。
launchConfigurationTabGroup
拡張ポイントに追加のオプションの launchMode
エレメントが追加され、提供されたタブ・グループが、起動構成型およびモードのデフォルトのパースペクティブを指定できるようになっています。
ユーザーは、Eclipse ユーザー・インターフェースから、起動構成ダイアログを開き、(個々の構成ではなく) ツリー内の起動構成型ノードを選択することによって、起動構成型に関連するパースペクティブを編集することができます。タブが表示され、ユーザーは、サポートされる各起動モードでパースペクティブを設定できます。
VMRunnerConfiguration
クラスには、環境変数の設定および検索をサポートするためのメソッドが 2 つ追加されています。IVMRunner
の実装は、VMRunnerConfiguration.getEnvironment()
を呼び出し、その環境を実行 JVM に渡します。DebugPlugin.exec(String[]
cmdLine, File workingDirectory)
を使用するクライアントは、代わりに DebugPlugin.exec(String[]
cmdLine, File workingDirectory, String[] envp)
を呼び出すことによってこれを行うことができます。getEnvironment()
の結果を渡すだけで十分です。
以前のリリースでは、VMRunnerConfiguration
にはブート・パスを記述する単一の属性がありました。その属性は、-Xbootclasspath
引数で指定される、Strings
のコレクションです。JVM をサポートするために、VMRunnerConfiguration には、ブート・パスの前および後に付加できる 3 つの新しい属性が追加されています。
追加された新しいメソッド/属性は、以下のとおりです。
getPrependBootClassPath()
- ブート・パスの前に付けられるエントリーのコレクションを戻します (-Xbootclasspath/p
引数)。
getMainBootClassPath()
- ブート・パス上に置かれるエントリーのコレクションを戻します (-Xbootclasspath
引数)。
getAppendBootClassPath()
- ブート・パスの後に付けられるエントリーのコレクションを戻します (-Xbootclasspath/a
引数)。旧属性 getBootClassPath()
もまだ存在し、3 つの新属性と同等の完全なパスが含まれます。ただし、新しいブート・パス・オプションをサポートする VMRunners
は、新規属性の利点を活用します。
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
のサブクラスで
置き換えられる必要があります。WorkingCopyOwner
は IBufferFactory
自体は
インプリメントしませんが、IBufferFactory
をインプリメントする WorkingCopyOwner
の
サブクラスを宣言して、新旧間を橋渡しします (IBufferFactory
は createBuffer(IOpenable)
を宣言し
、WorkingCopyOwner
は createBuffer(ICompilationUnit)
を宣言し、ICompilationUnit
は IOpenable
を拡張します)。
IWorkingCopy
と IBufferFactory
が関与する変更は、相互に影響するため、両方を同時に扱うことをお勧めします。
非推奨の詳細は、以下のとおりです。
IWorkingCopy
(パッケージ org.eclipse.jdt.core
)
public void commit(boolean, IProgressMonitor)
は、推奨されなくなりました。
ICompilationUnit
で直接提供されます。public void commitWorkingCopy(boolean, IProgressMonitor)
wc.commit(b,monitor)
を ((ICompilationUnit)
wc).commitWorkingCopy(b,monitor)
として書き直します。public void destroy()
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public void discardWorkingCopy(boolean, IProgressMonitor)
wc.destroy()
を ((ICompilationUnit)
wc).discardWorkingCopy()
として書き直します。public IJavaElement findSharedWorkingCopy(IBufferFactory)
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public ICompilationUnit findWorkingCopy(WorkingCopyOwner)
IBufferFactory
は WorkingCopyOwner
に置き換えられます。public IJavaElement getOriginal(IJavaElement)
は推奨されなくなりました。
IJavaElement
で提供されます。
public IJavaElement getPrimaryElement()
wc.getOriginal(elt)
を elt.getPrimaryElement()
として書き直します。IWorkingCopy.getOriginal
とは異なり、受信側が作業用コピーでない場合、IJavaElement.getPrimaryElement
は null
を戻しません。public IJavaElement getOriginalElement()
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public ICompilationUnit getPrimary()
wc.getOriginalElement()
を ((ICompilationUnit)
wc).getPrimary()
として書き直します。IWorkingCopy.getOriginalElement
とは異なり、受信側が作業用コピーでない場合、IWorkingCopy.getPrimary
は null
を戻しません。public IJavaElement[] findElements(IJavaElement)
は推奨されなくなりました。
ICompilationUnit
で直接宣言されます。wc.findElements(elts)
を ((ICompilationUnit)
wc).findElements(elts)
として書き直します。public IType findPrimaryType()
は推奨されなくなりました。
ICompilationUnit
で直接宣言されます。wc.findPrimaryType()
を ((ICompilationUnit)
wc).findPrimaryType()
として書き直します。public IJavaElement getSharedWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
IBufferFactory
が WorkingCopyOwner
に置き換えられます。public IJavaElement getWorkingCopy()
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public ICompilationUnit getWorkingCopy(IProgressMonitor)
wc.getWorkingCopy()
を ((ICompilationUnit)
wc).getWorkingCopy(null)
として書き直します。public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory, IProblemRequestor)
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProblemRequestor, IProgressMonitor)
IBufferFactory
が WorkingCopyOwner
に置き換えられます。public boolean isBasedOn(IResource)
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public boolean hasResourceChanged()
wc.isBasesOn(res)
を ((ICompilationUnit)
wc).hasResourceChanged()
として書き直します。public boolean isWorkingCopy()
は推奨されなくなりました。
ICompilationUnit
で直接宣言されます。wc.isWorkingCopy()
を ((ICompilationUnit)
wc).isWorkingCopy()
として書き直します。public IMarker[] reconcile()
は推奨されなくなりました。
ICompilationUnit
で直接提供されます。public void reconcile(boolean,IProgressMonitor)
wc.reconcile()
を ((ICompilationUnit)
wc).reconcile(false, null)
として書き直します。null
を戻しましたが、置換メソッドは結果を戻しません。public void reconcile(boolean, IProgressMonitor)
は、推奨されなくなりました。
ICompilationUnit
で直接宣言されます。wc.reconcile(b,monitor)
を ((ICompilationUnit)
wc).reconcile(b.monitor)
として書き直します。public void restore()
は推奨されなくなりました。
ICompilationUnit
で直接宣言されます。wc.restore()
を ((ICompilationUnit)
wc).restore()
として書き直します。IType
(パッケージ org.eclipse.jdt.core
)
public ITypeHierarchy newSupertypeHierarchy(IWorkingCopy[],
IProgressMonitor)
は推奨されなくなりました。
public ITypeHierarchy newSupertypeHierarchy(c,
IProgressMonitor)
IWorkingCopy[]
を ICompilationUnit[]
にキャストすることは不可能です。public ITypeHierarchy newTypeHierarchy(IWorkingCopy[],
IProgressMonitor)
は推奨されなくなりました。
public ITypeHierarchy newTypeHierarchy(ICompilationUnit[],
IProgressMonitor)
IWorkingCopy[]
を ICompilationUnit[]
にキャストすることは不可能です。IClassFile
(パッケージ org.eclipse.jdt.core
)
public IJavaElement getWorkingCopy(IProgressMonitor,
IBufferFactory)
は推奨されなくなりました。
public ICompilationUnit getWorkingCopy(WorkingCopyOwner,
IProgressMonitor)
IBufferFactory
が WorkingCopyOwner
に置き換えられます。JavaCore
(パッケージ org.eclipse.jdt.core
)
public IWorkingCopy[] getSharedWorkingCopies(IBufferFactory)
は推奨されなくなりました。
public ICompilationUnit[]
getWorkingCopies(WorkingCopyOwner)
IBufferFactory
は WorkingCopyOwner
に置き換えられます。ICompilationUnit[]
を IWorkingCopy[]
にキャストすることは不可能です。SearchEngine
(パッケージ org.eclipse.jdt.core.search
)
public SearchEngine(IWorkingCopy[])
は推奨されなくなりました。
public SearchEngine(ICompilationUnit[])
IWorkingCopy[]
を ICompilationUnit[]
にキャストすることは不可能です。org.eclipse.help プラグインは、以前はヘルプ・システムを提供および拡張し、ヘルプを表示するための API と拡張ポイントを保持していましたが、現在は、ヘルプ・リソースを提供し、 ヘルプ・リソースにアクセスするための API と拡張ポイントだけが含まれています。そのプラグインに含まれるデフォルトのヘルプ UI 実装部分は、その実装を拡張する API と一緒に新規プラグイン org.eclipse.help.base に移されています。 ヘルプ UI の提供およびヘルプ表示のための API と拡張ポイントは、org.eclipse.ui プラグインに 移されています。この再構築によって、アプリケーションのヘルプ・システムに関する柔軟性が大幅に向上しています。新しい構造によって、汎用のワークベンチに基づいたアプリケーションでは、独自のヘルプ UI やヘルプの実装を提供したり、ヘルプ・システム全体を 省略できるようになります。
影響を受ける拡張ポイントおよび API パッケージは、ヘルプ・システム自体による使用のみを目的としていたため、 既存のプラグインがこの変更の影響を受けることはほとんどありません。念のために、これらの拡張ポイントおよび API パッケージを以下に示します。
3.0 では、カスタム検索をインプリメントする新規 API が追加されています。オリジナルの API は 3.0 では 推奨されておらず、クライアントは、パッケージ org.eclipse.search.ui および org.eclipse.search.ui.text 内の 新規 API に移植することをお勧めします。
クライアントは、ISearchQuery
、ISearchResult
、および ISearchResultPage
の実装を作成する必要があります。ISearchResultPage
の実装は、その後、
新しい org.eclipse.search.searchResultViewPages
拡張ポイントに組み込む必要があります。
ISearchResult
および ISearchResultPage
のデフォルトの実装は、
パッケージ org.eclipse.search.ui.text
で提供されます。
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++ の開発」と呼ばれるアクティビティーと関連付けられる場合があります)。
IBreakpointManager は、メソッド setEnabled(boolean) および isEnabled() を定義するようになりました。ブレークポイント・マネージャーが使用不可になると、デバッガーはすべての登録済みのブレークポイントを無視します。デバッグ・プラットフォームも、新規のリスナー・メカニズム、IBreakpointManagerListener を提供します。これにより、クライアントは、 使用可能性が変更されたときに通知されるように、ブレークポイント・マネージャーに登録することができます。ブレークポイント・ビューは、この API を新規のトグル・アクションから呼び出します。 このアクションによって、ユーザーは、「すべてのブレークポイントをスキップ」することができます。このため、ブレークポイント・マネージャーの使用可能性を受け入れない デバッガーには、ユーザーがこの機能を使用として何か失敗したように見えます。
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 に 委譲することができます。