Runtime.getRuntime().exec( "myprog.exe" );

It is also best to fully qualify executable names so that the system executable search path is irrelevant, and so you don’t pick up some stray program off the path with the same name.

Overloaded exec

Command Interpreter

Simplifications

Launching A Browser

Runtime.getRuntime().exec( "cmd.exe http://mindprod.com/index.html" );

// spawning Firefox on the Mac
Runtime.getRuntime().exec( new String[] {
                              "open",
                              "-a",
                              "Firefox.app",
                              url.toString()
                           });

Note that

rundll32.exe url.dll,FileProtocolHandler file:///E|/mindprod/jgloss.html

Andrew Thompson  has a written a browser launching class that determines the default browser.

Unix

1. Start the script with #!bash or whatever the interpreter’s name is.
2. Mark the script file itself with the executable attribute.

Runtime.getRuntime().exec( new String[]{ "/bin/sh", "-c", "echo $SHELL"} );

Communicating With The Spawned Process

1. Spawn the child (and continue processing).
2. Write the child’s input from System.in with Process.getOutputStream(). Note the stream is named relative to the parent, not the child.
3. Read the child’s output from System.out with Process.getInputStream(). Note the stream is named relative to the parent, not the child. You must do this if there are more that a few line of output, or the child will stall, constipated with unread output.
4. Read the child’s output from System. err with Process.getErrorStream().
5. One each to read the child’s output from files, sockets etc.
6. Wait for the child with Process.waitFor() once you have all the hooks set up.
7. Timer to kill the child, and interrupt the waitFor() thread with Thread.interrupt() if the child takes too long.

Process.getOutputStream lets you write out data that will be used as input to the process. Don’t forget to include any "\n" and "\r" characters the process is expecting. Process.getInputStream lets you read in the data that your process squirted out to stdout.

The other cruder way to get the output from the execed program is to spawn a command processor and use the > or 2> redirection operator to direct stdout or stderr to a file. When the spawned program completes, read the file.

If you wait for the Process, you might want to do it on some thread other than the main AWT event processing one, i.e. create a new Thread, otherwise your app will not be able to process AWT events while you wait.

ON the Java side you may need to read and write to the child with separate threads to avoid deadlocks. The deadlock occurs if you try to read and/or write more than a certain amount (empirically it is around 4k). The deadlock (a Mexican standoff freeze) happens when the child wants you to listen when you are still trying to feed it more, or when the child is hungry for input and you won’t send it any more until it has spoken.

Applets

If you are in an Applet and all you are trying to is get a browser to render a page, you don’t need exec. Simply use getAppletContext().showDocument( new URL("http://domain/file.html"));

Gotchas

• If your child program produces more than a few lines of output, your parent program must capture and process it, otherwise the child will stall with constipation.
• If you are used to C exec, watch out. Java does not use the dummy parameter 0 which duplicates the name of the program.
• In a similar way, Java main methods don’t see that dummy parameter either.
• Your execed program will stall if it produces more than a few lines out output. You have to make provision via the Process object for the parent program to read the child’s System. out and System.err output if the child produces more than a few lines.
• You must use the .exe suffix. exec is not smart enough to figure out the extension. A command interpreter can however figure out if you meant .bat, .com or .exe, however. Spawn a command interpreter instead, with the program name as a parameter. See the example code above.
• For internal command interpreter commands like dir and del, you must spawn a command interpreter with the command as a parameter. You can’t spawn the command directly.

ProcessBuilder

• It lets you control the environment.
• There are separate methods for setting up the various aspects of the spawn, rather than confusing positional parameters.
• It will merge the child stderr and stdout streams for you.

Threads to Tend the Child

Spawning java.exe

• The easiest way to spawn some other program is just to invoke its static main method:

  // How to start up some other Java program whole name you
  // know at compile time.
  // Just call its main method.
  // It will run in the same JVM and return when it is done.
  
  import com.othersite.otherpackage.OtherProgram;
  ...
  OtherProgram.main( new String[] { "first", "second" } );

• When you don’t know the name of the class you want to exec at compile time, you need to resort to Class. forName dynamic class loading.
• If that does not provide sufficient flexibility, you will need to use reflection, which is ugly, slow and complicated.
• If you want a separate JVM running independently, use ProcessBuilder the same as you would any external app.
  See java.exe for more details on the command line options.

Spawning javac.exe

Desktop Spawning

• Desktop.open will launch the appropriate application to handle the given file.
• Desktop.browse will launch a browser and display a URL.
• Desktop.edit will launch as appropriate editor of some sort on the given file.
• Desktop.mail will launch the user’s favourite mail program.
• Desktop.print will launch the appropriate application to print the given file.

Learning More