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 mean, come on, people. Java is one of the top three languages used on this planet, after all.
just use the serialization API?
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.
There are only 10 types of people: those who understand decimal, those who don't, and, uh, 8 other types I forget.
Can someone explain why anyone would choose this method of serialization over XMLEncoder?
i ng-so syndrome (only slightly more useful than TCP over carrier pigeon).
This seems like just another case of look-what-i-can-do-without-any-real-reason-for-do
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.
The preferences API IMHO is one of the worst designed in the Java standard library. It is a poor copy of the windows registry interface designed to integrate well with the registry. It does not have a decent back end for unix, has no notification for concurrent modification of preferences, is limited in the type and size of data which can be stored (bad hacks like the one in the article aside) and has limited support for systemwide and personal data storage. Also there is no transactional capability.
I'd strongly recommend not using it.
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.
Preferences tree? XML backend?
Why this API reminds me of Havoc Pennington's GConf used by GNOME 2?
You can save space. Or you can save time. Don't ever count on saving both at once. -- First Law of Algorithmic Analisys
Overtime Laws