You'd need to push the work off into another class, and load that other class with the special loader:
Since you wrote such marvelous pseudocode, I can too, right?
The class loader that is used to load class A is also used to resolve all class names B that appear in A's class file. There's no way to influence this; if you could, bad things would happen. For example, you could have a member variable of type A, and manage to execute code that tries to assign an instance of A' (the same class file, loaded by a different class loader.)
Ok, that looks like a good thing, but much too simple for me to have come up with. Actually I googled like mad to find out if what you said was true - the loader that loads WidgetTwiddler will also load anything WidgetTwiddler creates via new - and couldn't find that spelled out clearly.
I was pondering how app server containers work to reload code ... I'm picturing a container shell that has the classloader and one reference to one anchor object in a subsystem. The rest of the subsystem is not referenced by the shell or any other subsystem and is all loaded by the same loader. So if the shell nulls that one reference it can make a new classloader and load the whole subsystem up from scratch. The old loader and old copy of the subsystem are all eligible for gc. It doesn't have to have exactly "one" reference to subsystem objects, but must null them all out.
BTW: In WebSphere I have run into the problem that if the subsystem uses Class.forName() it must also explicitly use the loader that loaded it. I think you hinted at the reason ... I'll read that a couple more times to see.
Joined: Jan 29, 2003
Sure enough, this works perfectly to run "APP" even though it is not on the classpath for this program ...
I might go so far as to put this in a loop and change some OOChart classes between iterations to demonstrate they're being picked up. [ May 14, 2007: Message edited by: Stan James ]