• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Ron McLeod
  • Junilu Lacar
  • Paul Clapham
  • Liutauras Vilda
  • Jeanne Boyarsky
  • Rob Spoor
  • Bear Bibeault
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Piet Souris
  • Carey Brown
  • Stephan van Hulst
  • Frits Walraven
  • fred rosenberger
  • salvin francis

java.util.prefs.* -- Some initial impressions

Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Well, on the advice of forum participants, and to satisfy my own curiosity, I have taken a look into the java.util.prefs package (read "played around with it a bit"). And now I have a few initial impressions concerning the replacement of the (aging) java.util.Properties class.
There are a couple of things that I like, and a few that I don't. I'll start with the positive ones.
1) It's pretty easy to use. Once you get used to the DTD, it isn't hard to write preference files from scratch. Of course, as with all XML, it helps to have an XML-aware text editor.
2) File I/O is identical to that used by the load() and save() methods of the Properties class, so no re-learning there.
3) Properties, um, excuse me, *Preferences* are easily persisted from one execution to the next. More about this later.
4) Preference Nodes can be nested, so you can build some rather complex data structures, if you're in the mood.
5) It is easy and natural to segregate system and user properties.
6) It enforces data type restrictions on keys and values (the java.util.Properties class can be tricked into violating this).
Now, on to some things that trouble me about this new API.
First, about the DTD; both the keys and the values are stored as attributes of the <entry> tag. That's okay right up until you have a rather long value string (I believe that keys should remain simple, so I have no issue with keys being attributes). I currently use properties files to store some SQL queries, so stuffing that sort of string into a tag attribute might be problematic.
Secondly, the persistance behavior is alarming, to say the least. Without calling anything that even remotely resembles an output method, the preferences read from the XML file are persisted. How? Well, that required some detective work -- I won't bore you with the discovery details. On my Win32 machine the Preferences class wrote to the registry, and I haven't figured out how to disable that. It's fine if you have an application that sports both install and uninstall scripts, but how many web applications have you seen that are like that?
So, what I got was a collection of registry keys that won't go away unless I remove them -- manually or otherwise. I don't relish the idea of polluting the registry on a production server with my application properties.
And on my Linux box, I got some truly hideous directory names out of the deal. If you really want to piss off your sysadmin, try creating a directory with a name like
I was a bit upset when I saw that one.
Now, perhaps I'm over-reacting, but it's not immediately obvious from perusing the API how to tame these nasties. And there was no warning at all about Windoze registry writing or unfriendly directory names in UN*X. In fact, there was no warning about the unexpected persistance in general. Maybe I just didn't read far enough.
The value-as-an-attribute thing has an easy work around; simply catch the SAXParseException that gets thrown when the parser finds no value attribute (Attribute value for "value" is #REQUIRED); the text node of the <entry> tag gets picked up regardless. But then, how elegant is that?
I think that for the time being anyway, I will stick with my own minimalist re-implementation of the Preferences class (based on LinkedHashMap, to maintain ordering). I haven't seen any compelling reason to re-work old code, and I don't think I want to take on the persistance issues in new code.
I think that this could really be something if I were to sit down and do my own implementation using the java.util.AbstractPreferences class, but I haven't got the time right now.
I welcome feedback -- especially if you can show me how I am totally missing the boat with this wonderful new Java API
[ November 20, 2002: Message edited by: Philip Shanks ]
Philip Shanks
Ranch Hand
Posts: 189
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay, I should have guessed from the API docs that the Windoze registry would be involved:

FROM THE Java 1.4 API: java.util.prefs.Preferences
This data is stored persistently in an implementation-dependent backing store. Typical implementations include flat files, OS-specific registries, directory servers and SQL databases. The user of this class needn't be concerned with details of the backing store.

But I still take issue with that last statement. If you are designing an application that is writing to the registry, you darn well ought to know all about it, and clean it up when it is no longer needed.
And that goes double if you are creating unfriendly directory names on a UN*X file system.
You showed up just in time for the waffles! And this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
    Bookmark Topic Watch Topic
  • New Topic