Executing a Java application in a separate process

Question

Can a Java application be loaded in a separate process using its name, as opposed to its location, in a platform independent manner?

I know you can execute a program via ...

Process process = Runtime.getRuntime().exec( COMMAND );

... the main issue of this method is that such calls are then platform specific.

Ideally, I'd wrap a method into something as simple as...

EXECUTE.application( CLASS_TO_BE_EXECUTED );

... and pass in the fully qualified name of an application class as CLASS_TO_BE_EXECUTED.

Answer 1

This is a synthesis of some of the other answers that have been provided. The Java system properties provide enough information to come up with the path to the java command and the classpath in what, I think, is a platform independent way.

public final class JavaProcess {

    private JavaProcess() {}        

    public static int exec(Class klass, List<String> args) throws IOException,
                                               InterruptedException {
        String javaHome = System.getProperty("java.home");
        String javaBin = javaHome +
                File.separator + "bin" +
                File.separator + "java";
        String classpath = System.getProperty("java.class.path");
        String className = klass.getName();

        List<String> command = new LinkedList<String>();
        command.add(javaBin);
        command.add("-cp");
        command.add(classpath);
        command.add(className);
        if (args != null) {
            command.addAll(args);
        }

        ProcessBuilder builder = new ProcessBuilder(command);

        Process process = builder.inheritIO().start();
        process.waitFor();
        return process.exitValue();
    }

}

You would run this method like so:

int status = JavaProcess.exec(MyClass.class, args);

I thought it made sense to pass in the actual class rather than the String representation of the name since the class has to be in the classpath anyways for this to work.

Answer 2

Two hints:

System.getProperty("java.home") + "/bin/java" gives you a path to the java executable.

((URLClassLoader) Thread.currentThread().getContextClassLoader()).getURL() helps you to reconstruct the classpath of current application.

Then your EXECUTE.application is just (pseudocode):

Process.exec(javaExecutable, "-classpath", urls.join(":"), CLASS_TO_BE_EXECUTED)

Answer 3

Expanding on @stepancheg's answer the actual code would look like so (in the form of a test).

import org.junit.Test;

import java.io.File;
import java.net.URL;
import java.net.URLClassLoader;
import java.util.Arrays;
import java.util.stream.Collectors;

public class SpinningUpAJvmTest {
    @Test
    public void shouldRunAJvm() throws Exception {
        String classpath = Arrays.stream(((URLClassLoader) Thread.currentThread().getContextClassLoader()).getURLs())
                .map(URL::getFile)
                .collect(Collectors.joining(File.pathSeparator));
        Process process = new ProcessBuilder(
                System.getProperty("java.home") + "/bin/java",
                "-classpath",
                classpath,
                MyMainClass.class.getName()
                // main class arguments go here
        )
                .inheritIO()
                .start();
        int exitCode = process.waitFor();
        System.out.println("process stopped with exitCode " + exitCode);
    }
}

Answer 4

This might be an overkill for you, but Project Akuma does what you want and more. I found it via this entry at Kohsuke's (one of Sun's rock start programmers) fabulously useful blog.

Answer 5

public abstract class EXECUTE {

    private EXECUTE() { /* Procedural Abstract */ }

    public static Process application( final String CLASS_TO_BE_EXECUTED ) {

        final String EXEC_ARGUMENT 
        = new StringBuilder().
              append( java.lang.System.getProperty( "java.home" ) ).
              append( java.io.File.separator ).
              append( "bin" ).
              append( java.io.File.separator ).
              append( "java" ).
              append( " " ).
              append( new java.io.File( "." ).getAbsolutePath() ).
              append( java.io.File.separator ).
              append( CLASS_TO_BE_EXECUTED ).
              toString();

        try {       

            return Runtime.getRuntime().exec( EXEC_ARGUMENT );

        } catch ( final Exception EXCEPTION ) {     

            System.err.println( EXCEPTION.getStackTrace() );
        }

        return null;
    }
}

Answer 6

Did you check out the ProcessBuilder API? It's available since 1.5

http://java.sun.com/javase/6/docs/api/java/lang/ProcessBuilder.html

Answer 7

Do you really have to launch them natively? Could you just call their "main" methods directly? The only special thing about main is that the VM launcher calls it, nothing stops you from calling main yourself.

Answer 8

Following on what TofuBeer had to say: Are you sure you really need to fork off another JVM? The JVM has really good support for concurrency these days, so you can get a lot of functionality for relatively cheap by just spinning off a new Thread or two (that may or may not require calling into Foo#main(String[])). Check out java.util.concurrent for more info.

If you decide to fork, you set yourself up for a bit of complexity related to finding required resources. That is, if your app is changing frequently and depends upon a bunch of jar files, you'll need to keep track of them all so that they can be passed out to the classpath arg. Additionally, such an approach requires to to infer both the location of the (currently executing) JVM (which may not be accurate) and the location of the current classpath (which is even less likely to be accurate, depending upon the way that the spawning Thread has been invoked - jar, jnlp, exploded .classes dir, some container, etc.).

On the other hand, linking into static #main methods has its pitfalls as well. static modifiers have a nasty tendency of leaking into other code and are generally frowned upon by design-minded folks.

Answer 9

A problem that occurs when you run this from a java GUI is it runs in the background. So you cannot see the command prompt at all.

To get around this, you have to run the java.exe through "cmd.exe" AND "start". I dont know why, but if you put "cmd /c start" infront it shows the command prompt as it runs.

However, the problem with "start" is that if there is a space in the path to the application (which the path to the java exe usually have as it is in C:\Program Files\Java\jre6\bin\java.exe or similar), then start just fails with "cannot find c:\Program"

So you have to put quotes around C:\Program Files\Java\jre6\bin\java.exe Now start complains about parameters that you pass to java.exe: "The system cannot find the file -cp."

Escaping the space in "Program Files" with a backslash also does not work. So the idea is to not use space. Generate a temporary file with the bat extension and then put your command with spaces in there and run the bat. However, running a bat through start, does not exit when done, so you have to put "exit" at the end of the batch file.

This still seems yucky.

So, looking for alternatives, I have found that using quote space quote in the space of "Program Files" actually works with start.

In the EXECUTE class above change the string builder appends to:

append( "cmd /C start \"Some title\" " ).
append( java.lang.System.getProperty( "java.home" ).replaceAll(" ", "\" \"") ).
append( java.io.File.separator ).
append( "bin" ).
append( java.io.File.separator ).
append( "java" ).
append( " " ).
append( new java.io.File( "." ).getAbsolutePath() ).
append( java.io.File.separator ).
append( CLASS_TO_BE_EXECUTED ).