JDK-4109888 : (process spec) Semantics of external process is not defined in JLS
  • Type: Bug
  • Status: Resolved
  • Resolution: Won't Fix
  • Component: core-libs
  • Sub-Component: java.lang
  • Priority: P4
  • Affected Version:
    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 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
  • OS:
    generic,solaris_2.5.1,solaris_2.6,solaris_7,solaris_8,windows_95,windows_98,windows_nt,windows_2000,windows_xp generic,solaris_2.5.1,solaris_2.6,solaris_7,solaris_8,windows_95,windows_98,windows_nt,windows_2000,windows_xp
  • CPU: generic,x86,sparc
  • Submit Date: 1998-02-05
  • Updated Date: 2017-07-18
  • Resolved Date: 2017-07-18
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
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.

Comments
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.
2017-07-18

Roger - should be close this?
2017-07-18

EVALUATION 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. gilad.bracha@eng 2000-02-02 This is a library issue, not runtime bug. ###@###.### 2000-06-29 >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(): use FileHandle; use IPC::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 double-ended pipe. 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
2005-03-29

WORK AROUND Since the spec does not give the semantic definition about the java.lang.Process, adding some additional javadoc in Process.java will help user with using the Process API. It should not affect the current spec. ###@###.### 1998-02-13
1998-02-13