モジュール java.prefs
パッケージ java.util.prefs

クラスAbstractPreferences

java.lang.Object
java.util.prefs.Preferences
java.util.prefs.AbstractPreferences
public abstract class AbstractPreferences extends Preferences
このクラスは、Preferencesクラスのスケルトン実装を提供します。このクラスを使用すれば、簡単に実装することができます。

Thisクラスは、Preferences実装者専用です。 Preferences機能の通常のユーザーは、このドキュメントを参照する必要はありません。 Preferencesのドキュメントで十分なはずです。

実装する場合は、9つの抽象サービス・プロバイダ・インタフェース(SPI)メソッドgetSpi(String)、putSpi(String,String)、removeSpi(String)、childSpi(String)、removeNodeSpi()、keysSpi()、childrenNamesSpi()、syncSpi()、およびflushSpi()をオーバーライドする必要があります。 オーバーライドする具象メソッドには、これらのSPIメソッド上に実装する方法を正確に指定する必要があります。 パフォーマンスなどの理由でデフォルトの実装に変更を加えたい場合は、任意の具象メソッドをオーバーライドします。

SPIメソッドは、例外処理について3つのグループに分類されます。 getSpiメソッドは例外をスローすることはありませんが、このメソッドによってスローされた例外は、get(String,String)によってインターセプトされ、指定されたデフォルト値がコール元に返されるため、実際には問題ではありません。 removeNodeSpi, keysSpi, childrenNamesSpi, syncSpiおよびflushSpiメソッドがBackingStoreExceptionをスローするように指定されており、操作を実行できない場合、このチェック済例外をスローするために実装が必要です。 スローされた例外は外部に送られ、対応するAPIメソッドが失敗します。

残りのSPIメソッドputSpi(String,String)、removeSpi(String)、およびchildSpi(String)は、より複雑な例外処理を行います。 バッキング・ストアが使用できない場合でも通常は契約に従うことができるため、BackingStoreExceptionをスローするように指定されていません。 これは、それらがPreferences.flush()またはPreferences.sync()が次に呼び出されるまで、情報を返さず、それらの効果が永続的になる必要がないためです。 一般に、これらのSPIメソッドは例外をスローしません。 一部の実装では、これらの呼出しが要求した操作を、あとで処理するためにキューに入れることができない場合があります。 こうした場合でも、通常は例外をスローせずに、呼び出しや戻り値を無視してください。 ただし、このような状況では、その後flush()またはsyncを起動しても、以前のすべての操作が正常に永続化されたとはかぎりません。

putSpi, removeSpi and childSpi 「必要」が例外をスローする状況が1つあります: 呼び出し元に、リクエストされた操作を実行するための十分な特権がベースとなるオペレーティング・システム上にある場合。 たとえば、ほとんどのシステムでは、非特権ユーザーがシステム設定を変更しようとすると例外が発生します。 必要な特権は、実装ごとに異なります。 たとえば、ファイル・システム内のディレクトリの内容を変更する権限が必要な場合や、レジストリ内のキーの内容を変更する権限が必要な場合があります。 こうした環境の場合、プログラムの実行は続行しないでください。続行しても、これらの操作は適用されることがないためです。 このような環境では、できるだけ例外をスローすることをお薦めします。 SecurityExceptionが適切と考えられます。

ほとんどのSPIメソッドの実装では、設定ノードで情報の読み込みまたは書込みを行う必要があります。 設定ノードは、別のVMによってバッキング・ストアから並行して削除されている場合があります。 このノードが削除されている場合は、実装するユーザーが再作成してください。

実装ノート: SunのデフォルトのPreferences実装では、ユーザーの識別情報はベースとなるオペレーティング・システムから継承され、仮想マシンの存続期間中は変更されません。 サーバー側のPreferences実装では、静的ThreadLocalインスタンスを使用して暗黙的にPreferencesメソッドに渡される、リクエストからリクエストへのユーザー・アイデンティティ変更があることが認識されます。 このような実装の作成者は、ユーザーを各Preferencesインスタンスに永続的に関連付けるのではなく、プリファレンスがアクセスされた時点で(たとえば、get(String,String)またはput(String,String)メソッド)のユーザーを判断することを「強く」お薦めします。 後者の動作は、通常のPreferencesの使用と競合するため、大きな混乱を招きます。

導入されたバージョン:
1.4
関連項目: