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.
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.
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.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Great questions. I'll try to answer them.
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.
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.
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.