JDK1.4新特性－－参数选择API

本文链接：https://blog.csdn.net/cherami/article/details/3858

参数选择 API

概览

应用程序需要参数和配置数据以适应不同用户和环境的需要。 java.util.prefs 包给应用程序提供了存储和恢复用户和系统参数及配置数据的方法。数据不断地存入独立实现的后备存储中。有两个分立的参数节点树，一个用于用户参数，另一个用于系统参数。

所有修改参数数据的方法都允许异步操作。它们可能立即返回并且修改最终会传递给后备存储。 flush方法能用于强制刷新后备存储。

Preferences类中的方法可以在单一JVM下在没有外部同步的情况下通过多线程并发调用。如果这个类被多个使用同一后备存储区存储参数数据的JVM并发调用，数据存储不会被破坏，但是不能保证数据的一致性。

更多细节，可以参看下面的链接:

参数选择API和其它机制的比较
使用的注意事项
设计 FAQ

参数选择API和其它机制的比较

在引入参数选择API前,开发者可能选择一种特别的方式管理参数和配置数据：使用下面描述的参数API或者JNDI API。

通常，参数和配置数据被存储在配置文件里面，这些文件可以通过java.util.Properties API访问。然而这些文件应该放在何处或者它们应该调用什么没有标准。使用这种机制，备份用户数据或者将它们从一个机器传递到另一个机器将异常的困难。随着应用程序的增加，文件名称冲突可能性就增加。而且，这种机制在没有本机磁盘的平台下是没有用的，或者需要将数据存储在外部的数据存储器上（例如企业范围的 LDAP目录服务）。

在少数情况下，开发者通过JNDI（Java名字和目录接口）API访问目录服务存储用户参数和配置数据。（不像参数API,JNDI允许允许使用任何后备存储（后端中立）。虽然JNDI是异常的强大，但是它也很巨大，它由5个包和83各类组成。JNDI不提供参数数据应该存储在目录名字空间的什么地方的政策。

参数API和JNDI都没有提供一个简单的，普遍地，后端中立的参数管理工具。参数选择API提供了一个这样的工具，它结合了参数选择API的简单和JNDI的后端中立。它在难以达到的后备数据存储方面提供充分的内置政策防止名字冲突、鼓励一致性并且促进健壮性。

参看: 设计 FAQ

使用注意事项

这一节包含的材料不是参数选择API规范的一部分，它只是提供了一些如何使用参数选择API的例子。

在类里面获得Preferences对象
在静态方法里面获得Preferences对象
原子化修正
探测后备存储的状态

在类里面获得Preferences 对象

下面的例子阐明了如何在类里面获得Preferences对象(系统和用户)。这个例子只能在实例方法里面工作

注意static final 成员而不是它的字面上的字符串用来作为关键字的名字(NUM_ROWS 和 NUM_COLS)。这降低了由于关键字名的印刷上的错误引起的运行时错误的可能性。

同时注意为每个参数提供的合理的缺省值。这些缺省值在参数值没有被设置或者后备存储不可达的情况下被返回。


package com.acme.widget;
import  java.util.prefs.*;
public class Gadget {
    // Preference keys for this package
    private static final String NUM_ROWS = "num_rows";
    private static final String NUM_COLS = "num_cols";
    void foo() {
        Preferences prefs = Preferences.userNodeForPackage(this);
        int numRows = prefs.getInt(NUM_ROWS, 40);
        int numCols = prefs.getInt(NUM_COLS, 80);
        ...
    }
}

上面的例子为每个用户获取一个参数，如果想获取系统值，foo 中的第一行应该用下面的程序代替:

        Preferences prefs = Preferences.systemNodeForPackage(this);

在静态方法中获取Preferences对象

前一节的例子阐明了在类里面获取Preferences对象，在实例方法中。在一个静态方法或者静态初始化程序里面，你需要明确的提供包名 :

    Static String ourNodeName = "/com/acme/widget";
    static void foo() {
        Preferences prefs = Preferences.userRoot().node(ourNodeName);
        ...
    }

只在需要系统参数的时候在静态初始化程序里面获取一次系统参数是可以让人接受的：

    static Preferences prefs =  Preferences.systemRoot().node(ourNodeName);

通常为一个用户参数做同样的事情也是可以让人接受的，但是如果代码用于服务器，在其中多个用户可能并发或者连续运行该程序，这样的情况下就不行了。在一个这样的系统下, userNodeForPackage 和 userRoot 为调用者返回一个合适的节点，因此在一个适当的时间从一个适当地线程调用userNodeForPackage 或者 userRoot 是很危险的。在这样一个服务器环境下最终使用的代码片断应该是在要使用它们之前才获取用户参数对象，这是一个好的，保守的惯例。就像先前的例子那样做。

原子化校正

参数选择API不提供像“事务”这样的多个参数原子地被修改的数据库操作。有时候我们需要将两个或更多参数当作一个单位修改。例如，假设存储窗口的x和y坐标，完成原子性的修改的唯一方法是在一个参数里面同时存储两个值。很多编码方法都是可以的，下面是一个简单的例子:

    int x, y;
    ...
    prefs.put(POSITION, x + "," + y);

当读取一个像这样的 "复合参数"就需要解码。出于健壮性的考虑，应该允许被破坏（不可解析）的值被读取:

    static int X_DEFAULT = 50, Y_DEFAULT = 25;
    void baz() {
        String position = prefs.get(POSITION, X_DEFAULT + "," + Y_DEFAULT);
        int x, y;
        try {
            int i = position.indexOf(',');
            x = Integer.parseInt(coordinates.substring(0, i));
            y = Integer.parseInt(position.substring(i + 1));
        } catch(Exception e) {
            // Value was corrupt, just use defaults
            x = X_DEFAULT;
            y = Y_DEFAULT;
        }
        ...
    }

探测后备存储的状态

通常应用程序代码不需要知道后备存储是否可用。它总应该是可用的，但是如果它不可用，代码将使用缺省值代替后备存储中的参数值继续执行。非常罕见的情况下，一些高级的程序可能想在后备存储不可用的时候改变它的行为（或者简单的拒绝继续运行）。下面是一个通过试图修改参数值并强制将结果写回后备存储的方法探测后备存储是否可用的方法。

    private static final String BACKING_STORE_AVAIL = "BackingStoreAvail";
    private static boolean backingStoreAvailable() {
        Preferences prefs = Preferences.userRoot().node("
  
  
   
   ");
        try {
            boolean oldValue = prefs.getBoolean(BACKING_STORE_AVAIL, false);
            prefs.putBoolean(BACKING_STORE_AVAIL, !oldValue);
            prefs.flush();
        } catch(BackingStoreException e) {
            return false;
        }
        return true;
    }