Boosting productivity using JRebel

by Denis TunovićSeptember 13, 2011

At JTeam I am involved in a number of projects. One of the more important projects at the moment is a Hippo project. During a Hippo training I was introduced to a tool that could speed up development time considerously. At Hippo they use JRebel to speed up CMS development. With JRebel you make changes to your code without the need to restart after every change. As I am always looking for tools that make me more productive, I wanted to try this out myself.

In this blog post I’ll show you my findings after experimenting with a Spring MVC application using Wicket running on Tomcat as well as Jetty.

Before we can use JRebel we need to configure our development environment.

As I am an IntelliJ user I also need to install the IntelliJ plugin. Check this page for the reference.


After starting the web application using the plugin I was modifying some JSP files. In IntelliJ usually I need to repackage the JSP using the CTRL + ALT + F9 command and then refresh the page to see my changes. With JRebel refreshing the page only, resulted in my changes visible immediately. I can change my code and refresh. In the log I could see that JRebel reloaded my JSP without needing to executing the repackage command. Here it did save me one extra step.

Spring Context

Next I went for the Spring controller. At start up the Spring context is loaded with my controller bean. In the controller I changed the method implementation and Spring configuration in the annotations. The only thing I needed to do is to recompile my class. JRebel reloaded my class and reconfigured my bean. Running the application without JRebel and recompiling the class made no difference to neither the method or Spring configuration. Although I needed to recompile my class, I didn’t have to restart the server to reload all my Spring context. Depending on how big your application is, depends how much time it can save for you not having to restart. In my case it saved me about fifteen seconds.

However when I was making changes to my Spring XML configuration it didn’t reload some changes. After trying to find out why I came across this post. In one of the replies Lauri explains that not all changes in the xml files can be reloaded by JRebel. JRebel can apply configuration changes to singleton beans that are created and configured by spring directly and not through a factory bean.


Using Apache Wicket in a couple of projects, I was wondering how JRebel could help me develop Wicket applications faster. I can reload both my HTML and class, but changes in HTML will only be visible if the class is recompiled. So when you change the HTML, you should only recompile the class. Not using JRebel gives you the opportunity to only reload HTML and not the class. Again some time saved here.


After testing some features using Tomcat, I was wondering how it would behave under Jetty. I started same Wicket application that I tested in the previous example using Jetty. It behaved almost the same way as in Tomcat. The only difference when not using JRebel, I had to recompile the class to see changes in the HTML. The changes in class file were not visible.


You can make JRebel monitor your changes through your all your dependencies by generating JRebel configuration in each of your modules. Each module is then monitored and changes in your dependencies will reflect in the web module while the application is running. This can easily be done by including the plugin in your Maven parent pom:


A good example here is Hippo. Although Hippo 7.6 comes with configuration for using JRebel by default, version 7.5 is not. You can have the plugin generate the configuration for JRebel by placing the above code in the CMS and HST parent poms. This will enable you to reload your changes in Hippo. Depending on the hardware you use it can save you about ten minutes of rebuild and restart time for both the modules.


JRebel will definitely save you quite some time developing and boost your productivity. Not having to rebuild or restart is every developers dream. Depending of the size of you application it can save you a couple of minutes till tens of minutes. There are some minor features that could work better. Nevertheless it should be part of every developer’s toolkit who works with enterprise Java.