JRebel, also known in the past as java-rebel, is a class reloading tool, that will automatically reload your classes when you change anything in it. And with anything, I mean anything (well almost anything, but the exceptions will follow shortly).
Normal hot-swapping containers can also reload classes in some occasions, but those occasions are limited to the content of existing methods (and for a number of times. After a couple of times of reloading classes in tomcat, you might or might not start to see different results then you are expecting). JRebel however can reload many more situations, for instance when methods are added or removed, or when the signature of the method is changed. In all of these situations JRebel can reload your classes without requiring a restart of the container. And that is a huge time safer.
There are some exceptions to the reloading though, static final Objects that are part of other classes will not be reloaded of course, since they are already done loading. An exception to this rule is the reloading of final Strings. These will be reloaded by the JRebel class loader.
For instance, given the following code in a spring web mvc controller, called ExampleController:
public static final String COMMAND_NAME = "commandd";
your web page will most likely not find this command, since the name should have been ‘command’ without the double ‘d’ character.
Now, if you rename the content of the COMMAND_NAME to “command”, JRebel will kick in and tell us:
JRebel: Reloading class 'ExampleController'.
JRebel-Spring: Reconfiguring bean 'exampleForm' [ExampleController]
And now your page (using the command object by the name “command”) will display correctly. You just saved yourself a restart of the container.
Of course, this should have been captured during a JUnit test, but JUnit-testing of webpages is not always the best option to build a web application.
Even annotations (not all of them) can be hot-swappable by JRebel. For instance, if in the same controller we have a method, defined as:
@RequestMapping(value = "/user/addExample.html", method = RequestMethod.GET)
public ModelAndView addExample(final HttpServletRequest request) {
...
}
and we decide that this method should be handled by the superuser from now on, and thus the url should be changed, then that is no problem either for JRebel. Just change it to the new url and it will be available for your application.
If we had changed the name of the method as well, then this too would have been reloaded without any issues.
All these small kind of refactorings each day can add up to a lot of restarts of the container, and if all these restarts are not required anymore then the coffee-corner-team will start to miss you. According to the JRebel website, the time saved can be from 10 to 23 procent.
The only downside I can see at the moment is that JRebel is not free or open source and that you have to buy an annual description. But this will be worth it in the end, you just have to try to convince the ‘powers that be’ to spend some cash on this tool. If you want to start programming in Scala (and who wouldn’t want that these days) then you can get a scala license for free for a year. (See Scala license for free ). It is also possible to try JRebel for free for 30 days, but afterwards you are stuck with the ‘powers that be’ again.