java.util.prefs.Preferences and arrays

[Roedy Green]

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?

 

[Stefan Ram]

java.util.prefs.Preferences does not seem to be designed to store
multiple copies of each field (i.e. arrays).

The documentation at

http://download.java.net/jdk7/docs/api/java/util/prefs/Preferences.html

does not use the term »field« in this regard.

You might refer to the value of a key.

Since I do not understand »multiple copies of each field«, but
mention arrays, I assume that you ask how to store an array as
the value of a key.

You might serialize the array to a string or a byte array and
then store this a string or byte array, respectively.

Do you look for some unique data value to use as key, load and sort?
without recording the index?

The documentation at

http://download.java.net/jdk7/docs/api/java/util/prefs/Preferences.html

does not use the term »index«.

I can not comprehend what you refer to with »the index«.

The key can be a string. Choose it as you choose any
other identifier, e.g., a variable name, when you write code.

 

[Stefan Ram]

Supersedes: <[email protected]>

java.util.prefs.Preferences does not seem to be designed to store
multiple copies of each field (i.e. arrays).

The documentation at

http://download.java.net/jdk7/docs/api/java/util/prefs/Preferences.html

does not use the term »field« in this regard.

You might refer to the value of a key.

Since I do not understand »multiple copies of each field«, but
since you mention arrays, I assume that you ask how to store
an array as the value of a key.

You might serialize the array to a string or a byte array and
then store this string or byte array, respectively.

Do you look for some unique data value to use as key, load and sort?
without recording the index?

The documentation at

http://download.java.net/jdk7/docs/api/java/util/prefs/Preferences.html

does not use the term »index«.

I can not comprehend what you refer to with »the index«.

The key can be a string. Choose it as you choose any
other identifier, e.g., a variable name, when you write code.

 

[Eric Sosman]

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"

The first seems more "natural" if the values are thought
of as some kind of collection, but may run into problems if
there are too many of them (Preferences.MAX_VALUE_LENGTH is
8192 characters).

 

[Stefan Ram]

I've encountered two conventions, not specific to Java
but in other key=value "ini file" contexts:
- Composite value: "gods=Jupiter,Odin,Zeus"

The library »ram.jar« contains an implementation of »Unotal«
with support for mutiple values of a single key.

Here is an example from the Junotal tutorial:

Main.java

import java.lang.String;
import java.lang.System;
import de.dclj.ram.notation.unotal.Room;
import static de.dclj.ram.notation.unotal.RoomFromModule.room;

public final class Main
{ public static void main( final String argv[] )
{ System.out.println( room( "< a=b >" ).get( "a" ));
System.out.println( room( "< a=b >" ).get( "a" ).getClass() );

System.out.println( room( "< a=b a=c >" ).get( "a" ));
System.out.println( room( "< a=b a=c >" ).get( "a" ).getClass() );

System.out.println( room( "< >" ).getValues( "a" ));
System.out.println( room( "< >" ).getValues( "a" ).getClass() );

System.out.println( room( "< a=b >" ).getValues( "a" ));
System.out.println( room( "< a=b >" ).getValues( "a" ).getClass() );

System.out.println( room( "< a=b a=b >" ).getValues( "a" ));
System.out.println( room( "< a=b a=b >" ).getValues( "a" ).getClass() );

System.out.println( room( "< a=b a=c >" ).getValues( "a" ));
System.out.println( room( "< a=b a=c >" ).getValues( "a" ).getClass() ); }}

System.out

b
class de.dclj.ram.notation.unotal.StringValue

[b, c]
class de.dclj.ram.notation.unotal.SprayValue

[]
class de.dclj.ram.notation.unotal.SprayValue


class java.util.HashSet


class java.util.HashSet

[b, c]
class java.util.HashSet

The Junotal tutorial

http://www.purl.org/stefan_ram/pub/junotal_tutorial

 

[Roedy Green]

- 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"

thanks. I have added those solutions to the entry at
http://mindprod.com/jgloss/preferences.html

 

[Roedy Green]

http://www.purl.org/stefan_ram/pub/junotal_tutorial

please have a look at http://mindprod.com/jgloss/junotal.html
to see if I accurately summarised Junotal.

 

[Stefan Ram]

please have a look at http://mindprod.com/jgloss/junotal.html
to see if I accurately summarised Junotal.

Thanks for the summary! I see no mistakes on your page.

 

[Andrew Thompson]

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.

The first seems more "natural" if the values are thought
of as some kind of collection, but may run into problems if
there are too many of them (Preferences.MAX_VALUE_LENGTH is
8192 characters).

FTR. There was no real risk of hitting that limit with the
data I was dealing with.

--
Andrew Thompson
http://www.physci.org/

Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200712/1

 

[Eric Sosman]

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.

 

[Mark Thornton]

"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.

A hybrid approach is
gods=god_1,god_2,god_3
god_1=Jupiter
etc
This eliminates the count (the extra keys need not be sequential either).

Mark Thornton