Users of the preferences facility typically get a preferences node using
one of two static factories: nodeForPackage and userNodeForPackage. There are
several problems with these calls as they stand. First of all, the call is
only convenient from within a non-static context, as it relies on the presence
of an object whose class belongs to the package in question:

    The alleged prototypical usage is:

    Preferences prefs = Preferences.userNodeForPackage(this);

The problem is that one typically wants to obtain a prefs node in a static
context (as part of the initialization of the class that requires access to
preferences). With the current API, this leaves you little choice but to use
the "root factory" and specify the node name explicitly as a string:

    Preferences prefs = Preferences.userRootForPackage().node(
                             "/com/acme/widget");

If the string is wrong, compilation proceeds normally and you use the wrong
prefs at runtime.

A second problem with the current calls is that subclasses of base types using
preferences will not have easy access to the parent's preferences if the
parent and child are in different packages. If the child uses the "alleged
prototypical usage" (above) it will get a prefs node corresponding to its
package rather than the parent's.

    An earlier draft of the API used Class instances rather than arbitrary
Objects, and we propose to reinstate this, replacing these methods:

    public static Preferences userNodeForPackage(Object o);
    public static Preferences systemNodeForPackage(Object o);

with these:

    public static Preferences userNodeForPackage(Class c);
    public static Preferences systemNodeForPackage(Class c);

The prototypical usage becomes:

    Preferences prefs = Preferences.userNodeForPackage(Widget.class);