env quoting changes interact poorly with JVM parsers #355

We've had breakages in a couple places in our infrastructure so far due to the new env quoting changes. This is documented in NEWS as an expected change in behavior - but I wanted to flag some real world examples we've hit in case it demonstrates a wider impact than expected:

Here's part of an entry point in one of our OCI images:

env | grep SPARK_JAVA_OPT_ | sort -t_ -k4 -n | sed 's/[^=]*=\(.*\)/\1/g' > java_opts.txt
readarray -t SPARK_EXECUTOR_JAVA_OPTS < java_opts.txt
...
CMD=("${JAVA_HOME}/bin/java" "${SPARK_EXECUTOR_JAVA_OPTS[@]}" ...)

The values become argv for java. With 9.12 any spaced option arrives with literal single quotes, and the executor dies with:

Error: Could not find or load main class '-Djava.net.preferIPv6Addresses=false'

Another example, with plexus-utils<2.0.2:

CommandLineUtils.getSystemEnvVars() does Runtime.exec("env") and splits each line on the first =. Commandline.getEnvironmentVariables() passes the result to Runtime.exec(cmd, envp) for the forked child. maven-javadoc-plugin 2.4 pins plexus-utils 1.4.6, so the forked javadoc JVM gets JAVA_TOOL_OPTIONS='-Xmx2g ...' with quotes intact. The JVM parser treats the quoted span as one token:

Invalid maximum heap size: -Xmx13g -Dfile.encoding=UTF-8 -Dsun.net.client...
Error: Could not create the Java Virtual Machine.