Preferences API の設計に関する FAQ

設計に関する FAQ

ここでは、Preferences API の設計に関する FAQ をまとめてあります。

Preferences API には、Properties API とどのような関連性がありますか。
Preferences API は、非常によく使用されてきた Properties クラスを置き換える目的で設計されており、軽量性を維持しながら、さまざまな欠点を訂正しています。Properties を使用するときは、各プロパティーファイルのパス名を明示的に指定する必要がありますが、標準の場所や名前の規約はありません。プロパティーファイルは壊れやすくなっています。手動で編集できますが、不注意な編集によって簡単に破損します。文字列以外のデータ型のサポートは存在しません。Properteis は、ファイルシステム以外の永続性メカニズムで簡単に使用することはできません。つまり、Properties の機能には拡張性がありません。
Preferences API には、JNDI とどのような関連性がありますか。
Preferences API は、JNDI と同様に、永続的なキー/値データへのバックエンド中立的なアクセスを提供します。ただし、JINDI は、はるかに強力で重量です。JNDI は、強力な機能を必要とする企業アプリケーションに適しています。Preferences API は、単純で、汎用的な、バックエンド中立性を持つ設定管理機能として設計されているため、Java アプリケーションの動作をユーザーの要望に合わせて簡単に調整でき、実行をまたがって一部の状態を保持できます。
すべての get メソッドに対して呼び出し側がデフォルトを渡す必要があるのはなぜですか。
これによって、アプリケーション作成者は強制的に相応のデフォルト値を提供することになり、リポジトリが利用できない場合でもアプリケーションは相応の実行機会を得ることになります。
どのメソッドが BackingStoreException をスローするべきかはどのようにして決定されたのですか。
セマンティクスが絶対的にバッキングストアとのやり取りを必要としているメソッドだけが、この例外をスローします。通常のアプリケーションでは、このようなメソッドを呼び出す必要はありません。このようなメソッドを呼び出さないかぎり、バッキングストアを利用できない場合でもアプリケーションは実行でき、それが設計の明示的な目標でした。
複数の VM による同時アクセスについて、この API がより強力な保証を提供しないのはなぜですか。同様に、この API が複数の Preferences 更新を単一トランザクションに結合することを許可しないのはなぜですか (オールオアナッシングセマンティクスで)。
この API は基本的な永続データストレージを提供しますが、それはデータベースの代替を意図したものではありません。この API を標準の設定/構成リポジトリ上に実装できることが重要で、そのほとんどはデータベースのような保証および機能を提供しません。このようなリポジトリは、この API が意図する目的を十分に満たしています。
この API が大文字と小文字を区別するキーとノード名を持つのはなぜですか。同様の空間 (Microsoft Windows レジストリや LDAP など) で使用されるほかの API はそうではありません。
Java プログラミング言語では、大文字と小文字が区別される String キーが一般的です。具体的には、それらは Properties クラスによって提供されており、この API が置き換える予定です。大文字小文字の区別を要求する方法で Properties を使用する人は珍しくありません。たとえば、Java パッケージ名 (大文字小文字を区別) がキーとして使用されることがあります。この設計上の意思決定は、大文字小文字を区別するキーを使用するバッキングストア上に Preferences を実装するシステムプログラマーの寿命を複雑にすると認識されていますが、これは受け入れ可能な対価と考えられます。はるかに多くのプログラマーがそれを実装するより Preferences API を使用するようになるでしょう。
この API が Java 2 Collections Framework を使用しないのはなぜですか。
この API は、かなり特定の目的のために設計されており、その目的のために最適化されています。ジェネリック型がないので (JSR-14 を参照)、この API は典型的なユーザーにとって便利さに欠けます。Map API に対して強制的に準拠される場合、コンパイル時型安全性が不足します。また、ほかの Map 実装との相互運用性が要求されることは想定していません (この想定が間違っているとわかった場合には、アダプタクラスを実装することは簡単です)。Preferences API は設計上、Map によく似ているため、後者に習熟しているプログラマーは前者を使用することは難しくないはずです。
put および remove メソッドが古い値を返さないのはなぜですか。
それらのメソッドは、バッキングストアが利用できない場合でも、実行可能であることが望ましいです。それらが古い値を返す必要がある場合、これはできなくなります。さらに、この API が一部の一般的なバックエンドデータストア上に実装されている場合は、パフォーマンスが低下します。
この API はなぜ保存済みデフォルトを許可するのですか (要求しませんが)。
この機能は、エンタープライズ全体の設定管理を拡張可能かつコスト効率的にするためにエンタープライズ設定に必要ですが、自己管理される単一ユーザー設定では過剰です。
任意の直列化可能オブジェクトを読み書きするメソッドがこの API に含まれていないのはなぜですか。
直列化されたオブジェクトは、いささか壊れやすくなっています。そのようなプロパティーを読み取るプログラムがそれを書き出すプログラムと異なる場合は、オブジェクトが正しくまたはまったく直列化復元されないことがあります。直列化されたオブジェクトをこの API を使用して保存することはできますが、推奨しておらず、便利なメソッドも提供していません。
Preferences がインタフェースでなく、抽象クラスなのはなぜですか。
上方互換な方法で新しいメソッドを追加できることは、Preferences を「Mixin」として使用できない短所 (任意のクラスを Preferences オブジェクトとして機能するようにできない) を上回ると判断しました。また、これによって、static メソッド用の別個のクラスの必要性がなくなります。(インタフェースに static メソッドを含めることはできません。)

連絡先