Most of the issues raised are no long relevant or have been addressed:
1. Environment specifies the inheritance
2. Win16 is not supported
3. Limited buffering is a feature that prevents a source from continuing to produce data when it is not being consumed
4. Inheriting file descriptors is implementation specific and not part of the spec. (Most handles are not inherited).
5. Unix syntax and semantics are common and well understood on Unixes, Solaris, and MacOS X.
6. Command line parsing is operating system specific
7. System.exit(n) is defined to exit with the desired status; return from main is normal (0) exit status.
8. Only main programs are supported by the JRE
Any other issues should be raised as separate issues and dealt with individually.
This is all true. The JLS is no longer concerned with library issues like this,
but our libraries should address what (if any) concept of external process
can portably be supported.
This is a library issue, not runtime bug.
>1.When we create a process and don't give environment variables, will the
> child process inherit those of parent process? See bug 4064912
Further support for environment variables was added in 1.5.
I think it should be system-dependent what happens if null is passed as
the child environment.
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.
Supporting win16 programs is surprisingly difficult. Since win64
is droppping support for such programs, adding such support is becoming
less important. I worked on getting a fix into Tiger, but failed.
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
There is a jplan feature to do better io redirection.
This is very tricky. From perlipc(1)
Here's an example of using open2():
$pid = open2(*Reader, *Writer, "cat -u -n" );
print Writer "stuff\n";
$got = <Reader>;
The problem with this is that Unix buffering is really going
to ruin your day. Even though your "Writer" filehandle is
auto-flushed, and the process on the other end will get your
data in a timely manner, you can't usually do anything to
force it to give it back to you in a similarly quick
fashion. In this case, we could, because we gave cat a -u
flag to make it unbuffered. But very few Unix commands are
designed to operate over pipes, so this seldom works unless
you yourself wrote the program on the other end of the
I have some ideas for a less hostile interface for running processes
in synchronous mode, as many users want. It is hard to design well.
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.
To do system-specific things, you need to use a system-specific helper
program, such as start.exe or xterm.
###@###.### 2005-03-29 08:18:17 GMT