2

Is there a use-case for custom JVM parameters (what are custom jvm properties?) that is impossible to replicate using regular program arguments? In other words, are they strictly necessary or simply a programming convenience?

Here is a use case for JVM arguments that is not strictly necessary:

java -jar -DmyCustomArg="my_value" MyFile.jar

Where somewhere in MyFile is the following code, pulling out the property:

String s = System.getProperty("myCustomArg");

This property is not strictly necessary because we can replace it as follows:

  1. Declare a map class in MyFile e.g. a HashMap mapping key value pairs, and use the singleton pattern to instantiate one instance of this to be used across the entire program
  2. Read in a program argument called myCustomArg, see Proper usage of Java -D command-line parameters for the difference between program and JVM System arguments.
  3. Add code to MyFile to load the program argument into the hash map
  4. Replace the above system property retrieval with hash map retrieval

Obviously, to do all of the above would be a lot less convenient than just adding & retrieving a JVM property. But my question: is there a qualitative difference between the two, i.e. is there a use case for JVM parameters where there is no way to achieve the same thing with regular program arguments? Or, are custom JVM arguments that we add simply a convenience that lets us avoid declaring and using our own Properties object like a Map?

Colm Bhandal
  • 3,343
  • 2
  • 18
  • 29

1 Answers1

0

Having -D overrides for properties is very nice in situations where you want to control application startup via environment variables (e.g. when using docker). With spring and other frameworks, there typically is a pecking order for finding the right configuration value for a property where overriding it via JVM arguments is the ultimate fallback after first looking in properties file in the jar file or on the filesystem. There are also many system properties specific to java itself that govern things like default encoding, proxies, dns caching, and other things.

The main thing here is the principle of the least amount of surprise. It's just how configuration works in Java and has worked for 20 or so years. You can work around it if you want to but why would you do that? In other words, what is your objection against this?

Jilles van Gurp
  • 7,927
  • 4
  • 38
  • 46
  • Thanks for the response, all very useful practical information. However, my question is less about practicality and more about possibility. Is there a use case for a custom JVM property where it can't be done otherwise? I have no objection to using JVM properties, I'm just trying to find out if they're absolutely necessary or just a convenience. BTW I'm not talking about the system properties specific to Java- I can see why they're needed. I'm talking about custom ones that we define & use ourselves. – Colm Bhandal Jun 26 '17 at 12:18
  • You can basically set any System property programmatically if that's what you mean. There's no difference between java's own system properties and the ones you add yourself. In that case, you need to do that before you read them obviously. For example at the beginning of your main method would work. – Jilles van Gurp Jun 26 '17 at 16:16
  • Jilles, unfortunately no that is not what I mean. I mean is there a scenario where using a custom JVM property is the only way to achieve some end? That is, where there is no feasible alternative, within reason? Or is it just convenient for us to be able to dump things into this pre-defined map rather than define our own map. – Colm Bhandal Jun 26 '17 at 17:04
  • No, I thought that was clear. System properties aren't magic; it's just a hash map. Either you put stuff in it or you put it somewhere else: it's up to you. There are of course bits of code that come with the JDK that read properties from the system properties beyond that you can do whatever you want. – Jilles van Gurp Jun 30 '17 at 09:25