java.util.prefs, was: positioning files for use from both IDEs and JARs

Just to followup:

Tom Roche Fri Mar 2 15:43:09 PST 2007
>>> how to position a file (either a .properties or a preferences XML)
>>> in filespace so as to satisfy all the following requirements: it
>>> can be

>>> * programmatically read from classes in an Eclipse project, e.g.
>>>   when launching a Java application

>>> * programmatically read from classes in a deployed JAR file

>>> * when deployed, read and written by a human outside the JAR. I.e.
>>>   a user could run the app, edit the .properties, re-run the app,
>>>   etc, without needing to open or rebuild the JAR.

Robert Dale Fri Mar 2 17:51:04 PST 2007
>> Preferences is a good API, but not if you intend for users to edit
>> the file.

...

>> An alternative to Properties is using XML. There are plenty of xml
>> binding APIs.

Rich Hammer Fri Mar 2 18:34:45 PST 2007
> In Eclipse we keep the lab.properties file in the project's root
> directory (where also live src/, bin/, .classpath, and .project).
> When we make a jar of the stuff in bin/, then we deploy that jar and
> the lab.properties file into the same directory, and the application
> finds it in both cases

Actually I went with a combination of these approaches, and it seems
to be working pretty well:

I used XML, but via Preferences, which has API to export to XML. The
XML is nicely human-{read, write}able, and separated by package, which
allows one to avoid the bazillion-properties-files antipattern. Like
Rich does, I can keep my preferences file either in

* the root of my Eclipse project

* the directory into which the JAR is deployed

Pretty simple and straightforward ... except :-) The main weirdnesses
with which I contended, while setting things up, were

* occasional differences between the actual contents of the backing
  store (where the values actually live, analogous to a Properties
  file) and my expectations. Hence it's often useful to examine what's
  actually there, and occasionally Make It How It Should Be :-) This
  is easy on linux, where (IIUC) the values are stored by default in
  XML files in a package filetree rooted @

  ${HOME}/.java/.userPrefs

  but ...

* On win32 Preferences uses the registry as backing store. Worse yet,
  since registry values are not case-sensitive, it uses the convention
  that uppercase chars in registry names and values must be prefixed
  by a slash, making editing more annoying.

* Java insists on saving the prefs file as a single line (actually 2,
  but 1 is the header

  <?xml version="1.0" encoding="UTF-8"?><!DOCTYPE map SYSTEM 
"http://java.sun.com/dtd/preferences.dtd">

  ) which decreases readability. This is easily fixed with editor
  macros <duh/> though, and Java does not object if you edit/save the
  file between runs.

java.util.prefs, unlike java.util.Properties, is designed to be
extensible to use different databases to hold values. Anyone care to
relate their experiences doing that?