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