A DESCRIPTION OF THE REQUEST :
Preferences in Windows are stored by default on the Windows registry, which can be not available or not practical in enterprise networks. It is not easy to develop a PreferenceFactory which store on disk rather that in the registry (involves a lot of recoding).

It would be easier to simplify the implementation of a custom PreferenceFactory, if :
- the XmlSupport class was made public an not package protected, and most of its methods be public too. It should be noted that the importPreferences method loads by default the default Preferences class on the platform, and so loads the "Windows" default preferences on Windows platforms, even if it is not used on the custom implementation. So a more configurable behavior for XmlSupport in this regard could be a good thing too..
- the Base64 class was made public too (in this case, it would be better directly under the java.util package). Also it is used and redefined in a -LOT- of cases, so as it is already in the JDK, why redevelop it ?

JUSTIFICATION :
Definition of custom Preferences factories is necessary on Windows platforms when the windows registry is not available / should not be modified (as in intranet networks, or when implementors whant the preferences for a user to be accessible all over the network, and not only on a particular machine).
But custom Preferences factories would be a -LOT- easier to develop if the two proposed modifications where made in the library.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
 XmlSupport and Base64 classes made public. (P1)
importPreferences method for XmlSupport changed to be more configurable, and not load the platform Preferences by default (P2)

Remark : to have a "more configurable" behavior for the importPreferences method could be done by adding a PreferencesFactory argument to the importPreferences method. The root would then be accessed by calling the systemRoot() or userRoot() of the PreferencesFactory interface (thus removing any dependencies on the default platform Preference class)
ACTUAL -
A XmlSupport class (same behavior that the actual JDK class) must be rewritten from scratch, as well as the Base64 class.

CUSTOMER SUBMITTED WORKAROUND :
Rewrite from scratch a class which have the same behavior as XmlSupport, and a "Base64" class, which can lead to a number of errors.