java.util.prefs
类 AbstractPreferences
java.lang.Object
java.util.prefs.Preferences
java.util.prefs.AbstractPreferences
JDK1.4提供了Preferences类，可以把Preferences理解为对Java的Properties的补充和扩展，使Java在保存系统的配置、运行状态等信息时，更加具有弹性和灵活性。Preferences类在不同的平台中有不同的实现方式。比如在Windows平台中，Preferences是将数据保存在注册表中的。
public abstract class AbstractPreferencesextends Preferences此类提供了 Preferences 类的骨干实现，从而大大简化了实现此类的任务。
此类仅供 Preferences 实现者使用。Preferences 设施的普通用户无需参考此文档。Preferences 文档已经足够了。
实现者必须重写九个抽象服务提供程序接口 (SPI) 方法：getSpi(String)、putSpi(String,String)、removeSpi(String)、childSpi(String)、removeNodeSpi()、keysSpi()、childrenNamesSpi()、syncSpi() 和 flushSpi()。所有的具体方法都精确指定它们如何在这些 SPI 方法上实现。如果出于某种考虑（如性能）对默认实现不满意，则实现者可能决定重写一个或多个具体方法。
SPI 方法按异常行为可分为三个组。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 的后续调用应该返回 false，因为返回 true 意味着以前的所有操作都已成功地成为持久性操作。
有一种情况下 putSpi、removeSpi 和 childSpi 应该 抛出异常：如果调用方在基础操作系统上不具备执行请求操作的足够权限。例如，如果非特权用户尝试修改系统首选项，则在大多数系统上都会发生这种情况。（这要求特权随实现而变化。在有些实现中，需要修改文件系统中某些目录内容的特权；而在另外一些实现中，则需要修改注册表中某些键的内容。）在上述任何情形下，通常让程序继续执行并不合乎需要，就好像这些操作在以后会成为持久操作一样。虽然在这些情形下不要求实现抛出异常，但还是鼓励这样做。SecurityException 就是合适的选择。
大多数 SPI 方法都要求实现在首选项节点上读取或写入信息。实现者需要注意一种情况，即另一个 VM 当前可能已经从内部存储删除了此节点。如果该节点已经删除了，则实现有责任重新创建它。
实现注意事项：在 Sun 的默认 Preferences 实现中，用户的身份是从基础操作系统继承的，在虚拟机的生命周期中不能更改。在服务器端的 Preferences 实现中，用户身份可以随请求而更改，并通过使用静态 ThreadLocal 实例隐式传递给 Preferences 方法。大力 提倡这种实现的设计者在访问首选项时确定用户（例如，使用 get(String,String) 或 put(String,String) 方法），而不是将用户与每个 Preferences 实例永久关联。后一种行为与通常的 Preferences 用法有冲突，将带来很大的混乱。
