-
Bug
-
Resolution: Won't Fix
-
P4
-
None
-
1.2a, 1.0.2, 1.1.3, 1.1.4, 1.1.5, 1.1.6, 1.1.7, 1.1.8, 1.2.0, 1.2.2, 1.3.0, 1.4.0, 6
-
generic, x86, sparc
-
generic, solaris_2.5.1, solaris_2.6, solaris_7, solaris_8, windows_95, windows_98, windows_nt, windows_2000, windows_xp
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.
- duplicates
-
JDK-4188007 Difference between 1.1 and 1.2 in calling Runtime.exec from javaw.exe
- Closed
-
JDK-4064912 Empty environment array for Runtime.exec does not yield an empty environment.
- Closed
-
JDK-4255453 win95 Runtime.exec() backslash quoting requirements are inconsistent with 98/NT
- Closed
-
JDK-4262372 Spaces in command-line parameters removed by Runtime.exec
- Closed
-
JDK-4131867 javadoc for Runtime.exec missing IOException
- Closed
-
JDK-4211683 (process) Runtime DOS console windows do not handle Win95 IO properly
- Closed
-
JDK-4216988 (process) JVM 1.2 hangs when executing external
- Closed
-
JDK-4219634 (process) Runtime.exec fails when trying to invoke another java vm
- Closed
-
JDK-4223650 (process) Runtime.exec: Discrepency between resolutions of 4098442 & 4210128?
- Closed
-
JDK-4247999 Runtime.exec(net.exe) creates undesirable DOS prompt
- Closed
-
JDK-4365120 Runtime.exec(String) does not parse quotes correctly
- Closed
-
JDK-4081777 (process) RFE: Would like to be able to set CWD for Runtime.exec'd() command
- Closed
-
JDK-4486892 (process) RFE: Please add full support for creating new processes
- Closed
-
JDK-4505263 RFE: Runtime.exec() with flag, whether calling process inherits handles
- Closed
- relates to
-
JDK-4064116 Runtime.exec(String[]) collapses white spaces on Win32
- Closed
-
JDK-4079419 Runtime.exec() ACCESS_DENIED with 16-bit application
- Closed
-
JDK-4324996 (process) Runtime.exit and Runtime.halt assume process model
- Closed
-
JDK-4062587 exec Processes failing with long output.
- Closed
-
JDK-4093815 Runtime.exec() leaks pipe to child process
- Closed