On 03/10/2014 10:12 PM, Brian Burkhalter wrote:
This issue (https://bugs.openjdk.java.net/browse/JDK-8029770) concerns
improving preference handling (java.util.prefs.Preferences) on systems other
than Mac OS X and Windows, essentially Unix systems other than OS X. It would
be good to obtain some comments on the behavior of the prospective changes
including whether they are even necessary. For the moment, comments on the
behavior are of more interest than those on any particular implementation.
For background, on the Unix systems in question, the file system is used to
store preferences in a tree with nodes mapping to directories. As node names
can contain characters which may cause confusion when used verbatim in
directory names, in those cases where such characters are detected, the
directory name is derived from the node name by encoding the latter using a
non-standard variant of the Base 64 Alphabet (Table 1 in [1]) which is immune
to alphabetic character case folding. This can result in some strange and human
unreadable directory names in the file system preferences tree. The objective
here would be to change this scheme to something more user friendly.
There are likely numerous approaches to solving this problem, but I think that
first it needs to be determined whether interoperability with earlier Java
versions is a requirement and, if so, what the nature of this requirement is.
There are probably others, but there are at least the following alternatives
(not all of which might be sensible):
A) No interoperability: Java 9 and subsequent versions would not share
preferences with earlier versions.
B) Initialization only: Java 9 preferences would be initialized from the state
of pre-9 preferences at the instant of first use.
C) Unidirectional: Java 9 would detect changes made by earlier versions.
D) Bidirectional: Java 9 and pre-9 preferences would be kept in sync.
For options C and D note that only Java 9+ instances could effect this
behavior. If for example Java 9 was not run for some time on a particular
machine, the pre-9 preferences could significantly diverge from the 9
preferences. These would presumably be brought into sync when a Java 9+
instance next invoked the Preferences APIs.
Whichever option were chosen, the changes made could include the definition of
a system property which could be set to disable the new preferences handling
variant, i.e., to force pre-9 file system preferences behavior.
Any comments would be appreciated.
Thanks,
Brian
[1] http://tools.ietf.org/rfc/rfc4648.txt
Hi Brian,
What is the purpose of changing the scheme? Is it just to be more
power-user and developer friendly? To enable users to inspect the
preferences with filesystem tools? What about a little command-line
and/or gui "jprefs" tool in the style of regedit or gconftool or
similar? Would that be enough to satisfy the goal? Any of the options
A...D seem a compatibility nightmare for majority of programs that use
preferences. Most users don't ever inspect directories starting with dot
'.', so this feature is more or less targeted at developers, right? A
tool that is standard part of JRE distribution could do the job of
browsing (and perhaps changing of) the preferences without compatibility
concerns...
Regards, Peter
