java.util.prefs.Preferences and arrays

Thread view:

Roedy Green - 29 Dec 2007 04:55 GMT

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?

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Stefan Ram - 29 Dec 2007 05:10 GMT

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

Reply to this Message

Stefan Ram - 29 Dec 2007 05:16 GMT

Supersedes: <Preferences-20071229060807@ram.dialup.fu-berlin.de>

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

Reply to this Message

Eric Sosman - 29 Dec 2007 14:26 GMT

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

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Reply to this Message

Stefan Ram - 29 Dec 2007 14:48 GMT

>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

[b]
class java.util.HashSet

[b]
class java.util.HashSet

[b, c]
class java.util.HashSet

The Junotal tutorial

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

Reply to this Message

Roedy Green - 29 Dec 2007 21:48 GMT

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

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Stefan Ram - 29 Dec 2007 22:04 GMT

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

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

Reply to this Message

Roedy Green - 29 Dec 2007 21:16 GMT

On Sat, 29 Dec 2007 09:26:31 -0500, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

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

Signature

Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com

Reply to this Message

Andrew Thompson - 30 Dec 2007 14:29 GMT

>> java.util.prefs.Preferences does not seem to be designed to store
>> multiple copies of each field (i.e. arrays). Is there a standard
[quoted text clipped - 11 lines]
> "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.

Signature

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

Reply to this Message

Eric Sosman - 30 Dec 2007 15:32 GMT

>>> java.util.prefs.Preferences does not seem to be designed to store
>>> multiple copies of each field (i.e. arrays). Is there a standard
[quoted text clipped - 33 lines]
> 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.

Signature

Eric Sosman
esosman@ieee-dot-org.invalid

Reply to this Message

Mark Thornton - 30 Dec 2007 16:12 GMT

> "god_1=Jupiter", "god_2=Odin", "god_3=Zeus" eliminates
> the marshalling and parsing, and makes length limits less
[quoted text clipped - 4 lines]
> 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

Reply to this Message

java.util.prefs.Preferences and arrays

Free Magazines