Override class at runtime
Is it possible to have a class implementation overrun at runtime?
For instance, if I have a method:
publicvoid myMethod(){
Person p =new Person("foo");
System.out.println(p.toString());
}
and the Person class at compile time's toString() method returns "I'm a person", but the one provided at runtime returns "different person", how can I have it so when I call myMethod, the person instantiated is the one given at runtime?
Is there someway I can do this with a class loader? I've tried fooling around with URLClassLoader to do it, but it always gives me back the original.
Basically, somebody will be submitting a new Person class during runtime, and I want to run some methods on their class instead of mine.
Does anyone have any ideas?
[983 byte] By [
pbeshaia] at [2007-11-15]
> I've tried fooling around with URLClassLoader to do
> it, but it always gives me back the original.
Then you're doing something wrong. Without seeing your code, it's impossible to say what.
And remember that the parent classloader is called not only for the class that you intend to load, but also for all classes referenced by that class. That makes it tricky to avoid calling the parent classloader. If you do you may end up with referenced classes such as java.lang.String that have been loaded by seperate classloaders and you will start getting lots of hard to comprehend class cast exceptions.
The way I have avoided this is to create my own classloader which calls the parent loader for all classes except the one I am specifically trying to load and/or those in its package.
The first thing to make sure of is that your URLClassLoader is pointed at a directory (or jar file or whatever) that is NOT part of your classpath. If it's pointed at a directory that is in your classpath, and you ask it to load a class, it will delegate that to its parent. And since its parent can see the class in your classpath, it just loads it. So in this scenario you always get the original class, as you described.
> I have never seen this behavior. The classloader
> will load the class from wherever you point it. Even
> if its the same directory or jar. Classloaders
> delegate to their parents always unless you stop
> them. It has nothing to do with where the .class or
> .jar is located.
Right, but often the parent of your classloader will be the default classloader, which uses the classpath. So if you want the class to be loaded by YOUR classloader, rather than its parent (the default), then you have to make sure the delegation fails. Your class must not but on the classpath.
