JDK-4219634 : (process) Runtime.exec fails when trying to invoke another java vm
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 1.1.7
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: windows_nt
  • CPU: x86
  • Submitted: 1999-03-11
  • Updated: 1999-08-24
  • Resolved: 1999-08-24
Related Reports
Duplicate :  

Name: dbT83986			Date: 03/11/99

The problem that I am having is the inability for Java to spawn
another Java VM under Windows NT 4.0.  Included are two programs,
one called spawn, and one called child.  The spawn program attempts
to exec a process, and then output the stdout and stderr of the
child process.  The child merely prints out the java vm properties
as well as any command line arguments.

This program was tested with various child subprocesses (dir,
batch programs, etc), all of which worked, as expected.

A couple of additional notes:
1)  Java is in the path.  Therefore, bug #4026917 does not apply.
2)  A batch program which invokes the java child does work, but
    has the following limitations:
    - A new shell window is created
    - The output of the java process is not output by the batch
3)  I do not want to use a thread for the process because primarily
    because both processes (can)use a large amount of memory, and
    it is easier to kill a subprocess if it does not terminate than
    it is to kill a thread, and I do not want to kill the original
    program, because it causes undesired side-effects.

The spawn and child programs are listed below:
import java.io.*;
import java.util.*;

public class spawn {
  public spawn() {
    Runtime rt = Runtime.getRuntime();
    String command = "java child";
    String line;
    System.out.println("Executing "+command);
    try {
      Process p = rt.exec(command);
      BufferedReader in =
        new BufferedReader(new InputStreamReader(p.getInputStream()));
      BufferedReader err =
        new BufferedReader(new InputStreamReader(p.getErrorStream()));
      line = in.readLine();
      System.out.println("Subprocess output:");
      while (line != null) {
        line = in.readLine();
      line = err.readLine();
      System.out.println("Subprocess Errors:");
      while (line != null) {
        line = err.readLine();
    catch (Exception e) {

  public static void main(String argv[]) {
    spawn s = new spawn();

import java.io.*;
import java.util.*;

public class child {
  public static void main(String argv[]) {
    System.out.println("Number of arguments to child: "+argv.length);
    for (int i=0;i<argv.length;i++)
      System.out.println("Argument #"+(i+1)+":  "+argv[i]);
    System.out.println("JVM Properties:");

REVIEW NOTE 2/22/99 - User responded with additional information
It is definately still a concern, and a problem.  In my actual application, I do not 'waitFor' the spawned process to return.

Specifically, I have a process that gets a request from a servlet (via RMI) to 'spawn' another process to handle the request.
The 'spawned' program grabs a free port, and sends the host/port information back to the servlet.  The servlet then informs
the applet how to contact the 'spawned' application.  However, the spawned program does not return the host/port information
back to it's parent.

Is there a problem with I/O blocking on spawned processes in Windows?

Interestingly enough, exec'ing javac is NOT a problem on NT.  In that section of code, I exec javac, followed by a waitFor.  This succeeds...

Also, interestingly enough, on NT, I can see the other java process being spawned, but both processes seem to block (deadlock?).

Any help that you may be able to give regarding this matter would be greatly appreciated.
(Review ID: 48920)

WORK AROUND Name: dbT83986 Date: 03/11/99 There are no known workarounds that I know of. ======================================================================

EVALUATION This is part of spec problem, part of implementation problem. The JDK1.2 has largely fixed the problem. However, we don't have chance to backport the change to jdk1.1.x. The spec problem is difficult to solve. Please refer to Bug 4109888. ###@###.### 1999-08-24