What is best practice for setting java system properties, -D or System.setProperty()?

Question

I need to set the codebase for the RMI application I'm working on at the moment and have done this successfully using first

try{
  ResourceBundle config = ResourceBundle.getBundle("myApp");
  String codeBaseUrl = config.getString("codeBaseUrl");
  System.setProperty("java.rmi.server.codebase", codeBaseUrl);
} catch (Exception e) {
  e.printStackTrace();
}

and later using

java -Djava.rmi.server.codebase=http://192.168.1.1/path/to/codebase ...

on the command line.

Both of these approaches allow for the codebase to be changed without the need to recompile, but the System.setProperty approach allows codebase to be bunlded into a properties file and the same launch command to be used.

Most of the tutorials/documentation I've read on this uses the -D approach leading me to believe this is accepted as best practice, but I've been unable to find anything that explains WHY I should use over the other.

Is -D considered best practice for setting system properties such as codebase, and what benefits does this give / what pitfalls does it avoid?

Answer 1

(Edited - I mis-read the question)

Comparing the two:

• -D is configurable - it's specified at runtime
• A resource bundle via System.setProperty() is still "runtime", but it's edited via a file which lives beyond the start-up command

Firstly, driving flexible behaviour by specifying settings at runtime is always preferable to hard-coding behaviour (unless the behaviour isn't actually flexible - ie don't use configuration unless there is value in doing so).

The main downside to using a file is that it may contain sensitive data, like passwords, that sysadmins don't want permanently lying around on disk. If the password is entered as part of the start-up command, it's ephemeral and much more secure (session command history not withstanding).

The upside to using a file is that you can establish the correct settings and they stay in the file. You can even manage the file via source control.

There's another even safer option, which is the have the start-up ask for passwords to be entered on the command line, which leaves no trace.