Quote:

---

First of all, the reason we use property files in the first place, instead of hardcoding the properties in the code, is because we want the people who use the application to be able to change them.

---

Quote:

---

But what must the user do in order to change some properties? First of all, he must locate the property file inside the archive. Next, he must unpack the archive, change the desired properties, and pack the archive again... Seems to me a lot of trouble for the poor user! Not to mention signed jar files, where the problems are even bigger!
Just how many times did you find yourself looking through some ".jar" files looking for a "jndi.properties" file? And what if you find the file twice in the classpath? which one is loaded?

Seems to me that in this case, the user has much more trouble than just editing a good old fashioned /etc/someapp.conf file (I know, portability issues, etc.), but...

---

Ok, now let's say that you do want user-editable properties. But I don't follow you connection from editable properties to them necessarily being loaded as java.io.Files.

What if you told the user to edit a .properties file located, say, in <jre dir>\classes -- is that really hard? You can load this as a classpath resource and the changes will be picked up on the next JVM restart.

(c) finally, there are tons of resources that the user might know about but will never have to edit. For example, let's say your application can parse user XML files written to a certain (well-known) XML schema. You can load the .xsd schema definition as a classloader resource, can't you? The user never has to edit that.

Or as another example, instead of hardcoding all label/frame/etc titles in you Swing code, why not put them in a classpath .properties definition? This way you separate your visual content from the actual implementation. You can later localize it or fix typos by merely editing the non-compilable resource and again the user never touches such properties.

Or if not text labels, consider .gif icon images instead: why do you expect the user to ever want to edit them? Surely you can load them as a classloader resource as well.

A Java application of any reasonable level of complexity will have several such resources that are best loaded via classloaders. And for properties that are specific to an individual user's experiences (e.g., the size of his/her Swing windows etc) there is always the java.util.prefs API (load your defaults as a classpath resource and save user changes via java.util.prefs, registry, etc)...

Post Extras