Like many other java users, for years, I have been yearning for true hotswap. I want to add or remove methods, fields, interfaces and everything else like that at runtime and my vm in debug mode should be smart enough to put it in without complaining about non-binary compatible changes. If you have already heard about “Dynamic Code Evolution VM”, you can skip this whole article, as it adds nothing new, but if you haven’t ….
Now thanks to the effort by some really smart guys at Institute for System Software at the Johannes Kepler University Linz, this is possible. We can find the binaries here. The jar file acts like an installer which searches for the vm (or you can point one to it) and then soups up the jre to provide the better hotswap. If we want to revert to the original vm, we can uninstall this patch via the same installer jar. This installer can enhance 1.6 jres too.
Since the actual implementation does need to make some changes to the core pieces, internally it replaces the libjvm.xx with its own version. This change can be undone if we uninstall the patch. We can find the source code here. This source is a bit back dated, but gives us an idea of what the actual changes are.
The way it works is when a new version of the class is fed to the vm, it loads the new version and switches all usages to it. The class structure has been modified to maintain multiple versions of itself.It also takes care of updating the existing objects with the new fields and methods. To do so, it does make some real changes at the method and interface table level as well as the way classes are stored. (oversimplification alert).
In case of enterprise applications, it is possible that we may need extra operations to be done on these, if that is the case we can use something like classfiletransformers to know which classes have been changed and then make the proper changes for it. For example if we change a spring bean and introduce a new dependency, we can detect that the transformed class is a spring artifact and then update this bean with the new dependency (my version schedules a task from the classfiletransformer which executes a few seconds later that looks up the same bean in spring context and wires the new dependency field).
I seldom blog about solutions in which I have no hand, but this is an exception, as I think there should be a lot of noise about this feature and a lot of appreciation for Thomas Wuerthinger, so am doing my bit.
P.S: If you are thinking about java rebel, the approaches are very different, so go through the source to get a better understanding before drawing any conclusions or comparisons.