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.
Store objects using the JDK 1.4 Preferences API
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
In reading this tutorial, I couldn’t help but wonder- why not use something a little better? That is, for saving the really simple stuff- numbers and strings- it’s easy, nothing to it. But for anything more complex, you’re stuck doing a bunch of tricks to put your objects in a store that doesn’t seem designed for them. Wrong tool for the job, anyone? If you want to store serialized objects, why not use a simple, but more featured OODB, or perhaps a binding to Unix dbm or Berekeley DB?
The reason for all these non-RDBMS solutions lately is due to the fact that relation and object oriented supposedly don’t mix. However it is a storage technology that has had a serious amount of time invested into it. It would be very easy to enfore strict OO use when using a relational database. However the current JDBC architecture doesn’t allow for a simple OO structure. An extended Map would solve the problem of using indexes for fields. And if you want performance. Use the indexes. That’s how C++ does it in say ADO. You can either loop through the recordset itself or an array if performance is what you want. But to disregard the value behind an RDBMS is just being over-zealous.
Hell now RDBMS is becoming a layer to a filesystem. Which makes me drool at the possiblities and rightly should. So until an OODB or other pesistent storage API can do any better than an XML or RDBMS I have to say it’s pointless for a serious solution. But hell it can save you the $300k+ on Oracle if that’s the performance you demand so who knows….
From revaaron
Wrong tool for the job, anyone?
It’s something that could easily be abused and drift into the wrong tool, but for simpler data, it’s fine.
The Preferences API is essentially a Java clone of the Window Registry.
The primary motivation for using it is simply that it’s “Free” with Java, and requires pretty much no install or administration.
This article is focused on the fact that sometimes you want to store something more robust than a simple scalar or string.
From GK
It would be very easy to enfore strict OO use when using a relational database.
No, it wouldn’t.
There are several issues with OODBs. One is simply that the entire industry is oriented around the Relational Model, particularly back office and finance (a huge consumer of software). Given that, the network effect of 3rd party tools that work with RDBMSs helps leverage the data even more.
Mapping object data onto relational tables, and being able to include details specific to OO programming, notably inheritance, is a Hard Problem, especially if you want it to be efficient. Plus, once you’ve converted the model into an RDBMS, the data model that may be straightforward for OO systems are just horrible for those 3rd party tools I mentioned earlier. Complicated object models tend to be finer grained thatn RDBMS data models.
Finally, recall that in classic OO programming, an object is not simply data, but a combination of state and logic. Store away the state of an object and you have simply that: the state, not the entire object.
This is especially important as the model evolves and versioning starts to raise its ugly head. If I go into a Smalltalk image and add a slot or method to a class, then boom — it’s done. All of the current instances in the system are made compliant (if not immediately, then lazily later).
Many OODBMS systems handle this versioning transparently, promoting instance change as the instances are loaded into the system. But, say in an RDBMS that you tried that and half of the instances were promoted and half were not. When you go “behind the back of the object layer” (with something like, say, Crystal Reports connecting straight to the DBMS), you have potentially corrupt data.
Managing all of these issues with OO system to RDBMS systems is a lot of work, and the frankenstein result gives you something that compromises both models. That may well be adequate for some applications but it really brings the worst sides of both worlds.
Because one doesn’t need to. The preferences api is designed to store preferences. And they are often simple.(last window location/size, state of checkboxes, a login name, last visited url, etc. ). You don’t want to drag a big db engine into a user application. Sure, you could use berkeley db, all you need is to write a service provider for the Preferences api. Even writing a gconf service provider ought to be fairly trivial.
All in all, the preferences API is well thought trough and does the job in a very nice way.
Just to somewhat mirror what the last poster said, I think the one thing that is great about the Preferences API is it is not tied directly into any storage medium. You can extend AbstractPreferences and/or PreferencesFactory and set it up to use whatever backing store you wish.
Having said that though, it was not the easiest thing to find documentation on