I have one jar file in my application\'s class path. At run time, I add new classes to the jar file and sometimes also modify the fields/methods of the existing classes. Current
URLClassLoader
has one problem and that is that the jar file remains open.URLClassLoader
and you change the jar file at runtime, you will usually get this error: java.util.zip.ZipException: ZipFile invalid LOC header (bad signature)
. The error may be different.close
method on all URLClassLoader
s using the given jar file. But this is a solution that actually leads to a restart of the entire application.A better solution is to modify the URLClassLoader
so that the contents of the jar file are loaded into the RAM cache. This no longer affects other URLClassloader
s that read data from the same jar file. The jar file can then be freely changed while the application is running. For example, you can use this modification of URLClassLoader
for this purpose: in-memory URLClassLoader
Normally to reload a class you need to unload the entire class loader. i.e. remove all references to all classes loaded for that class loader.
Another option is to use instrumentation to change the byte code of an existing class. This usually comes with limitations and changing fields is something you cannot do. i.e. the objects of that type would have to be translated somehow.
What I normally do is have services which are very quick to start/restart. This way to you easily restart a process which needs updated code ideally by pressing the Run
in my IDE. This minimises deployment time as well.