JDK-6518827 : (process) zero length Process arguments ignored on win32
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 2.0,6,6u24
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: generic,solaris_1,windows_7
  • CPU: generic,x86,sparc
  • Submitted: 2007-01-29
  • Updated: 2021-11-22
  • Resolved: 2021-11-22
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Description
For win32, it appears that java.lang.ProcessImpl is not performing quotation correctly for an argument of length zero. This affects the <java> target in ant when empty command line arguments are passed in. I have attached a short sample test that is runnable from ant. It calls a simple Java class and passes in some arguments. On unix, both tests pass, but on windows, it fails:

** fork=false **
Pass:
argument 0: "argument0"
argument 1: ""
argument 2: "argument2"

** fork=true **
Fail. Only received 2 args:
argument 0: "argument0"
argument 1: "argument2"

I don't think this is an ant issue, as it does not appear that ant converts all the arguments into a single string (as it would be on a command line).
Adding Kohsuke to the interest list since he did the detective work to narrow down the issue.

Comments
Here is the suggested fix: http://cr.openjdk.java.net/~uta/openjdk-webrevs/JDK-6518827/webrev.00/ Summary: Here we close the long-standing problem of the lost empty argument. Due to significant impact for legacy applications, the functionality is not active by default and needs the presence of the Security Manager, or defined in "false" the system property "jdk.lang.Process.allowAmbiguousCommands" Currently the property has the "true" value by default. We need to declare, that the property could change the default value in the next major release. Please, read 7u21, 7u25, 7u40 release notes for details. By introducing the dependence from property value we are stimulating developer for more accurate approach for argument transfer and minimizing the regression risk. New feature has the test coverage.
08-08-2013

EVALUATION See 6468220: (process) Runtime.exec(String[]) does not pass command line arguments correctly (win) As I wrote in the evaluation for that CR, We cannot change the implementation, but we should document the behavior and workaround in a place more obvious than this CR, but there is no such obvious document currently. We need a Platform Guide! At least I can document the way to use the API on Windows here: Here is a way to quote arguments to the windows process API: static boolean needsQuoting(String s) { int len = s.length(); if (len == 0) // empty string have to be quoted return true; for (int i = 0; i < len; i++) { switch (s.charAt(i)) { case ' ': case '\t': case '\\': case '"': return true; } } return false; } static String winQuote(String s) { if (! needsQuoting(s)) return s; s = s.replaceAll("([\\\\]*)\"", "$1$1\\\\\""); s = s.replaceAll("([\\\\]*)\\z", "$1$1"); return "\"" + s + "\""; }
30-01-2007

EVALUATION It's possible that there's a problem here, but I can't I see how ant is invoking Runtime.exec() (which would use ProcessImpl). If I run the provided Test.java in the obvious way, I can't reproduce the problem on windows. Please provide a reproducible test case which does not depend ant.
29-01-2007

WORK AROUND Do not rely on empty params, but define a string to represent the param. Or, alter String[] checking in main() to account for possibly missing arguments.
29-01-2007