Re: java.util.prefs.Preferences and arrays
Andrew Thompson wrote:
Eric Sosman wrote:
java.util.prefs.Preferences does not seem to be designed to store
multiple copies of each field (i.e. arrays). Is there a standard
convention to fudge it?
Do you look for some unique data value to use as key, load and sort?
without recording the index?
I've encountered two conventions, not specific to Java
but in other key=value "ini file" contexts:
- Composite value: "gods=Jupiter,Odin,Zeus"
- Prefix-and-number key families: "god_1=Jupiter",
"god_2=Odin", "god_3=Zeus", sometimes accompanied
by "god_count=3"
Huh! I was faced with a similar problem recently, and
the 'second solution' would have fit my needs* better,
but it never occured to me define a var_count attribute.
* But now I mention it, the real reason I wanted to follow
the second strategy was that my data might contain the
',', or '|', or '"' (double quote) or ''' (single qoute) and I simply
did not have the ..grit to feel I could handle parsing the
data back out, with potentially any or all of those characters
embedded in the data.
When I step back and look at it, it seems I was 'wimping
out' on using the first solution simply because I couldn't
figure how to split the data at the end.
What are your* thoughts/recommendations re. my favoring
the second approach?
* Eric specifcally, but anyody that feels interested, is
welcome to chime in - I am no 'design guru' and could
probably gain tips from people who I've referred to the
JDocs within the last 24 hours.
I'm no design guru either. These are not my inventions,
but merely things I've run across in similar contexts. But
as to the pros and cons (as they appear to me):
"gods=Jupiter,Odin,Zeus" seems to me the best expression
of the idea that the value of some key is in fact composite:
a collection of some kind. It requires that you be able to
marshal and later parse the composite value, which could be
troublesome and could run into length limits.
"gods=(Jupiter,Juno),(Odin,Freya),(Zeus,Hera)" hints
at ways one might handle values with further structure. Lisp
shows us that such representations are quite powerful -- but
also shows us they can be carried to extremes.
"god_1=Jupiter", "god_2=Odin", "god_3=Zeus" eliminates
the marshalling and parsing, and makes length limits less
likely to cause trouble. On the other hand, it now requires
that you parse the keys in a traverse-all-keys operation, or
generate and query god_1, god_2, ... until you find a god_N
that yields "no such key." This could be fragile if the
repository (may we call it Valhalla?) is edited independently
and gaps are accidentally introduced in the god_N sequence.
Adding "god_count=3" introduces some redundancy that may
improve error detection; you can detect that god_2 is missing,
and you might even protest if you found god_4 present. But I
don't much like this if Valhalla can be edited manually; it
makes me nervous and cranky when a human being is required to
keep two nominally different pieces of information in synch.
In Java we write `new String[] {"Jupiter", "Odin", "Zeus"}'
and let the compiler figure out the `[3]' on its own; similar
ideas are at work.
Finally, if the collection of gods is really large and/or
really intricate, it's not clear that the Preferences mechanism
is the best storage medium. It's convenient, yes, and if you're
already using Preferences for other things it's an easy step
just to add a few more keys -- but at some point you may want
to think about valhalla.xml or some other alternative.
--
Eric Sosman
esosman@ieee-dot-org.invalid