2

I have an application that needs the ability to update parts of itself (one class at a time) without stopping and restarting. With the JavaCompiler API, it is straightforward to generate modified class source code, recompile, load, and instantiate a class. I can do this all in memory (no files read from disk or net).

The application will never instantiate more than one object of such a class. There will only be two or three references to that object. When the modified class is loaded and instantiated, all those references will be changed to the new object. I can also probably guarantee that no method in the affected class is running in another thread while loading the modified class.

My question is this: will my class loader have problems loading a modified class with the same name as a class it previously loaded?

If I do not explicitly implement a cache of loaded classes in the class loader, would that avoid problems? Or could delegation to a parent class loader still cause a problem?

I hope to use a single instance of my class loader, but if necessary, I could instantiate a new one each time I update a class.

Note: I looked at OSGI and it seems to be quite a bit more than I need.

skaffman
  • 398,947
  • 96
  • 818
  • 769
user1198411
  • 139
  • 10
  • I have something very similar to this. You will have to specify to use JDK in order to compile it, or else you will get errors with the JavaCompiler returning null. –  Feb 15 '12 at 17:42

2 Answers2

1

There's a useful example on this at http://tutorials.jenkov.com/java-reflection/dynamic-class-loading-reloading.html

We do quite a bit of dynamic class reloading ourselves (using Groovy for compilations). Note if you've got class dependencies then you may need recompile these dependencies on reload. In dev stacks we keep a track of these dependencies and then recompile whenever dependencies become stale. In production stacks we opted for a non-reloading ClassLoader and create a new ClassLoader when ever anything changes. So you can do it either way.

BTW - you might find the GroovyScriptEngine at http://grepcode.com/file/repo1.maven.org/maven2/org.codehaus.groovy/groovy-all/1.8.5/groovy/util/GroovyScriptEngine.java#GroovyScriptEngine very interesting if you want to dig around how they do it.

ian
  • 89
  • 5
0

Okay, it should work: when you load the new class, it will replace the class name in the appropriate tables, and the memory should be GC'd. That said, I'd give it a strenuous test with a real short program that compiles a nontrivial class and replaces it, say 10,000 times.

Charlie Martin
  • 110,348
  • 25
  • 193
  • 263