Eclipse 3.0 と 3.1 の間の非互換性

Eclipse の変更に伴い、3.0 と 3.1 の間には互換性がなくなったため、プラグインはその影響を受けます。以下の項目で、変更された領域、および 3.0 のプラグインを 3.1 にマイグレーションする手順について説明します。3.0 のプラグインを 3.1 で実行していて問題が生じる場合は、ここを調べるだけで十分です。

  1. プラグイン設定
  2. IPath 制約に対する変更
  3. 拡張レジストリー
  4. コード・フォーマッター・オプション
  5. API 規約の変更 - AntCorePreferences
  6. API 規約の変更 - JFace の Policy クラス
  7. API 規約の変更 - ヌル・デフォルト・パースペクティブの許可
  8. API 規約の変更 - IViewLayout
  9. API 規約の変更 - IVMInstall
  10. SelectionEnabler.SelectionClass がパッケージ可視になった
  11. ContributionItem.getParent() がヌルを戻せるようになった
  12. IPropertySource および IPropertySource2 の isPropertySet(boolean) の変更
  13. org.eclipse.ui.commands 拡張ポイントから削除された handlerSubmission 要素
  14. TeamUI 内の final ではなかった静的 API フィールド GLOBAL_IGNORES_CHANGED が final になった
  15. Team UI 内の FillLayout を使用する ClassCastException
  16. 廃棄された親を使用したウィジェットの作成

1. プラグイン設定

影響を受けるもの: Plugin#initializeDefaultPreferences をオーバーライドして、そのデフォルトのプラグイン設定値を初期化するプラグイン、または設定変更リスナーを使用するプラグイン。

説明: Eclipse 3.1 では、org.eclipse.ui.plugin.AbstractUIPlugin#getPreferenceStore から取得される org.eclipse.jface.preference.IPreferenceStore オブジェクトはマイグレーションされ、org.eclipse.core.runtime プラグインによって提供される新しい 3.0 Eclipse 設定フレームワークの上位で存続するようになりました。

必要な処置: その結果、設定 API を使用しているクライアントは、以下の 2 つの考えられる問題を検査する必要があります。

  1. 設定変更イベントに含まれているオブジェクトの型は保証されません。イベントの古い値と新しい値の両方が、ヌル、ストリング、または型付きオブジェクトになる可能性があります。したがって、クライアントが有効であるためには、設定変更リスナーが、考え得るこれら 3 つのすべての状態を処理できる必要があります。
  2. プラグインが org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences を使用する場合は、org.eclipse.core.runtime.compatibility プラグインを必須プラグイン・リストに組み込む必要があります。これは、この依存関係が org.eclipse.ui.workbench プラグインから除去されたためです。

詳しくは、『設定ストア』を参照してください。

2. IPath 制約に対する変更

影響を受けるもの: IPath オブジェクトを作成、操作、または保管するプラグイン。

説明: Eclipse 3.0 の IPath では、パスのセグメントに関する制限が多く、基礎となるオペレーティング・システムでの制限よりも厳しくなっていました。これは、以下のような制限でした。

Eclipse 3.1 では、プラットフォームのデータ・ロケーション (ワークスペース) が、このような制限のないファイル・システムにある場合に、これらの制限が除去されました。

必要な処置: 拡張されたパス範囲の適切な処理を有効にするためには、プラグイン内での Path および IPath のすべての使用を検討し、以下のように更新する必要があります。ほとんどの未変更のプラグインは、3.0 で正しいと見なされていたすべてのパスに対して 3.0 と同じように振る舞います。 ただし、上記の変更を行わない限り、3.1 では正しいと見なされるけれど、3.0 では正しくないと見なされていたパスが関係する場合に、プラグインが失敗する可能性があります。

パスのストリング表記を異なるプラットフォーム間で読み取り可能な形式で保管するプラグインは、新しい Path.fromPortableString ファクトリー・メソッドにマイグレーションする必要があります。このメソッドは、プラットフォーム独立形式の IPath インスタンスを作成します。パスのこのストリング表記は、IPath.toPortableString メソッドを使用して作成できます。 影響を受けるメタデータ・ファイルの例として、 Eclipse ワークスペース・プロジェクト内に保管されるファイル (.project、.classpath など)、および設定ストア (org.eclipse.core.runtime.preferences.IPreferencesService) に保管されるすべてのパスなどがあります。

注: fromPortableString は、Eclipse 3.0 IPath.toString メソッドを使用して作成したすべてのパス・ストリングを正常に読み取りますが、Eclipse 3.1 toString メソッドを使用して作成したものは正常に読み取りません。したがって、ほとんどの場合、既存のメタデータ・ファイル・フォーマットに対する変更は不要です。 ただし、toPortableString でパスの書き込みを始め、fromPortableString でパスの読み取りを始める必要があります。

「:」および「¥」がすべてのプラットフォームで特別な意味を持つと想定していた、ハードコーディングされた文字列リテラルからパスを作成していたプラグインは、マイグレーションする必要があります。最も簡単なソリューションは、ストリング・パス・リテラルをすべてのプラットフォームでサポートされるサブセットに制限する (コロンおよび円記号を使用しない) ことです。パス・リテラルは、Path.toPortableString で作成される移植可能なパス・ストリング形式を使用することによって、有効な UNIX パスの完全なセットをサポートできます。この形式は、最初の単一コロン (「:」) を装置セパレーター、スラッシュ (「/」) をセグメント・セパレーター、および二重コロン (「::」) をリテラル・コロン文字として解釈します。例えば、コード new Path("c:/temp") は、UNIX プラットフォーム上で 2 つのセグメントを持つ相対パスを作成します。同様に、new Path("a¥¥b") は、UNIX プラットフォーム上で 1 つのセグメントを持つパスを、また Windows 上では 2 つのセグメントを持つパスを作成します。

「:」および「¥」がすべてのプラットフォームで特別な意味を持つと想定していた、IPath.append(String) メソッドを使用してパスを構成するプラグインは、コードを更新する必要があるでしょう。 Eclipse 3.1 では、このメソッドは、オペレーティング・システム固有の装置区切り文字およびセグメント区切り文字を使用して、提供されるパス・ストリングを解釈します。例えば、UNIX プラットフォーム上で append("a¥¥b") を呼び出すと、1 つのセグメントが追加されるようになりました。一方、Windows では、引き続き 2 つのセグメントが追加されます。

プラットフォームによって読み取られ、解釈されるデータ・ファイルは、すべてのプラットフォームにおいて、':' および '¥' を特殊文字として扱わなくなります。複数のプラットフォームで読み取ることのできるデータ・ファイルに保管されているすべてのパスは、移植可能な形式をしている必要があります。例えば、plugin.xml 内のアイコン・ファイルのパスやその他のパスは、パス・セグメントのセパレーターとして '/' のみを使用する必要があります。

3. 拡張レジストリー

影響を受けるもの: Eclipse プラットフォームのプラグインまたは拡張レジストリーの IExtensionPointIExtension、および IConfigurationElement オブジェクトを操作または保存するプラグイン。

説明: 3.0 以前は、(以前のプラグイン・レジストリーの) 拡張レジストリーから取得されたすべてのオブジェクトは、永久に有効でした。Eclipse 3.0 では、Eclipse を再始動せずにプラグインの動的な追加または除去を許可していましたが、それが変更されました。再始動せずにプラグインを除去すると、拡張レジストリー内の項目は必然的に無効になります。つまり、削除されたプラグインの拡張レジストリー項目から以前に取得されたオブジェクトを保持している別のプラグインは、無効なオブジェクトを保持したままになります。クライアントが得られる唯一のヒントは、IRegistryChangeEvent を listen することで得られます。 この問題は Eclipse 3.0 から存在していましたが、Eclipse を再始動しないでプラグインを除去するのは極めて例外的であるため、実際に問題が発生することはほとんどありませんでした。

この問題は 3.1 で、以下のように改善されました。

必要な処置: プラグインを動的に認識されるようにする (つまり、プラグインのオンザフライ追加または除去に対応可能にする) 必要がある場合は、他のプラグインをソースとする IExtensionPointIExtension、および IConfigurationElement オブジェクトを処理するコードを、検査済みの例外であるかのようにして IRegistryChangeEvent を catch するよう変更する必要があります。例外 (isValid() 事前チェックではなく) を catch することは、プラグインが並行スレッドによって除去される場合に対応するための唯一の確実な方法です (これが発生する場合、これはほぼ間違いなく唯一の確実な方法です)。

4. コード・フォーマッター・オプション

影響を受けるもの: Java コード・フォーマッター・オプションにプログラマチックにアクセスするプラグイン。

説明: Eclipse 3.0 では、コード・フォーマッター・オプション org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR の値は、TAB または SPACE のみでした。仕様では、値の型が将来のリリースで拡張される可能性のある列挙型であるということは明示されていませんでした。Eclipse 3.1 では、バグ 73104 に対処するために 3 番目の可能な値 MIXED が追加されました。 仕様は、この新しい値が組み込めるよう、また将来さらに多くの値が追加できるように変更されました。

必要な処置: このコード・フォーマッター・オプションをプログラマチックに読み取ったり設定するクライアントは、新しい 3 番目の値を考慮に入れるようコードを検査する必要があります。また、コードが予期しないオプション値に遭遇した場合に、正しく障害を報告するような頑強な方法でコードを作成する必要があります。

5. API 規約の変更 - AntCorePreferences

影響を受けるもの: org.eclipse.ant.core.AntCorePreferences をサブクラス化またはインスタンス化するプラグイン。

説明: Eclipse 3.0 では、クラス org.eclipse.ant.core.AntCorePreferences は、クライアントがインスタンス化またはサブクラス化してはならないとマークされていませんでした。これは、サブクラス化またはインスタンス化を目的としていないとマークされたクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。

必要な処置: org.eclipse.ant.core.AntCorePreferences のインスタンスをプログラマチックに作成するクライアントのコードを、org.eclipse.ant.core.AntCorePlugin.getPreferences() を使用して設定を検索するようマイグレーションする必要があります。サブクラスは、org.eclipse.ant.core.AntCorePreferences をサブクラス化しないよう作り直す必要があります。

6. API 規約の変更 - JFace の Policy クラス

影響を受けるもの: ワークベンチによって設定される JFace ログをオーバーライドする RCP アプリケーション。

説明: Eclipse 3.0 では、ワークベンチは、ワークベンチ・プラグインのログを直接 org.eclipse.jface.util.Policy.setLog(ILog) に渡すことによって、JFace エラーを記録するためのログとしてワークベンチのログを設定していました。3.1 では、Eclipse ランタイムの外部で SWT および JFace を使用するスタンドアロン・アプリケーションを有効にするために、ILog への依存関係が JFace から除去されました。JFace のニーズに応えるため、新しいインターフェース ILogger が導入されました。ワークベンチ ILog をラッピングする ILogger を提供するよう、ワークベンチが変更されました。詳細については、バグ 88608 を参照してください。

必要な処置: ほとんどの RCP アプリケーションは、ワークベンチによって設定されたログをオーバーライドする必要はありませんが、以前に Policy.setLog(ILog) を呼び出していた場合は、ILogger を代わりに渡すよう変更する必要があります。

7. API 規約の変更 - ヌル・デフォルト・パースペクティブの許可

影響を受けるもの: 非ヌル・デフォルト・パースペクティブを予期する RCP アプリケーション。

説明: 開いているパースペクティブがない空のウィンドウ (機能拡張 71150) で RCP アプリケーションを開始できるようにするために、ヌルを戻せるよう WorkbenchAdvisor.getInitialWindowPerspectiveId() および IPerspectiveRegistry.getDefaultPerspective() が変更されました。IDE では、常にデフォルト・パースペクティブがあるため、IPerspectiveRegistry.getDefaultPerspective() はヌルを戻しません。同様に、既存の RCP アプリケーションが以前から、WorkbenchAdvisor.getInitialWindowPerspectiveId() で非ヌル値を戻していた場合、IPerspectiveRegistry.getDefaultPerspective() は引き続き非ヌル値を戻します。

必要な処置: クライアントで必要な処置はありません。

8. API 規約の変更 - IViewLayout

影響を受けるもの: org.eclipse.ui.IViewLayout を実装するプラグイン。

説明: Eclipse 3.0 では、クラス org.eclipse.ui.IViewLayout は、クライアントが実装してはならないとマークされていませんでした。これは、クライアントによる実装を目的としていないとマークされたクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。

必要な処置: org.eclipse.ui.IViewLayout を実装しないよう、実装クラスを作り直す必要があります。

9. API 規約の変更 - IVMInstall

影響を受けるもの: org.eclipse.jdt.launching.IVMInstall を実装するプラグイン。

説明: Eclipse 3.0 では、クラス org.eclipse.jdt.launching.IVMInstall は、クライアントが直接実装してはならないとマークされていませんでした。これは、クライアントによる直接実装を目的としていないとマークされたクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。バイナリー互換性を維持するために、クライアントでこのインターフェースを直接実装することは依然として可能ですが、それよりもクライアントで org.eclipse.jdt.launching.AbstractVMInstall をサブクラス化することを強くお勧めします。IVMInstall を実装するクライアントは、新規のオプション・インターフェースである org.eclipse.jdt.launching.IVMInstall2 も実装する必要があります。このインターフェースは、現在では AbstractVMInstall が実装します。バグ 73493 で指摘されている問題を回避するために、クライアントに新規インターフェース IVMInstall2 を実装することをお勧めします。推奨マイグレーションは、AbstractVMInstall のサブクラス化です。

必要な処置: まだ org.eclipse.jdt.launching.AbstractVMInstall をサブクラス化していないすべての実装クラスを、org.eclipse.jdt.launching.AbstractVMInstall をサブクラス化するように作り直す必要があります。

10. SelectionEnabler.SelectionClass がパッケージ可視になった

影響を受けるもの: org.eclipse.ui.SelectionEnabler.SelectionClass を使用するプラグイン。

説明: Eclipse 3.0 では、ネストされた実装クラス org.eclipse.ui.SelectionEnabler.SelectionClass は public で、使用法に制限はありませんでした。これは、パッケージ可視とされているクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。

必要な処置: org.eclipse.ui.SelectionEnabler.SelectionClass をインスタンス化または拡張するすべてのクラスを、このクラスを参照しないように作り直す必要があります。

11. ContributionItem.getParent() がヌルを戻せるようになった

影響を受けるもの: org.eclipse.jface.action.ContributionItem のサブクラスで getParent() を呼び出すプラグイン。

説明: Eclipse 3.0 では、メソッド org.eclipse.jface.action.ContributionItem.getParent() はヌルを戻せると指定されていませんでした。これは、メソッドがヌルを戻せる場合について説明した Javadoc について見落とされていた点で、Eclipse 3.1 で対処されました。詳細については、バグ 92777 を参照してください。

必要な処置: ContributionItem.getParent() を呼び出すコードを、ヌル結果を処理できるようにする必要があります。

12. IPropertySource および IPropertySource2 の isPropertySet(boolean) の変更

影響を受けるもの: org.eclipse.ui.views.properties.IPropertySource または IPropertySource2 を実装するプラグイン。

説明: Eclipse 3.0 では、メソッド org.eclipse.ui.views.properties.IPropertySource.isPropertySet(boolean) の仕様が誤って変更され、指定されたプロパティーに意味のあるデフォルト値がない場合に true を戻すよう指定されていました。旧バージョンでは、このような場合に false を戻すよう指定されていました。プロパティー・ソースが IPropertySource2 ではなく、IPropertySource を実装していた場合、この実装は以前と同様に機能していましたが、これは不用意な API 変更でした。 この問題は 3.1 で訂正され、IPropertySource.isPropertySet(boolean) が以前の仕様 (このような場合に false を戻す) に戻され、IPropertySource2.isPropertySet(boolean) がこれをオーバーライドして、このような場合に true を戻すことを指定するようになりました。詳細については、バグ 21756 を参照してください。

必要な処置: IPropertySource または IPropertySource2 を実装しているクラスを検査して、 一部のプロパティーが意味のあるデフォルト値を持たない場合、isPropertySource(boolean) に適切な値を戻すことを確認する必要があります。 クライアントは、「プロパティー」ビューの「デフォルト値の復元」ボタンが、プロパティー・ソースで期待されるとおりに機能することを確認する必要があります。

13. org.eclipse.ui.commands 拡張ポイントから削除された handlerSubmission 要素

影響を受けるもの: Eclipse 3.0 の org.eclipse.ui.commands 拡張ポイントに導入された試験的な handlerSubmission 要素を使用しているプラグイン。

説明: Eclipse 3.0 では、org.eclipse.ui.commands 拡張ポイントに試験的な要素が導入されていました。この要素は、XML を介してハンドラーを登録する方法となることを意図されていました。その後に、さらに優れたメカニズムである org.eclipse.ui.handlers 拡張ポイントが導入されました。この要素は試験用としてマークされていたため、現在では除去されています。

必要な処置: handlerSubmission 要素を定義しているプラグインはすべて、org.eclipse.ui.commands 拡張ポイントにマイグレーションする必要があります。

14. TeamUI 内の final ではなかった静的 API フィールド GLOBAL_IGNORES_CHANGED が final になった

影響を受けるもの: TeamUI の GLOBAL_IGNORES_CHANGED フィールドを設定していたプラグイン。

説明: Eclipse 3.0 では、GLOBAL_IGNORES_CHANGED フィールドが TeamUI クラスに追加されていました。このフィールドは、Team プラグインによって保持されているグローバルな ignore のリストが変更されたことを示すために、プロパティー変更イベントで使用される定数です。このフィールドは、3.0 では final とマークされてはいませんでしたが、その必要がありました。これは、3.1 では final になっています。

必要なアクション: 上記のフィールドを設定していたプラグインは、すべてこのフィールドを設定できなくなっています。

15. FillLayout を使用する ClassCastException

影響を受けるもの: FillLayout を間違って使用しているプラグイン。

説明: Eclipse 3.0 では、どのレイアウト・データも FillLayout には関連付けられておらず、アプリケーションが FillLayout によって管理されている子にレイアウト・データを割り当てた場合、それは無視されていました。Eclipse 3.1 では、サイズ変更のパフォーマンスを改善するために、サイズ情報をキャッシュに入れるためのサポートが FillLayout に追加されました。 キャッシュされたデータは、FillLayout によって管理されているそれぞれの子に関連付けられている FillData オブジェクトに保管されます。アプリケーションが間違ったレイアウト・データを子に割り当てている場合、その親に対して computeSize が呼び出されると ClassCastException がスローされます。

必要な処置: レイアウト・データが割り当てられている FillLayout 内のすべての子を見つけ、レイアウト・データの割り当てを停止します。

16. 廃棄された親を使用したウィジェットの作成時に IllegalArgumentException がスローされる

影響を受けるもの: ウィジェットの作成中に例外をキャッチするプラグイン。

説明: Eclipse 3.0 では、廃棄された親を使用してウィジェットが作成された場合、例外はスローされませんが、後でウィジェット・コードが失敗するか、SWTException がスローされ、「ウィジェットは廃棄されています (Widget Is Disposed)」というテキストが表示されていました。Eclipse 3.1 では、廃棄された親を使用してウィジェットが作成されると、コンストラクターが IllegalArgumentException をスローし、「引数が無効です (Argument not valid)」というテキストが表示されます。

必要な処置: ウィジェットの作成時に SWTException を処理するすべてのコードで、IllegalArgumentException も処理する必要があります。