I wanted to post this inquiry from our ZeroTurnaround Support Forum because it brings up a great feature of LiveRebel that we often show during LiveRebel demos – the compatibility check feature you can use to ensure your live app hotpatch will do what is intended.
“Could you tell me what does LiveRebel actually do when saying that this or that update is compatible / not compatible with the deployed version ? Does it basically look for supported/nonsupported changes (http://zeroturnaround.com/software/jrebel/features/)?”
The compatibility check is for hotpatching only. We distinguish 100+ low-level changes that can be applied to a class/method/field during the update (e.g. adding a new static field). Each type of change is known to be either a) fully compatible, b) compatible with a warning (depends on the actual application and change), or c) incompatible.
During the compatibility check, LiveRebel compares classes between the old and new version and tries to detect those types of changes in your application. The compatibility of the whole update is detected by the worst single change it contains.
Any change to an XML is “compatible with a warning”. For configuration changes we recommend to use rolling restart or full restart.
The LiveRebel team has also developed this Compatibility Test into a standalone command-line tool that is able to take 2 archives (JAR, WAR, EAR) and give you a compatibility result. This is helpful if you have multiple historical archives of your applications available. With this you can check how many of those updates could have been updated in an instant and how many would have required some other strategy (rolling restart or full restart).
In the end, LiveRebel isn’t going to let you break anything without literally forcing it to accept a rolling restart or offline update. For the instant hotpatch feature to be effective, both the old and new versions of the classes are checked and must be compatible.
Contact firstname.lastname@example.org if you’d like to learn more!