Launching Java Subprocess using parent process Classpath

I want to launch a java subprocess, with the same java classpath and dynamically loaded classes as the current java process. The following is not enough, because it doesn't include any dynamically loaded classes:

String classpath = System.getProperty("java.class.path");

Currently I'm searching for each needed class with the code below. However, on some machines this fails for some classes/libs, the source variable is null. Is there a more reliable and simpler way to get the location of libs that are used by the current jvm process?

String stax     = ClassFinder.classPath("javax.xml.stream.Location");

public static String classPath(String qualifiedClassName) throws NotFoundException {
    try {
        Class qc = Class.forName( qualifiedClassName );
        CodeSource source = qc.getProtectionDomain().getCodeSource();
        if ( source != null ) {
            URL location = 开发者_C百科source.getLocation();        
            String f = location.getPath();
            f = URLDecoder.decode(f, "UTF-8"); // decode URL to avoid spaces being replaced by %20
            return f.substring(1);
        } else {
            throw new ClassFinder().new NotFoundException(qualifiedClassName+" (unknown source, likely rt.jar)");
        }
    } catch ( Exception e ) {
      throw new ClassFinder().new NotFoundException(qualifiedClassName);
    }
}

---

See my previous question which covers getting the classpath as well as how to launch a sub-process.

---

I want to launch a java subprocess, with the same java classpath and dynamically loaded classes as the current java process.

You mean invoke a new JVM?

Given that...

• it is possible to plug in all sorts of agents and instrumentation into a JVM that can transform classes at load time
• it is possible to take a byte array and turn it into a class
• it is possible to have complex class loader hierarchies with varying visibility between classes and have the same classes loaded multiple times

...there is no general, magic, catch-all and foolproof way to do this. You should design your application and its class loading mechanisms to achieve this goal. If you allow 3rd party plug-ins, you'll have to document how this works and how they have to register their libraries.

---

If you look at the javadoc for Class.getClassLoader, you'll see that the "bootstrap" classloader is typically represented as the null. "String.class.getClassLoader()" will return null on the normal sun jvm implementations. i think this implementation detail carries over into the CodeSource stuff. As such, I wouldn't imagine you would need to worry about any class which comes from the bootstrap classloader as long as your sub-process uses the same jvm impl as the current process.