Is *this* really the best way to start a second JVM from Java code?

Question

This is a followup to my own previous question and I'm kind of embarassed to ask this... But anyway: how would you start a second JVM from a standalone Java program in a system-independent way? And without relying on for instance an env variable like JAVA_HOME as that might point to a different JRE than the one that is currently running. I came up with the following code which actually works but feels just a little awkward:

public static void startSecondJVM() throws Exception {     String separator = System.getProperty("file.separator");     String classpath = System.getProperty("java.class.path");     String path = System.getProperty("java.home")                 + separator + "bin" + separator + "java";     ProcessBuilder processBuilder =                  new ProcessBuilder(path, "-cp",                  classpath,                  AnotherClassWithMainMethod.class.getName());     Process process = processBuilder.start();     process.waitFor(); } 

Also, the currently running JVM might have been started with some other parameters (-D, -X..., ...) that the second JVM would not know about.

Answer 1

I think that the answer is "Yes". This probably as good as you can do in Java using system independent code. But be aware that even this is only relatively system independent. For example, in some systems:

1. the JAVA_HOME variable may not have been set,
2. the command name used to launch a JVM might be different (e.g. if it is not a Sun JVM), or
3. the command line options might be different (e.g. if it is not a Sun JVM).

If I was aiming for maximum portability in launching a (second) JVM, I think I would do it using wrapper scripts.

Answer 2

It's not clear to me that you would always want to use exactly the same parameters, classpath or whatever (especially -X kind of stuff - for example, why would the child need the same heap settings as its parents) when starting a secondary process.

I would prefer to use an external configuration of some sort to define these properties for the children. It's a bit more work, but I think in the end you will need the flexibility.

To see the extent of possible configuration settings you might look at thye "Run Configurations" settings in Eclipse. Quite a few tabs worth of configuration there.