Preferences APIを導入する前は、プリファレンスおよび構成データを動的に管理するために、Properties APIまたはJava Naming and Directory Interface (JNDI) APIを使用していました。

プリファレンスおよび構成データは、多くの場合、 java.util.Properties APIを使用してプロパティ・ファイルにアクセスし、このファイルに格納していました。ただし、ディスク上でのファイルの位置またはファイルの名前に関する標準は存在しませんでした。このメカニズムを使用する場合、ユーザーの設定データのバックアップ作成や、マシン間のデータ転送が困難になります。さらに、アプリケーション数が増加するにつれて、ファイル名が重複する可能性が高くなります。また、プラットフォームにローカル・ディスクが存在しない場合、またはデータを外部データ・ストア(企業全域にわたるLDAPディレクトリ・サービスなど)に保存するのが望ましい場合には、このメカニズムは役に立ちません。

適用例は少なくなりますが、JNDI APIを使用してディレクトリ・サービスにアクセスし、そこにユーザー設定や構成データを格納する場合もありました。Properties APIと異なり、JNDIでは、任意のデータ・ストアを使用できます(バックエンドの中立性)。JNDIは強力ですが、サイズが比較的大きく、5つのパッケージと83のクラスから構成されます。JNDIには、ディレクトリ名前空間内で設定データを格納する場所、または格納する名前空間に関するポリシーが存在しません。

PropertiesおよびJNDIには、単純で、汎用的な、バックエンドの中立性を持つ設定管理機能はありません。Preferences APIでは、Properties APIの単純さとJNDIのバックエンドの中立性が同時に実現されます。これには、バッキング・データ・ストアにアクセスできない場合でも、名前の重複を回避し、一貫性を保持し、安定性を向上するために必要なポリシーが組み込まれています。