How can I start a second Java process?

Question

How can I start a second Java process platform independent? Ideally it should be the same Java version that currently running. Are there any helpful system properties?

Answer 1

You can use java.home system property to find the current JVM:

String jvm = new java.io.File(new java.io.File(System.getProperty("java.home"),
                                               "bin"),
                              "java").getAbsolutePath();

and then run it using ProcessBuilder (or Runtime.exec).

Note that for JDK java.home points to the JRE directory included in JDK.

Answer 2

It is not possible, in general.

The recipe provided in @khachik's answer will not necessarily work for a non Sun implementation of Java.

• The java executable is not necessarily called java and doesn't necessarily live in the bin subdirectory. Even with Sun Java, on Windows there are two executables; java and javaw.

• The command options for the command that starts a JVM are different for different Java implementations. So the ProcessBuilder step may involve non-portable arguments.

---

While most JVMs have adopted the primary Sun java command options, there are numerous differences. For example:

• IBM J9 uses j9 and j9w as the executable names.
• BEA / Oracle JRockit has different -X and -XX options.
• Jikes RVM uses rvm as the executable name, and only supports a subset of Sun's java options.
• IKVM uses ikvm as the executable name.

(Note: these are just examples that stand out in a cursory reading of the respective online documentation.)

Answer 3

Have you tried using the Apache Commons libs? If you haven't give the launcher project a try. It was quite useful for me some time ago.

Here's the project description from their site:

The Launcher Component is designed to be a cross platform Java application launcher.

The original Java classes come from the Tomcat 4.0 project.

Commons-launcher eliminates the need for a batch or shell script to launch a Java class. Some situations where elimination of a batch or shell script may be desirable are:

• You want to avoid having to determining where certain application paths are e.g. your application's home directory, etc. Determining this dynamically in a Windows batch scripts is very tricky on some versions of Windows or when softlinks are used on Unix platforms.
• You want to avoid having to handle native file and path separators or native path quoting issues.
• You need to enforce certain system properties e.g. java.endorsed.dirs when running with JDK 1.4.
• You want to allow users to pass in custom JVM arguments or system properties without having to parse and reorder arguments in your script. This can be tricky and/or messy in batch and shell scripts. You want to bootstrap system properties from a configuration file instead hard-coding them in your batch and shell scripts.
• You want to provide localized error messages which is very tricky to do in batch and shell scripts.