AW: Can't fork VM if option value contains space

[Aleksey Shipilev]

Ah, got it. This is the impedance in -jvmArgs handling.

In all other places, including the Java API and annotations, we pass
String[], where each individual String is the argument (may be with
spaces). This fits nicely into Runtime.exec(String cmd, String[] args)
API, and it will handle the spaces correctly.

However, for -jvmArgs, we only get String, and then we blindly split it
by space to produce String[]:
 http://hg.openjdk.java.net/code-tools/jmh/file/60e8aae7ac7d/jmh-core/src/main/java/org/openjdk/jmh/runner/options/CommandLineOptions.java#l405

Therefore:

On 08/12/2014 04:09 PM, Dmitry Vyazelenko wrote:
> On Tuesday, August 12, 2014 1:34 PM, Dmitry Vyazelenko <vyazelenko at yahoo.com> wrote:
> Well it is even more strange on Windows:
> - On command line:
>   FAILS: java -jar target\benchmarks.jar -jvmArgs -Dmy.prop="A B C"
>   Does not start benchmark execution.

...forked command line has individual argument "B", which fails, because
VM thinks "B" is the Java class name.

>   WORKS: java -jar target\benchmarks.jar -jvmArgs -Dmy.prop="\"A B C\""
>   Runs and produces this result:
>          Iteration   1: my.prop ==> A B C

...forked command line also has "B" as the individual argument, but VM
launcher seem to reconstruct the "-DmyProp=\"A", "B", "C\"" into
"-DmyProp=A B C".

> - Using Java API:
>   FAILS: new OptionsBuilder() 
>                 .jvmArgs("-Dmy.prop=\"A B C\"").build();
>   Does not fork VM.

...one level of quotes seem to be digested by Runtime.exec.

>   WORKS: new OptionsBuilder() 
>                 .jvmArgs("-Dmy.prop=\"\"A B C\"\"").build();
>   Runs but produces wrong result:
>          Iteration   1: my.prop ==> "A B C"

...putting another level of quotes helps.

>   RUNS: new OptionsBuilder() 
>                 .jvmArgs("-Dmy.prop=\\\"A B C\\\"").build();  
>   Runs but produces wrong result: 
>          Iteration 1: my.prop ==> "A B C" 

...the quotes are properly escaped from Runtime.exec.

>   WORKS (no quoting): new OptionsBuilder() 
>                 .jvmArgs("-Dmy.prop=A B C").build();
>   Runs and produces correct result: 
>          Iteration 1: my.prop ==> A B C"

...and this is a correct and most straight-forward scenario.

All this feels rather messy cross-cutting issue across multiple shells,
VMs, etc. At this point, I am a bit puzzled if we can do anything about it.

Thanks,
-Aleksey.