aspose file tools*
The moose likes Java in General and the fly likes Current ClassLoader Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Java in General
Bookmark "Current ClassLoader" Watch "Current ClassLoader" New topic
Author

Current ClassLoader

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I don't see any way to change the "current classloader" that is used by the "new" operator. Anybody know if we can do this?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24184
    
  34

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.)


[Jess in Action][AskingGoodQuestions]
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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 ]
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Current ClassLoader