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

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

  1. 起動構成
  2. 起動モード
  3. International Components for Unicode for Java (ICU4J)
  4. ランタイム分割

起動構成

構成リソース・マッピングを起動します。

Eclipse 3.2 は、起動構成とリソースを関連付けるための、新しいインフラストラクチャーを提供します。 このマッピングによって、プラットフォームが起動構成上でリソース・ベースのフィルタリングを行うことが可能になり、また関連したプロジェクトが削除されたときに、プラットフォームがオプションで起動構成を削除することが可能になります。 起動ダイアログが拡張され、閉じられた、あるいは削除されたプロジェクトに関連した構成を、オプションで非表示にするフィルターのセットをサポートするようになりました。 また、起動ダイアログは、アクティブなワークベンチ・ウィンドウ内の選択済み作業セットをベースとしたフィルタリングをサポートします。これは、起動ダイアログ内で選択することもできます。

起動構成のためのリソース・マッピングを管理するのは、クライアントの責任です。 API が ILaunchConfigurationWorkingCopy に追加されて構成と関連するリソースを設定するようになり、また、API が ILaunchConfiguration に追加されて、構成と関連するリソースを入手するようになっています。 例えば、起動タブ、起動ショートカットおよびリファクタリング登録プログラムは、マイグレーション中に考慮されなければなりません。 起動構成を作成または変更するコードも、リソース・マッピングを更新する必要があります。

起動構成のマイグレーション・サポート

Eclipse 3.2 は、起動構成をマイグレーションして新しいツールと互換性があるようにするための、新しいインフラストラクチャーを提供します。 例えば、Eclipse 3.2 では、起動構成上でリソース・ベースのフィルターを実行するために、サポートが追加されました。 起動構成は、この新しい機能に効果を与えるリソース・マッピングを提供するために、アップグレードされる必要があります。 ユーザーは、 実行/デバッグ」>「起動」 >「起動構成設定ページから、「Migrate」ボタンを押すことによって、ワークスペース内で起動構成を、手動でマイグレーションできます。

新規のオプション・マイグレーション委譲属性が、launchConfigurationTypes 拡張ポイントに追加されて、新規インターフェース ILaunchConfigurationMigrationDelegate を実装するクラスを指定します。 マイグレーション委譲には、マイグレーション候補を識別して、それらをマイグレーションする責任があります。

起動モード

新規のオプション属性が launchModes 拡張ポイントに追加されて、カスケード起動メニューのアクション・ラベルの外部化を適切にサポートするようになっています。 起動モードをコントリビュートするクライアントは、適切なラベルを指定して、「実行」のような起動カスケード・メニューのために使用する必要があります。 新規属性は launchAsLabel と呼ばれます。 適切なラベルが、実行、デバッグおよびプロファイル起動モードのためのプラットフォームによって提供されました。 下位互換性の場合は、新規属性が起動モードに対して指定されていない場合は、以前のように、「{0} As」を持つ MessageFormat を介して、カスケード・メニュー・ラベルが生成されます。 関連バグ 105235 を参照してください。

International Components for Unicode for Java (ICU4J)

ICU4J は、Unicode、ソフトウェア、グローバリゼーション、および国際化対応に、より包括的なサポートを提供する Java ライブラリーのセットです。 この機能性を Eclipse コミュニティーに提供するために、ICU4J が Eclipse 3.2 のプラットフォームのビルドに追加されました。 com.ibm.icu という名前のプラグインとして、ビルドに表示されます。 Eclipse プラットフォームは、Eclipse 3.2 で ICU API を使用します。

マイグレーション

アプリケーション・コードのマイグレーションを付加的に行うことができます。これは、ICU4J 使用の利点を得るために必ずしもすべての ICU4J 機能を採用する必要はないことを意味します。 ICU4J を使用するためにユーザーのコードをマイグレーションする方法について詳しくは、Eclipse Wiki の ICU4J ページを参照してください。

ICU4J 置換プラグイン

ICU4J プラグインの追加により、約 3MB の追加占有スペースが必要になります。 ICU4J 機能の採用よりもアプリケーション・サイズを重視する場合、アプリケーションによっては ICU4J の組み込みが望ましくない場合があります。 このような場合、Eclipse プラットフォーム・ビルド・ページから置換プラグイン (com.ibm.icu.base) を使用することができます。プラグインをダウンロードして、/plugins ディレクトリーから com.ibm.icu プラグインとそのソース対応物を除去し、置換プラグインにドロップインします。 Eclipse プラットフォームは ICU API for 3.2 を採用しているため、単に ICU プラグインを除去すると、プラットフォーム・コードでコンパイル・エラーが発生するので、このようにする必要があります。 置換プラグインのサイズは約 100KB で、ICU4J で最も一般的に使用されるクラスおよび API のデフォルト JDK の実装のみを呼び出します。 ICU 置換プラグインの使用に関する詳細は、再度、Eclipse Wiki の ICU4J ページをお読みください。

JFace に及ぼす影響 - ViewerSorter および StructuredViewer

JFace で ICU4J をサポートするには、API で ICU クラスの参照を防ぐために、いくつかの独自の API を追加する必要がありました。 これにより、以下のものが追加されました。

  1. org.eclipse.jface.viewers.ViewerComparator と呼ばれる新規クラス。そのうち org.eclipse.jface.viewers.ViewerSorter は現在サブクラスです。
  2. org.eclipse.jface.viewers.StructuredViewer への 2 つの新規メソッド。org.eclipse.jface.viewers.ViewerComparator の追加をサポートします。

Rationale

ViewerSorter クラスには、java.text.Collator を戻す public メソッド getCollator() があります。 このメソッドは API であるので、ICU コレーターを使用するためにそれを簡単には変更できませんでした。 また、ICU 上の直接のプラグイン依存関係は、(SWT で) JFace がスタンドアロンで使用されるのを防止するため、ICU クラスは、API (シグニチャー) の一部にすることはできません。 これらの制約に対応するために、ICU コレーターではなく、java.util.Comparator を使用する ViewerComparator クラスが追加されました。 ICU コレーター・クラスが java.util.Comparator を実装するので、このクラスが追加されました。これにより、いずれの StructuredViewerjava.text.Collator ではなく ICU コレーターを使用できますが、JFace は、ICU4J プラグインへの依存関係を追加する必要はありません。 StructuredViewer に追加された 2 つの新規のメソッドは、ViewerSorter ではなく ViewerComparator を通してビューアーのコンテンツをソートするために ICU コレーターの使用をサポートします。 現在、いずれの StructuredViewer も、getSorter() および setSorter(ViewerSorter) メソッドではなく、これらのメソッドを使用して、ビューアーのソーター (コンパレーター) を get/set することをお勧めします。

ランタイム分割

新規ランタイム API

org.eclipse.equinox.common バンドルには、共通名を持ついくつかの新規 API クラス (例えば、Assert および ListenerList) が組み込まれています。 コードに同じ名前を持つクラスがある場合に、ローカル・クラスとランタイムからのクラスの両方のインポートにインポート * ステートメントを使用すると、以下のエラー・メッセージが表示される場合があります。

   The type ABC is ambiguous
  

インポートを編成し、適切なインポート元を選択することで、この問題は解決します。

カスタム・ビルド・スクリプト内の明示的クラスパス

新規ランタイム・プラグインにコードが移動されたため、カスタム・スクリプトが明示的に org.eclispe.core.runtime を参照する場合は、以下のプラグインを 1 つ以上追加しなければならない可能性があります。