This page contains an archived post to the Design Forum (formerly called the Flexible Java Forum) made prior to February 25, 2002. If you wish to participate in discussions, please visit the new Artima Forums.

Message:

Actually the technique does work

Posted by Bill Venners on March 06, 2000 at 8:47 PM

> In the article, the class loader first loads using findLoadedClass() which always uses the system class loader. Fact is it never reaches the getClassFromHole () method in RodentClassLoader.loadClass ().
>
> In order to make live updates, we need to be able to "reload" an existing class file on disk that has changed. Since the RodentClassLoader NEVER actually load from the "hole", it always gets the cached class in the default system loader.

> In any case, by looking at the package name for custom loading, I modified the class loader to look at the "hole" first, and if the class couldn't be loaded (java.lang.Object for instance) use findLoadedClass (). This worked fine except that the cast from Mouse to Rodent now throws a ClassCastException.

> Remember, to have live updates, we need to load from the "hole" every single time using our custom class loader, and we would do it by creating a new instance of the loader every time. This does work correctly, but its unusable

> Also remember, the article's implementation of RodentClassLoader is "flawed" for what I am trying to do since it always used findLoadedClass() which uses the system class loader. This is cheating!

> I am pasting the code below. If anyone can come up with a RodentClassLoader to make the rest of the code work I would appreciate it. I must say, this code worked fine in JDK 1.1.
>
I expect your problem is that some Mouse class is available on
the class path. If a Mouse is available on the class path, it
will be loaded by the system loader, which always gets a chance
to load a class before the custom loader attempts to load it
from hole.

bv