Preferences MAX_KEY_LENGTH Why?

[Jacob]

Why is there a limitation on key length
in the Preferences module?

It's 80 (JDK 1.4.2) and I easily exceed
this => Exception!

Is there a work-around?

Thanks!

 

[Thomas Weidenfeller]

Why is there a limitation on key length
in the Preferences module?

Maybe because Sun had to ensure that it works with some existing
mechanism on a specific OS. So they decided to limit the length to
something they can support on all platforms.

It's 80 (JDK 1.4.2) and I easily exceed
this => Exception!

Is there a work-around?

Sure. E.g. number your preferences. That would give you 10^80 keys if
you use decimal numbers, and 16^80 if you use hex numbers.

Note, the number of atoms in the univers is estimated around 10^79. So
you could provide approx. 10 keys for each atom in the univers. I think
that should do it.

If you want readable keys inside your application, just add an
intermediate step which converts your keys to numbers (hashing comes to
mind) first, and then access the preferences.

If you need readable keys in the Preference database, too, then you
have to think about useful abbreviations, and maybe still some
numbering.

/Thomas

 

[Jacob]

Sure. E.g. number your preferences. That would give you 10^80 keys if
you use decimal numbers, and 16^80 if you use hex numbers.

My keys are not just very long strings,
but passages with a semantic meaning.

I use Preferences to implement a session
mechanism (save/restore of program states)
and they may look something like this:

Program.User.com.company.some.package.and.Class-1.windowWidth

etc. In particular the use of class names
as keys are powerful, but easily breaks
the 80 character limit.

 

[Sudsy]

I use Preferences to implement a session
mechanism (save/restore of program states)
and they may look something like this:

Program.User.com.company.some.package.and.Class-1.windowWidth

etc. In particular the use of class names
as keys are powerful, but easily breaks
the 80 character limit.

So have you thought about storing the class name portion in a more
compact manner? Here's what Sun does:
<http://java.sun.com/j2se/1.4.1/docs/guide/serialization/spec/class.doc6.html#4100>

 

[Thomas Weidenfeller]

and they may look something like this:

Program.User.com.company.some.package.and.Class-1.windowWidth

etc. In particular the use of class names
as keys are powerful, but easily breaks
the 80 character limit.

I repeat myself: Calculate e.g. a hash, and use the hash as a key
instead. Or consider not abusing a preference mechanism for object
persistance.

/Thomas

 

[Jacob]

I repeat myself: Calculate e.g. a hash, and use the hash as a key
instead. Or consider not abusing a preference mechanism for object
persistance.

I'd like to use a hashCode mechanism, but I am not sure how.
The getClass.hasCode() method returns different value for
each run. I guess computing a checksum might be a possible
approach?

And please explain why you consider this "abusing" the
preference mechanism; I do like to improve my skills on the
subject. I for instance regard a window position and size as
a "user preference". I store this setting using java Preferences
with keys like "width", "height". Then:

o As I have many window types to consider I prefix the settings
with the window class name.
o As there may be several windows of the same type I postfix
the setting with an integer index.
o As there are different users to my system, I prefix the setting
with the user name.
o As each user can have named sessions, I prefix the setting
with the session name.
o As I have different executables within the same java
package tree, I prefix the setting with the executable class.

As you can see, the keys becomes quite verbose, but I can't
see that this is "abuse" still. Poweruse maybe...

Thanks!

 

[John C. Bollinger]

I'd like to use a hashCode mechanism, but I am not sure how.
The getClass.hasCode() method returns different value for
each run. I guess computing a checksum might be a possible
approach?

That's not equivalent to what you were doing before. Hash the class
_name_ (a String) not the Class object. That ought to be repeatable.
I.e.: getClass().getName().hashCode().

[...]

As you can see, the keys becomes quite verbose, but I can't
see that this is "abuse" still. Poweruse maybe...

From an earlier message:

I use Preferences to implement a session mechanism (save/restore of
program states)

That is pushing what preferences are intended for. "Abuse" might be a
little strong, but not very much so.

In any event, you could greatly reduce your key length without losing
any information by using the hierarchical structure provided by
Preferences instead of storing everything in one Preferences node.


John Bollinger
(e-mail address removed)