Store Objects Using the JDK 1.4 Preferences API

An anonymous reader writes "The Preferences API -- a lightweight, cross-platform persistence API introduced in JDK 1.4 -- is designed to store small amounts of data (string, simple byte arrays, and so on.) and was not intended to be an interface to a traditional database. It can, however, be effective as a storage device if your data can be expressed as simple objects. This article offers an introduction to the API, explains how objects are stored, demonstrates the process in action, and provides a code library to do the work."

Re:Half an hour and no first post?

[laa]

The other two being English and awk?

Re:Half an hour and no first post?

[Pieroxy]

Giving that the first one is obviously Chinese, I doubt it...

Re:Half an hour and no first post?

[BigGerman]

It is not just language the article is pretty much pointless.
People did exactly the same things with Properties since Jdk1.1

Re:why not...

[dr_steel]

That's effectively what he does. Uses the serialization api to allow storing arbitrary objects with the Preferences api...

Decent idea... only limited use, though

[jtheory]

Quick summary: The Preferences API in Java 1.4 doesn't support storing an Object value, but we can hack around that by serializing the Object into a byte array, and storing limited length chunks as prefs.

This is NOT a replacement for an object db, just a way to make storing your prefs more flexible.

Personally, I don't think it's worth the trouble. Preferences are already hierarchichal (so there's no real gain in data organization). In most cases this will save only a few lines of code.

And in exchange for those lines of code, we do lose some things: the complexity added by putting another layer on top of the prefs API, for one, and the fact that debugging would suck (instead of readable data in your preferences, you now have chunks of serialized object).

So.. go for it if it would make your life much easier to store prefs as objects. Everyone else... read the article ANYWAY -- because it shows nicely how simple it is to use the Preferences API -- but you probably needn't bother to download the source.

Caveat -- I don't maintain any large Java apps with lots of preferences... but it seems to me that most prefs won't come automatically as objects.

Is this guy serious?

[animaal]

I had to look twice at the article, I couldn't believe it was written by IBM. I really don't like this guy's approach. I'd much rather store the values that were used to create the objects, rather than the objects themselves. Here's my reasoning:

1. It's quite likely that the objects will be much larger than the intiialisation parameters. For example, for a Font object on given JDK, the initialisation parameters are a string (name) and integer (size). The Font object created could potentially have all sorts of internal data structures.

2. Storing the parameters rather than the object will allow the user/admin to manually alter the preferences later. Think of the Windows registry. It's much easier to change an ASCII value than a binary object. It also becomes easier to examine/inspect the values. Never mind having a binary object spread over multiple binary preference values.

3. What about debugging the code for the application that created the preferences? Related to (2) above, I'd hate to be examining a dump of the binary objects, spread over multiple property values.

4. Dumping binary objects leads to a JVM-specific repository. Again, using the Font example, storing the name and size would produce two values that could be used on any other JVM to produce a valid font (at least I think Java still uses default font values if it can't find the requested one?). Whereas, dumping an actual Font object results in the storing of the specific implementation of the object used. This means that if the user upgrades their JVM to a more recent version (e.g. JDK1.3 to JDK1.4), all their previously stored preferences may be unreadable.

5. Realated to (4) above, it also makes reproducing bugs difficult. I.e. a user says "I hve this crash...". You can't ask for an export of the user's preferences, because they're specific to the JVM that user used. It's also impossible to tell, from a glance, exactly what those preferences even are.

I usually find IBM's articles extremely interesting, but I'm afraid I'm very disappointed with this one.

Re:Is this guy serious?

[psychofox]

4. Dumping binary objects leads to a JVM-specific repository. Again, using the Font example, storing the name and size would produce two values that could be used on any other JVM to produce a valid font (at least I think Java still uses default font values if it can't find the requested one?). Whereas, dumping an actual Font object results in the storing of the specific implementation of the object used. This means that if the user upgrades their JVM to a more recent version (e.g. JDK1.3 to JDK1.4), all t

Poorly designed -- no decoupling of persistence

[rdeadman]

The Preferences API has one fatal flaw, it binds persistence to a JVM implementation. That is, if you store preferences using the Sun SDK and then run your application later using the IBM JVM, your Preferences are not available. This coupling of persistence to the JVM should never have taken place and breaks the tacit assumption that applications are decoupled from the JVM they run on. For enterprise applications, this could be devastating during a JVM upgrade.

For the record, I did object during the JCP process, and even offered a modification to the architecture, but was dismissed.

I wrote a more extensive criticism of this API in the Java Developer's Journal back in March of 2002. An on-line version (with some of the preamble truncated) is available here [sys-con.com].

GConf anyone?

[ebassi]

Preferences tree? XML backend?

Why this API reminds me of Havoc Pennington's GConf [gnome.org] used by GNOME 2?

not worth it

[sna899]

I don't think it's worth the trouble. I also don't like this guy's approach.

Overtime Laws [paymyovertime.com]