JRebels with a JCause

JRebel has a great elevator pitch: install a simple tool and ensure your developers never have to do a repetitive, time-wasting task again. You don’t need a time-and-motion study to see the benefits to productivity – who wouldn’t want it?

The repetitive task JRebel eliminates is redeploying your application inside a container like Tomcat. If you’re developing a web application in Java, you may find yourself doing this every time you change a class, so you can get speedy feedback. With JRebel, your changes just magically appear in the deployed application – no human intervention required.

This would have been a lifesaver for us a couple of years ago. Back then, redeploying our app was something we all did hundreds of times a day, and it took minutes to complete – due in part to Hibernate caching the world at startup. And thanks to the lovely PermGen OutOfMemory error, every six or seven times you’d actually have to restart Tomcat, which took even longer. We could have gotten a lot of swordfighting done in those wasted hours every day.

However, as we try it out we’re finding that JRebel is less useful for us now than it would have been then, because:

  • We have much faster machines – a full Tomcat bounce takes under 20 seconds. At these speeds, there’s no point trying to optimise by redeploying – just start the bounce script, sip your coffee twice, and get back to work.
  • We use Test-Driven Development, which gives us an easy way to get immediate feedback on every code change as soon as we make it, no deployment needed. So we look at the changes in the application less often, which in turn means fewer bounces.
  • We couldn’t get JRebel to handle some of the clever code we write these days:
    • New static final objects didn’t show up in the application automatically. We use a lot of these in our controller code.
    • Adding a missing @Inject annotation to make Guice happy didn’t, because the change didn’t deploy. We use Guice to simplify our code and eliminate factories and singletons.
  • Looking at code JRebel had reloaded in the debugger was a confusing experience. Some ordinary objects showed up as opaque handles instead of their normal selves, and where our code dynamically reads a field on an object using reflection, we found that JRebel replaced this object with a Serializable with no methods or fields.

We had heard great things about JRebel, so we were a bit surprised by these results and consulted a friend from CITCON, David Gageot of Tech4Quant. David tells us that he finds JRebel invaluable in one particular case – editing Java Server Pages (JSPs). Because JSPs are a bit of a Frankenstein mix of HTML and Java, developers can wind up in a very tight tweak-view-tweak again loop getting the UI just right, and if seeing application changes means a restart and login every time, those are going to be some frustrated coders.

It’s clear that JRebel is a real lifesaver for David and probably would be for anyone using JSPs or similar code. Since we don’t, we’re unlikely to use it in a serious way. But we can certainly admire the JRebel team for solving a very hard problem elegantly!