JDK-4223650 : (process) Runtime.exec: Discrepency between resolutions of 4098442 & 4210128?
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.2.0
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_95
  • CPU: x86
  • Submitted: 1999-03-24
  • Updated: 1999-09-11
  • Resolved: 1999-09-11
Related Reports
Duplicate :  

Name: dbT83986			Date: 03/24/99

In bug 4098442 the team promised to fix the "bug" of process.waitfor()
not returning if the pipe is full. I have been waiting a very long
time for this bug fix. Now I read bug report 4210128 where it
is claimed that this "bug" is actually user error. Why did the story

 Here is a bit of code that will set off this bug.
I am still getting the process hanging if there is a lot of output. 
The following snippet runs fine if the output from dir is short.
It hangs if there is a lot of output.
 Reported against JDK 1.2 on Windows 95.

	String theCommandString="command.com /c dir"
      Process p = Runtime.getRuntime().exec(theCommandString, theEnvironment);
      System.out.println("Finished exec");
      InputStream dis = p.getInputStream();
      InputStream err=  p.getErrorStream();
      int c;

      String StdError="";
      String StdOut="";
      System.out.println("Begin waitfor");
      System.out.println("End waitfor()");

       while(dis.available()>0 && (c = dis.read()) != -1)

       while(err.available()>0 && (c = err.read()) != -1)

       int exitVal=p.exitValue();
       //Do clean up
(Review ID: 55810)

EVALUATION I maintain that the user must read from the process, and cannot expect it to terminate while there is unread output, thus this does not appear to be a bug. That does not preclude some examples from working on some platforms, as it depends on buffer sizes. I have assigned this bug report to the engineer who handled 4098442, who may offer a differing analysis. william.maddox@Eng 1999-03-31 We need redesign the Runtime.exec() in order to fix this kind of problem. See 4109888 for future improvement. ###@###.### 1999-09-10