re: The Java Preferences API Is a Little Thing That is a Huge Benefit VIEW POST


While reading from the Windows Registry is cool, I have a few questions:

  1. How do you source control such configurations?
  2. How do you scalably change & deploy such configurations on a cluster of machines?
  3. Do you think not having the configuration in the source code abstracts things away from the developer? Now, they have to remember to look in a different location altogether just to see what the default configuration should be. Ramping up new developers on the team would also be a pain.

Great questions. I'll try to answer them.

  1. The Java Preferences exchange format is an xml file (see the Preferences API). One could write a file and put that into source control. The application could be written such that on initial startup, it will look for such a file and import it.

  2. Again, I mention in my post that knowing when to use them is the key to success. Perhaps another bullet item is in order where I say that the deployment size is known. One other option is that if you want to scale this out, write your own PreferencesFactory as I describe that meets your needs.

  3. Yes, I believe this abstracts things away from the developer, but in a good way. I mention in my post that if you can build in an editor for your preferences then that helps keep the user focused on the application, not where the configuration is written. Also, I have linked to import and export tools in my dotfiles repository. This adds work no more than having to get access to an application's configuration (if that's necessary) and editing/learning what settings do what. It's just a different set of steps to follow.

Please keep in mind that I don't propose this as a "one size fits all" approach to configuration. This is a good choice when the application can use it. It's up to you as the developer to figure out when you can use it.

code of conduct - report abuse