JRebel is great for an agile environment

One of the basic tenets of agility is to be always in a fast feedback loop. You develop in short iterations (sprints, is you use Scrum). If you believe in Test Driven Development (as I do), you execute tests as frequently as possible.

Accordingly, I believe your development environment must facilitate the capability to redeploy your application in zero time (ok, a few seconds might be bearable). If you have to wait two or three minutes to redeploy your app to see the effect of your last code change, you will be destroying the fast feedback loop, with subtle consequences to your concentration and focus. And you will probably avoid it, getting less and less feedback.

I’ve always been able to create almost instant-redeploy environments in which we did not have to pack jars or wars, and little changes to a class did not force us to redeploy the apps.

However, my last project is a distributed app that includes several wars which share several jars, and so on. When I arrived there, it was taking almost 4 minutes to recompile and redeploy the whole app. Of course, changing a class and expecting the change not to force us to redeploy the app was a dream. Yup!

Besides, I wasn’t able to use the setup I had been using for my last projects: I was caught between a rock and a hard place.

Enter JRebel.

JRebel is a tool that allows instant class redeploy to a jar, war or ear: it just sits there checking whether a .class file is modified, and silently loads it when that happens. And it works. And, it works always! No corner cases of ifs so far.

Configuration is so easy you’ll probably have to configure it just once for the whole project lifetime, and will be able to forget it.

If you are not using JRebel, you are throwing away your time, focus and energy. Seriously: get it!

3 responses to “JRebel is great for an agile environment

  1. Pedro,

    Just read your post about JRebel and am intrigued. While our production environment is Tomcat I have been using Resin for development because it supports similar functionality (live monitoring/reload of class files to the JVM). Are you familiar with Resin? If so, do you know of any advantages of JRebel? One reason I may try it is so that I am developing/testing on the same app server as our production environment. perhaps there are other benefits…


    • Unfortunately, I am not familiar with Resin, and therefore can’t compare its capabilities with what JRebel provides. Just for the record, I can tell you that JRebell allows you to reload classes that live in .WARs, .JARs or whatever else, making it unnecesary to regenerate them -a real PITA for multi-module apps. I don’t know whether Resin allows this -I would be impressed, if it did!

      JRebel is so easy to set up and so unobtrusive that I would recommend you to take a look at the trial: unlike many other tools, it will not force you to change your existing configuration in one way or other, you just add a very short file per-project.

      And, if you are creating open source code, they will give it for free! In fact, that’s how I got it.

    • Resin can just redeploy the application when it changes. This is not a unique functionality among the containers. Tomcat, Glassfish, JBoss and others can do that as well. The difference is that with JRebel you do not _redeploy_ the application but only update the changed class. In fact, it loads a new “version” of the class without dropping the classloader and thus keeping the objects state intact.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s