URLClassLoader loading class from jarB, which uses classes from jarC

Question

Hi, here's my problem:
I have a classA in executable jarA.
This uses URLClassLoader to load classB from jarB. So far so good.
But classB uses classC, which lives in jarC. jarC is specified in the Class-Path of the manifest in jarB. But classB gets a ClassNotFound exception when it tries to use classC.
The situation I want to achieve looks like this (sorry for the bad art; it's almost impossible to make it look better because sun strips out extra spaces):
jarA:
classA-----> URLClassLoader(jarB).loadClass(classB)
jarB:
Class-Path jarC
classB------> new classC
jarC:
classC
My expectation was that URLClassLoader would automatically be used to load all the classes that classB uses, and that it would extend its classpath by the classpath specified in the manifest of jarB, just like the default classloader does. Anyone know what I'm doing wrong?
When I do the following, i.e. use only the default classloader, everything works fine. Unfortunately I won't know where jarB is until runtime, so I can't actually do this:
jarA:
Class-Path jarC
classA-----> new classB
jarB:
Class-Path jarC
classB------> new classC
jarC:
classC
thanks alot
j

Answer 1

Actually, there is definitely a way to make this work. A plugin engine has to handle this in order for plugins loaded by separate loaders to be able to share class instances with one another (dependency). My engine does static runtime plugin dependency resolution, which means it parsers every plugin's config file, then after all plugins are in the "registry" it goes back and resolves all dependencies. How it does this is that each PluginClassLoader keeps a list of "dependent" classloaders. So, if the engine finds plugin A, B, and C, and B depends on C (declares this in its config file), the engine creates 3 class loaders (custom loader called PluginClassLoader), one for each plugin. This is done so that the plugin can be unloaded or reloaded at runtime without having to shut the application down. Now, since B depends on C, when plugin B code requests a class found in C, the JVM first asks B's loader to find the class. The "normal" delegation model of Java is for B's loader to first look in the parent hierarchy, then in its own classpath. The problem with this approach is that in order to support reloadable and unloadable plugins, you do NOT want your plugin .jar file at any location within the main application classpath. The plugin .jar file should be able to be at any URL location outside of any other classpath, even perhaps at another web site.
So, the JVM asks B to find the class in C. But B's loader isn't able to find it because it is not in B's classpath. The trick is to do one of a couple things. First, remember that each loader keeps a list of dependent loaders. Second, in order to avoid any tie-in to the main classpath, we break the normal classloader delegation model by overriding the loadClass() method. In here we want to first check our local cache of loaded classes. The built-in method findLoadedClass() handles this for us. If that doesn't return a Class, then we want to look in our own classpath. In this case, we only want to look for any classes in B's plugin .jar file. C's class of course wont be found here. So the next step is to delegate to our "dependent" list of loaders. Aha, you say? This is the trick (credit goes to the Eclipse IDE team where a few members taught me this and was able to help me solve my very same problem). By delegating to a dependent loader, B's loader effectively asks C's loader to find C's class. The same thing happens, only this time it is now C's loader doing the work. The very first time the calls is made, no classes are loaded yet, so the finding of the C class in the local cache of C's loader wont yet work. The next step though, looking in C's classpath (C's .jar file) WILL find the class. It is loaded, put in C's loader cache and the Class is returned. Now, at this point B now has a Class from C's classpath that it can use.
Now, my first foray into this made me think that if B asks C to find it, and C finds it and loads the bytecode, doesn't B's loader also need the bytecode in order to properly "see" the C class. Apparently, this is not needed. I am guessing the JVM keeps a repository of bytecode, so that so long as you have the C ref (location in the JVM's memory where C's bytecode is), you don't need to re-load the bytecode of C into B's loader. Thus, B's loader now can "see" the C class without actually having to have loaded the bytecode of C. Now, B's code can typecast C, use it, etc. Beautiful aint it?
Let me know if you have any further questions.