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

[Bernd Eckenfels]

Hello,

I think it is a bit hard to solve because the Java Launcher had to do its own parsing on Windows but not Unix (and it seems to do more than needed on OSX?)

(Don't even look at the apache commons exec, it does use /bin/sh -c and breaks even the simple Unix case*)

Maybe the requirement for passing hard to parse system properties can be reduced (to passing only VM and system lib controlling switches but no dynamic benchmark parameters) by offering a better interface to environment variables? having said that, what is the OP's use case?

Gruss
bernd

* https://issues.apache.org/jira/browse/EXEC-82?jql=project%20%3D%20%22EXEC%22%20AND%20resolution%20%3D%20Unresolved%20AND%20status%20%3D%20Open%20AND%20text%20~%20%22quote%22%20ORDER%20BY%20priority%20DESC%2C%20key%20DESC
-- 
http://bernd.eckenfels.net

----- Ursprüngliche Nachricht -----
Von: "Aleksey Shipilev" <aleksey.shipilev at oracle.com>
Gesendet: ‎13.‎08.‎2014 12:46
An: "Dmitry Vyazelenko" <vyazelenko at yahoo.com>; "Bernd Eckenfels" <ecki at zusammenkunft.net>; "jmh-dev at openjdk.java.net" <jmh-dev at openjdk.java.net>
Betreff: Re: AW: Can't fork VM if option value contains space

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.