The semantics of external process is noy clearly defined in Java spec.
Many of the external process related bugs are caused by this problem.
Here is a couple of examples of how the semantic problem is:
1.When we create a process and don't give environment variables, will the
child process inherit those of parent process? See bug 4064912
2.When we create a process, the process will be detached from Java process.
But for win16 program, we can not run a 16-bit process in detached mode.
Because the 16 prog must run inside a 32-bit virtual machine process.
In detached mode, there is no such process to reside in. On win32, the
detached process is supposed to have its own console.
What shall we do? See bug 4079419.
3.By default, the child process's stdout and stderr are redirected to parent
process. If parent process does not read the pipe, the child process will
block when pipe is full. See bug 4062587
4.When we create a child process, will the child process inherits the file
handles or other system resources from parent. See bug 4093815
5.The current implementation of process code assume unix syntax and semantics.
Which will be almost impossible on mac, where there is not concept of
stdio, console etc.
6.On unix, it is shell(the parent process) do the command line parsing. On
win32, the parsing is done by both parent process and child process CRT.
See bug 4064116
7.How should we handle(atually define) the virtual machine process? If we
run a Java program, the Java main() does not return anything. The exitcode
is the vm exit code. Will that be good enough?
8.How should we handle program does not use main() function, like native
windows app. The win32 let parent process to specify the window size,
location, maybe minimized or maximized. But the current syntax prevent
user from having full control of its child process.
The bottom line is the process is an external concept to Java. How should we
address the semantic difference? The current implementation uses the unix semantics, but it brreaks in many different ways.