リリース 3.1 では、AbstractUIPlugin#getPreferenceStore から戻される org.eclipse.jface.preference.IPreferenceStore は org.eclipse.ui.preferences.ScopedPreferenceStore のインスタンスです。 ScopedPreferenceStore では、設定を管理するために、新規コア・ランタイム API を使用します。3.0 では、互換性レイヤーを使用して、org.eclipse.core.runtime.Preferences のインスタンスとインターフェースしていました。
3.1 では、設定変更イベントで送信される値の型を特定するため IPreferenceStore のあいまいさをなくしました。AbstractUIPlugin#getPreferenceStore からの IPreferenceStore は、 以前と同様に動作します。変更点は、より明確に指定されるようになったことのみです。
Typing: IPreferenceStore に追加された org.eclipse.jface.util.IPropertyChangeListener は、
場合によって、古い値と新しい値の 2 つのタイプ、つまり型付けされた表記または String 型の
表記を取ることができます。型付きの IPreferenceStore API
(setValue(String key, boolean value)
など) に対する呼び出しにより生成されるイベントでは、
型付きのイベントが生成されます。ただし、
型付きでないイベント (例えば、設定インポートなど) を生成するコア・ランタイム設定からイベントが伝搬される
場合もあります。プロパティー・リスナーは、両方に対して準備する必要が
あります。型付きイベントはプリミティブ型を伝搬しないため、setValue(String key, boolean value)
に対する呼び出しは、oldValue および newValue がブールであるイベントになることもあります。
putValue: IPreferenceStore.putValue(String key, String value) は、 変更イベントを生成しません。この API は、リスナーが反応しない専用設定に使用されることが前提になります。
initializeDefaultPreferences: この API は、互換性レイヤーが使用される場合にのみ発行されるため、Eclipse 3.0 では推奨されていませんでした。多くのプラグインが 設定ストアを取得するために AbstractUIPlugin#getPreferenceStore を使用するため、 これはプラグインの始動前に発行されていました。プラグインが互換性レイヤー自体にアクセスしない場合、 このメソッドは使用されないことがあります。設定の初期化を処理する場合は、 org.eclipse.core.runtime.preferences.AbstractPreferenceInitializer を作成することをお勧めします。