JVM variables escape equals when running from command line

Question

When running a Java application such as

java -Dme.unroll.url=unroll.me?param=val -jar my.jar

Does the = in param=val need to be escaped? This has been surprisingly hard to Google as most of the results are for escaping Unix shell special values. = is not a special character in a shell so

-Dme.unroll.url='unroll.me?param=val'

will be exactly the same. Must = be escaped in this context, and if so how?

The `?` needs to be escaped so that the shell doesn't interpret it as a glob. — devnull, Jun 02 '14 at 17:49
@SotiriosDelimanolis about to run it... I posted the question anyway since it may still be bad practice, even if it works on my attempt. — djechlin, Jun 02 '14 at 18:06
When I tried it with simple `name=value` on Mac, I didn't get any issues. I can't think of any reason why you would. I didn't have a `?` in it though. — Sotirios Delimanolis, Jun 02 '14 at 18:10
@SotiriosDelimanolis Well the ? needs unix-level escaping, that I'm aware of. I can't find doc on this stuff either, which is another reason I posted here. — djechlin, Jun 02 '14 at 18:20

score 4 · Accepted Answer · edited Jun 20 '20 at 09:12

The most normative reference I could find is the Oracle java man page, which states

-Dproperty=value

Sets a system property value. The property variable is a string with no spaces that represents the name of the property. The value variable is a string that represents the value of the property. If value is a string with spaces, then enclose it in quotation marks (for example -Dfoo="foo bar").

As it mentions spaces but not =, I interpret that to mean no = escaping is required. That's somewhat unsatisfying, so I decided to look at what OpenJDK does. As the widely-used reference implementation, its behavior sets a de facto standard.

At least in OpenJDK/HotSpot 8, when parsing -D options, all characters after the first occurrence of = are considered part of the value, so later occurrences of = do not need to be (and should not be) escaped. See the source code, the relevant part of which is

bool Arguments::add_property(const char* prop) {
  const char* eq = strchr(prop, '=');
  char* key;
  // ns must be static--its address may be stored in a SystemProperty object.
  const static char ns[1] = {0};
  char* value = (char *)ns;

  size_t key_len = (eq == NULL) ? strlen(prop) : (eq - prop);
  key = AllocateHeap(key_len + 1, mtInternal);
  strncpy(key, prop, key_len);
  key[key_len] = '\0';

  if (eq != NULL) {
    size_t value_len = strlen(prop) - key_len - 1;
    value = AllocateHeap(value_len + 1, mtInternal);
    strncpy(value, &prop[key_len + 1], value_len + 1);
  }

The call to strchr finds the first =, which is taken to be the divider between key and value.

Other bits of the code look for specific property arguments earlier in the VM start-up process, but all of the places I found did not perform any special handling of =. For example, the Java launcher both sets and checks some property arguments but does not escape or unescape =.

JVM variables escape equals when running from command line

1 Answers1