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
