JDK 9 RFC on 8029770: Improve user friendliness of preferences storage on Unix systems
peter.levart at gmail.com
Tue Mar 11 12:09:10 UTC 2014
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 ) 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.
>  http://tools.ietf.org/rfc/rfc4648.txt
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
More information about the core-libs-dev