This bug report is the result of tracking down why Ant builds have been behaving incorrectly on Windows. This has been reported by a number of individuals. Since the Ant files work fine on other platforms, we looked at Runtime.exec on Windows, and believe that to be at fault.

Specifically, it would appear that Runtime.exec "loses" empty parameters.

The attached program is a simple test case/demo for the problem.  When you run the program with no args, it re-execs itself with a number of arguments, including an empty argument. The child process lists its arguments, which do not include the empty argument.

Here is the output from the program:

$ java -classpath build/classes Main
java version: 1.7.0-ea
[C:\Program Files\Java\jre1.7.0\bin\java, -classpath, build/classes, Main, a, b b, c, , d]
err: 0: a
err: 1: b b
err: 2: c
err: 3: d
child terminated: 0

Note that the input args include an empty string between c and d, and note that the child process reports c and d together, with no intervening blank.

I get similar output from JDK 1.5.0_12 and 1.6.0.

By contrast, here is the expected output, on Solaris

gzilla[langtools]% /tl/jdk/1.6.0/bin/java -cp ~/gzillapc/ExecTest/build/classes/ Main
java version: 1.6.0-rc
[/tl/jdk/jdk1.6.0/jre/bin/java, -classpath, /home/jjg/gzillapc/ExecTest/build/classes/, Main, a, b b, c, , d]
err: 0: a
err: 1: b b
err: 2: c
err: 3: 
err: 4: d
child terminated: 0

The problem is particularly serious and hard to work around when the empty parameter is the "value" of a preceding option. In the case we originally tracked down, we were trying to pass -sourcepath "" to javac, the "" was being lost, and so the argument decoding got out of whack.

[Thanks to Seetharama Prasad for originally identifying the -sourcepath "" problem].
It would appear that this is only for empty args (length 0).  Args containing just a space are OK.