Hi

I agree about properties that are not user editable (except with the example with labels, which is a i18n issue, and should be kept as resource boundle).
I was reffering to application properties that are user editable (note that I say user editable properties, not user preferences, there is a clear distinction between these two concepts). I am sorry I did not make it clear in my previous post.

However, I think that the solution with a directory that contains the configuration porperties, and that the user (or shell script that starts the app) must add to classpath does not have more benefits than loading the properties using java.io.File (the config dir can be pased to the application as a system property by the startup script, or by the user).
However, sometimes the second solution could be "cleaner" than the first one (I am thinking about the example with a properties file that appears twice in classpath).
This is what I wanted to point out in my previous post, sorry again I did not make it clear.

Featured White Papers