views:

10165

answers:

4

Hi,

I was asked to build a java system that will have the ability to load new code (expantions) while running. How do I re-load a jar file while my code is running? or how do I load a new jar?

Obviously, since constant up-time is important, I'd like to add the ability to re-load existing classes while at it (if it does not complicate things too much). What are the things I should look out for? (think of it as two different questions - one regarding reloading classes at runtime, the other regarding adding new classes).

+1  A: 

ok, got off my ass and googled a bit. found this code here:

File file = getJarFileToLoadFrom();   
String lcStr = getNameOfClassToLoad();   
URL jarfile = new URL("jar", "","file:" + file.getAbsolutePath()+"!/");    
URLClassLoader cl = URLClassLoader.newInstance(new URL[] {jarfile });   
Class loadedClass = cl.loadClass(lcStr);

anyone can share opinions/comments/answers regarding this approach?

Amir Arad
The jar URL is for pointing at a resource with a jar file. You want to pass the whole jar file over to URLClassLoader. (Unfortunately jars within jars is broken.)
Tom Hawtin - tackline
+9  A: 

Reloading existing classes with existing data is likely to break things.

You can load new code into new class loaders relatively easily:

ClassLoader loader = URLClassLoader.newInstance(
    new URL[] { yourURL },
    getClass().getClassLoader()
);
Class<?> clazz = Class.forName("mypackage.MyClass", true, loader);
Class<? extends Runnable> runClass = clazz.asSubclass(Runnable.class);
// Avoid Class.newInstance, for it is evil.
Constructor<? extends Runnable> ctor = runClass.getConstructor();
Runnable doRun = ctor.newInstance();
doRun.run();

Class loaders no longer used can be garbage collected (unless there is a memory leak, as is often the case with using ThreadLocal, JDBC drivers, java.beans, etc).

If you want to keep the object data, then I suggest a persistence mechanism such as Serialisation, or whatever you are used to.

Of course debugging systems can do fancier things, but are more hacky and less reliable.

It is possible to add new classes into a class loader. For instance, using URLClassLoader.addURL. However, if a class fails to load (because, say, you haven't added it), then it will never load in that class loader instance.

Tom Hawtin - tackline
if my initial classloader loaded stuff like threadpools and other resources, does it not mean that the new classes loaded by the second classloader will not be accessible to those resources?
Amir Arad
I've not specified a parent for the URLClassLoader so it'll just use system (I'll fix). That will mean it'll still be able to access classes on the classpath. If you want to share stuff, pass references around using types defined in common class loaders (perhaps the boot class loader for Java lib).
Tom Hawtin - tackline
I'm missing something: why is Class.newInstance() "evil"?
Ryan Delucchi
Ryan, I posted this as a new question - see: http://stackoverflow.com/questions/195321/why-is-classnewinstance-evil
Amir Arad
+1  A: 

I was asked to build a java system that will have the ability to load new code while running

You might want to base your system on OSGi (or at least take a lot at it), which was made for exactly this situation.

Messing with classloaders is really tricky business, mostly because of how class visibility works, and you do not want to run into hard-to-debug problems later on. For example, Class.forName(), which is widely used in many libraries does not work too well on a fragmented classloader space.

Thilo
+1  A: 

Try this. it works for me.

File file = new File("c:\myjar.jar"); URL url = file.toURL();
URL[] urls = new URL[]{url}; ClassLoader cl = new URLClassLoader(urls);

Class cls = cl.loadClass("com.mypackage.myclass");