Eclipse の変更に伴い、3.0 と 3.1 の間には互換性がなくなったため、プラグインはその影響を受けます。以下の項目で、変更された領域、および 3.0 のプラグインを 3.1 にマイグレーションする手順について説明します。3.0 のプラグインを 3.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 つの考えられる問題を検査する必要があります。
ストリング
、または型付きオブジェクトになる可能性があります。したがって、クライアントが有効であるためには、設定変更リスナーが、考え得るこれら 3 つのすべての状態を処理できる必要があります。org.eclipse.ui.plugin.AbstractUIPlugin#initializeDefaultPreferences
を使用する場合は、org.eclipse.core.runtime.compatibility
プラグインを必須プラグイン・リストに組み込む必要があります。これは、この依存関係が org.eclipse.ui.workbench
プラグインから除去されたためです。詳しくは、『設定ストア』を参照してください。
影響を受けるもの: 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 内のアイコン・ファイルのパスやその他のパスは、パス・セグメントのセパレーターとして '/' のみを使用する必要があります。
影響を受けるもの: Eclipse プラットフォームのプラグインまたは拡張レジストリーの IExtensionPoint
、IExtension
、および IConfigurationElement
オブジェクトを操作または保存するプラグイン。
説明: 3.0 以前は、(以前のプラグイン・レジストリーの) 拡張レジストリーから取得されたすべてのオブジェクトは、永久に有効でした。Eclipse 3.0 では、Eclipse を再始動せずにプラグインの動的な追加または除去を許可していましたが、それが変更されました。再始動せずにプラグインを除去すると、拡張レジストリー内の項目は必然的に無効になります。つまり、削除されたプラグインの拡張レジストリー項目から以前に取得されたオブジェクトを保持している別のプラグインは、無効なオブジェクトを保持したままになります。クライアントが得られる唯一のヒントは、IRegistryChangeEvent
を listen することで得られます。
この問題は Eclipse 3.0 から存在していましたが、Eclipse を再始動しないでプラグインを除去するのは極めて例外的であるため、実際に問題が発生することはほとんどありませんでした。
この問題は 3.1 で、以下のように改善されました。
IExtensionPoint
、IExtension
、および IConfigurationElement
上の既存のメソッドは、オブジェクトが無効な場合に InvalidRegistryObjectException
をスローするように、指定するようになりました。この例外は検査されないため、動的に認識されないクライアントでは、この例外を強制的に検査する必要はありません。isValid()
メソッドが追加され、オブジェクトがまだ有効であるかどうかをクライアントが判別できるようになりました。必要な処置: プラグインを動的に認識されるようにする (つまり、プラグインのオンザフライ追加または除去に対応可能にする) 必要がある場合は、他のプラグインをソースとする IExtensionPoint
、IExtension
、および IConfigurationElement
オブジェクトを処理するコードを、検査済みの例外であるかのようにして IRegistryChangeEvent
を catch するよう変更する必要があります。例外 (isValid()
事前チェックではなく) を catch することは、プラグインが並行スレッドによって除去される場合に対応するための唯一の確実な方法です (これが発生する場合、これはほぼ間違いなく唯一の確実な方法です)。
影響を受けるもの: Java コード・フォーマッター・オプションにプログラマチックにアクセスするプラグイン。
説明: Eclipse 3.0 では、コード・フォーマッター・オプション org.eclipse.jdt.core.formatter.DefaultCodeFormatterConstants#FORMATTER_TAB_CHAR
の値は、TAB
または SPACE
のみでした。仕様では、値の型が将来のリリースで拡張される可能性のある列挙型であるということは明示されていませんでした。Eclipse 3.1 では、バグ 73104 に対処するために 3 番目の可能な値 MIXED
が追加されました。
仕様は、この新しい値が組み込めるよう、また将来さらに多くの値が追加できるように変更されました。
必要な処置: このコード・フォーマッター・オプションをプログラマチックに読み取ったり設定するクライアントは、新しい 3 番目の値を考慮に入れるようコードを検査する必要があります。また、コードが予期しないオプション値に遭遇した場合に、正しく障害を報告するような頑強な方法でコードを作成する必要があります。
影響を受けるもの: 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
をサブクラス化しないよう作り直す必要があります。
影響を受けるもの: ワークベンチによって設定される 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
を代わりに渡すよう変更する必要があります。
影響を受けるもの: 非ヌル・デフォルト・パースペクティブを予期する RCP アプリケーション。
説明: 開いているパースペクティブがない空のウィンドウ (機能拡張 71150) で RCP アプリケーションを開始できるようにするために、ヌルを戻せるよう WorkbenchAdvisor.getInitialWindowPerspectiveId()
および IPerspectiveRegistry.getDefaultPerspective()
が変更されました。IDE では、常にデフォルト・パースペクティブがあるため、IPerspectiveRegistry.getDefaultPerspective()
はヌルを戻しません。同様に、既存の RCP アプリケーションが以前から、WorkbenchAdvisor.getInitialWindowPerspectiveId()
で非ヌル値を戻していた場合、IPerspectiveRegistry.getDefaultPerspective()
は引き続き非ヌル値を戻します。
必要な処置: クライアントで必要な処置はありません。
影響を受けるもの: org.eclipse.ui.IViewLayout
を実装するプラグイン。
説明: Eclipse 3.0 では、クラス org.eclipse.ui.IViewLayout
は、クライアントが実装してはならないとマークされていませんでした。これは、クライアントによる実装を目的としていないとマークされたクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。
必要な処置: org.eclipse.ui.IViewLayout
を実装しないよう、実装クラスを作り直す必要があります。
影響を受けるもの: 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
をサブクラス化するように作り直す必要があります。
影響を受けるもの: org.eclipse.ui.SelectionEnabler.SelectionClass
を使用するプラグイン。
説明: Eclipse 3.0 では、ネストされた実装クラス org.eclipse.ui.SelectionEnabler.SelectionClass
は public で、使用法に制限はありませんでした。これは、パッケージ可視とされているクラスについて見落とされていた点で、Eclipse 3.1 で対処されました。
必要な処置: org.eclipse.ui.SelectionEnabler.SelectionClass
をインスタンス化または拡張するすべてのクラスを、このクラスを参照しないように作り直す必要があります。
影響を受けるもの: org.eclipse.jface.action.ContributionItem
のサブクラスで getParent()
を呼び出すプラグイン。
説明: Eclipse 3.0 では、メソッド org.eclipse.jface.action.ContributionItem.getParent()
はヌルを戻せると指定されていませんでした。これは、メソッドがヌルを戻せる場合について説明した Javadoc について見落とされていた点で、Eclipse 3.1 で対処されました。詳細については、バグ 92777 を参照してください。
必要な処置: ContributionItem.getParent() を呼び出すコードを、ヌル結果を処理できるようにする必要があります。
影響を受けるもの: 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) に適切な値を戻すことを確認する必要があります。 クライアントは、「プロパティー」ビューの「デフォルト値の復元」ボタンが、プロパティー・ソースで期待されるとおりに機能することを確認する必要があります。
影響を受けるもの: 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
拡張ポイントにマイグレーションする必要があります。
影響を受けるもの: TeamUI の GLOBAL_IGNORES_CHANGED フィールドを設定していたプラグイン。
説明: Eclipse 3.0 では、GLOBAL_IGNORES_CHANGED フィールドが TeamUI クラスに追加されていました。このフィールドは、Team プラグインによって保持されているグローバルな ignore のリストが変更されたことを示すために、プロパティー変更イベントで使用される定数です。このフィールドは、3.0 では final とマークされてはいませんでしたが、その必要がありました。これは、3.1 では final になっています。
必要なアクション: 上記のフィールドを設定していたプラグインは、すべてこのフィールドを設定できなくなっています。
影響を受けるもの: FillLayout を間違って使用しているプラグイン。
説明: Eclipse 3.0 では、どのレイアウト・データも FillLayout には関連付けられておらず、アプリケーションが FillLayout によって管理されている子にレイアウト・データを割り当てた場合、それは無視されていました。Eclipse 3.1 では、サイズ変更のパフォーマンスを改善するために、サイズ情報をキャッシュに入れるためのサポートが FillLayout に追加されました。 キャッシュされたデータは、FillLayout によって管理されているそれぞれの子に関連付けられている FillData オブジェクトに保管されます。アプリケーションが間違ったレイアウト・データを子に割り当てている場合、その親に対して computeSize が呼び出されると ClassCastException がスローされます。
必要な処置: レイアウト・データが割り当てられている FillLayout 内のすべての子を見つけ、レイアウト・データの割り当てを停止します。
影響を受けるもの: ウィジェットの作成中に例外をキャッチするプラグイン。
説明: Eclipse 3.0 では、廃棄された親を使用してウィジェットが作成された場合、例外はスローされませんが、後でウィジェット・コードが失敗するか、SWTException がスローされ、「ウィジェットは廃棄されています (Widget Is Disposed)」というテキストが表示されていました。Eclipse 3.1 では、廃棄された親を使用してウィジェットが作成されると、コンストラクターが IllegalArgumentException をスローし、「引数が無効です (Argument not valid)」というテキストが表示されます。
必要な処置: ウィジェットの作成時に SWTException を処理するすべてのコードで、IllegalArgumentException も処理する必要があります。