How to avoid jvm caching objects?

Question

I'm programming a class, which will be loaded into another class. Everytime I did some modifications on my class, recompile it, kill the loaded object, and reload it, the old version will be loaded again, rather than the newly compiled version. So I have to shut down the whole thing, and start again. please help. thanks.

Answer 1

Well, now, you are right along the lines of what I am working on. I am building a plugin engine that will offer this type of ability along with many other features. Of course, it isn't exactly what you are trying to do, per se, but the class loading stuff, reloading and picking up the new object, that stuff is what I am working on as well.
First of all, your message is a little vague on what you are doing. Is your application creating an object at runtime, then you "modify" the source while your application is still running, and then your app creates a new object but is still retaining the old version of the class, thus not picking up your modification to the source? I am guessing this is what you mean. You then need to answer if you are using a separate class loader instance for this object that you wish to reload. In this case, an object and a class are the same thing, because you are only creating one of them at runtime then wish to reload it with a new version of the class/object.
In any case, for every class you wish to reload at runtime with a new version, EVERY SINGLE CLASS must have its own class loader instance. I have no idea if you understand how the JVM loads classes, the classpath, and so forth, but let me give you a bit of what I have learned.
First, the JVM has a "system" class loader that it uses to load the Java APIs and usually all of your classes to an application unless you create an instance of a class loader to load your classes. I forget, to be honest, if there is more than one classloader the JVM uses. I think there is a boot loader for the API classes, then a system loader that has as its parent the boot loader. Now, if you are unfamiliar with the ClassLoader hierarchy and how it works, a good read is the ClassLoader API docs. It explains the delegation model. Then read the URLClassLoader docs, as it explains how it uses its own URL as a classpath, in which you can add more URLs to its classpath and so forth.
The delegation model works like this. Every class has a ClassLoader, usually its the System loader because most developers never get into the class loading issues. They develop an app that is launched by the JVM in the normal way java -jar someapp.jar or java myclass with various parameters and attributes. If their code never creates a ClassLoader instance to load classes dynamically, then every class of their app shares the same one classloader instance, the System loader. This is why your classes never have to include any of the JDK/JRE runtime, its automatically done for you as part of the boot loader classpath, which the system loader picks up due to how the delegation model of ClassLoader works. Now, lets get on to that. The delegation model is a way a ClassLoader instances looks for a class when asked by the JVM to find a class. First, the classloader looks in its "cache" of already loaded classes. If not found, it then asks the parent class loader to find the class. If the parent class loader can't find the class, it finally calls its findClass method, which is what the API recommends any new classloaders override to do their own specific class loading features. This is the delegation model in short. It ensures that the very first time a class is being loaded, the parent classloaders are searched first before your own classloader instance has a chance to find it however it needs. There is one problem I have with this. IF any class you need to load lies within the JVM classpath (or in the case of a J2EE deployed application, lies within the J2EE classpath or web-app classpath), it is ALWAYS found by the parent classloader before your classloader instance ever gets a chance to load it. What I mean is, if you create your own classloader, extending say URLClassLoader, and you try to load a class that you want to eventually reload, because the JVM classloader (or parent loader) loads it first before your own classloader implementation gets a chance (via the recommended findClass() method you should override and implement for your needs), you can't ever really "reload" the newly modified class, because it is within the JVM's classpath (or J2EE/web-app).
As I have had to do with my plugin engine to ensure any class can be reloaded, I have to override the loadClass() method of ClassLoader. Now, to understand why this is done, you need to understand how the JVM works, which in fact I posted a message on the JVM forum of this site just earlier today to get exact info on. The JVM, when it loads the bytecodes of a class, as far as I know asks that class' ClassLoader instance to "find" any classes the class implements, extends, or imports. If you have Class A use Class B, and Class A has its own classloader with say NO parent loader, and Class B has its own loader with no parent loader as well, The Class A classloader instance needs to "see" the Class B .class file (visibly) somehow in order to understand HOW to use Class B in the Class A use of it. Man this gets tricky to explain. So, somehow, Class A and Class B must be within the same path so that Class A classloader can also instantiate Class B for its use in Class A. I am using the word Class loosely here, because we know that every Class becomes an object when instantiated. Anyway, in order to have every class reload, every class must have its very own instance of a ClassLoader. Ideally, using URLClassLoader works well for this because you can declare URL objects as part of the classpath a URLClassLoader instances looks for classes in.
Anyway, that is all the time I have for this right now. Let me know if it helped at all, or if you have any more questions. I'll watch the topic and check back soon.