views:

1880

answers:

10

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.

+3  A: 

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 it yourself.

TofuBeer
+13  A: 

Two hints:

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

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

Then your EXECUTE.application is just (pseudocode):

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

stepancheg
third hint: don't use urls.join(":") if you want to be platform independent.
jdigital
File.some_constant instead of : (you can look up some_constant :-)
TofuBeer
http://java.sun.com/j2se/1.4.2/docs/api/java/io/File.html#pathSeparatorCha
Jean
+1  A: 
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;
    }
}
_ande_turner_
+1  A: 

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.

jasonnerothin
RMI will subsequently be involved, the processes act as Daemons for the main "Kernel" process, and there is some chance they may not be on the same computer but somewhere else on the network. I thought the original phrasing is useful to more readers though.
_ande_turner_
+4  A: 

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

lothar
+8  A: 

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) 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.getCanonicalName();

        ProcessBuilder builder = new ProcessBuilder(
                javaBin, "-cp", classpath, className);

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

}

You would run this method like so:

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

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.

hallidave
+1  A: 

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.

StaxMan
A: 

Hi

Thanks for suggestions; I need further clarification on below three points :

  1. How to start a RMI client application (server is already started )
  2. how do i pass arguments to the main
  3. I dis not see output console for the new process do you have any suggestions ?

Thanks in advance

This is more likely to be answered if you post it as a new question...
harto
+1  A: 

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 ).
Matiaan
A: 

Today I've reencountered some nasty bug that occured for me in another project some time ago (though the other project had issues like this when launching a game with some params). The following workaround may fix some unintuitive "ClassNotFoundException" you may encounter on some systems. For me it today occured in Ubuntu 10.04:

String classpath = System.getProperty("java.class.path");
if (classpath.contains(" ")) {
    //if using " without the need for it, on some systems the classpath may not be recognized correctly
    classpath = "\"" + classpath + "\"";
}
String command = "java -classpath  " + classpath + " " + classname + " " + options;
subes