My guess (based on the comments I found in code grep) is that the issue is with the fact you have to handle the streams of the process and that this handling might be an issue.
The methods that create processes may not work well for special
processes on certain native platforms, such as native windowing
processes, daemon processes, Win16/DOS processes on Microsoft Windows,
or shell scripts. The created subprocess does not have its own
terminal or console. All its standard I/O (i.e. stdin, stdout, stderr)
operations will be redirected to the parent process through three
streams (getOutputStream(), getInputStream(), getErrorStream()). The
parent process uses these streams to feed input to and get output from
the subprocess. Because some native platforms only provide limited
buffer size for standard input and output streams, failure to promptly
write the input stream or read the output stream of the subprocess may
cause the subprocess to block, and even deadlock.
It may also be related to the fact that Process
is an abstract class and every JRE/JDK carries with it it's own platform dependent process implementation (e.g. UNIXProcess
, WindowsProcess
etc.) Some operating systems might simply have limitations related to opening processes which Java cannot cover in its documentation.
Again - this is just a guess, the code does't reveal much.
From my experience (both on *nix systems and windows) - your code needs to be platform aware most of the time in how you construct your command line, how you provide arguments (either in the arguments
parameter or in the command line) and how you build the environment of the spawned process (inherit your process's values or create on of your own). It is more a game of trial and error in any case.