Well, first of all that's not valid Java code. Secondly, System.getProperty() does not get properties from a file properties.conf, as far as I'm aware.

You will want to include a default properties file as a resource in your JAR and load it with Class.getResourceAsStream(). Then, if you want the user to be able to change properties, load an additional properties file from disk. It looks like this:

For this to work, the application.properties file containing the default properties must be in the same package as the Application class, although the packages can be in different source folders as long as both folders are in the source path when you build the application.

For complex systems, it's not uncommon to store system-wide property overrides in "/etc/myapplication.conf" or as a file in "/etc/myapplication/" on Unix-like systems. Windows, alas, doesn't have an equivalent that I can think of and the Registry isn't well-suited as an OS-indpenendent property source.

For an extra level of customization, you can make a properties file based off the user.home directory. The popular approach these days is to place the user properties file in the user's $HOME/.config directory (note the dot - it's a hidden directory). This is a refinement on the older style where every app's properties file was anchored directly in the user.home directory itself. Once it became normal to have dozens of apps, it tended to clutter the home directory, so now we have .config. Again, this is Linux/MacOS, but you could make a .config directory under the user.home in Windows and few would complain, I think.

Since Properties can stack, you can arrange user preferences to override system preferences which override built-in preferences on an item-by-item basis.

When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.

Absolutely 100% true. However it's worth mentioning that you have to use the load(Reader) method of Properties, as you did in your code, to be able to use UTF-8. If you use the load(InputStream) method then it annoyingly defaults to ISO-8859-1.

Stephan van Hulst

Saloon Keeper

Posts: 10136

214

posted 1 week ago

I always roll my eyes when an API that works with textual data, such as XML processors, supply convenience methods that accept InputStream. Making assumptions about the encoding is what causes confused programmers and heaps of bugs.

Stephan van Hulst wrote:I always roll my eyes when an API that works with textual data, such as XML processors, supply convenience methods that accept InputStream. Making assumptions about the encoding is what causes confused programmers and heaps of bugs.

Well, in the case of XML processing, the encoding is specified in the header and the processor is supposed to reject bad input. Not just illegal characters, but generally stuff that's syntactically invalid and stuff that's semantically invalid. To the point where it can get really frustrating trying to persuade it that you don't want the XML cross-checked against a DTD or schema.

Other systems, of course, have other methods, some more rigorous than others.

When it comes to destroying a civilization, gas chambers cannot hold a candle to echo chambers.

Stephan van Hulst

Saloon Keeper

Posts: 10136

214

posted 1 week ago

I suppose an exception can be made for formats that have explicit constraints on the encoding. You're right, XML was a poor example on my part.

I didn't like the taste of tongue and it didn't like the taste of me. I will now try this tiny ad: