I have a piece of software, contained in a single .jar that is doing its job but sometimes I need to quickly push a bug fix necessitating replacing the .jar file in a central location, unfortunately if there is a currently running execution of this jar file if I replace it then it crashes with “class not found” error. I thought that once a jar file is executed the JVM will cache it in memory and won’t do any reads from the disk but apparently this is not the case, how can (if possible at all) this be remedied?
EDIT:
The application is not web-based. It’s normal Java SE.
JAR files are not loaded into memory in bulk, as other shared object libraries are. Their classes are loaded into memory on a demand basis, so if you remove a JAR file and a class lookup needs to occur, the file handle the class loader will be invalid (because the open file it referenced is now gone) and you will get an error.
Operating systems manage the file handles, so replacing an open file with a new copy is not going to fool anyone. You need to close the file first, which often can only be done by garbage collecting the class loader. If you are using the system class loader, then that means shutting down the JVM.
People have written frameworks to create custom class loaders that can be disposed independently of the system class loader; however, this does complicate class loading. While it can accomplish what you are asking, it cannot do so without restructuring your existing program to accommodate the lookup of classes in the framework’s class loaders (and accommodating the loss and gain of class loaders over time).
If you want to try such a framework, see Christian’s post. If you want to learn a bit more about how one project uses class loaders to facilitate its needs, take a peek under the covers of Apache’s Tomcat, which restricts web applications within their own class loaders.
Often you might find that the correct answer really is to stop the service prior to deployment, and start it after deployment.