United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4109888 : (process spec) Semantics of external process is not defined in JLS

Details
Type:
Bug
Submit Date:
1998-02-05
Status:
Open
Updated Date:
2012-09-19
Project Name:
JDK
Resolved Date:
Component:
core-libs
OS:
solaris_8,solaris_2.6,windows_nt,solaris_7,solaris_2.5.1,generic,windows_98,windows_xp,windows_95,windows_2000
Sub-Component:
java.lang
CPU:
x86,sparc,generic
Priority:
P4
Resolution:
Unresolved
Affected Versions:
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
Targeted Versions:

Related Reports
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Duplicate:
Relates:
Relates:
Relates:
Relates:
Relates:

Sub Tasks

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
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



Hardware and Software, Engineered to Work Together