I first became aware of JRebel about a year ago and became addicted after a lightning talk by Jevgeni Kabanov at JavaZone 09 and the introduction of the tool into my Java development toolbox a couple of days later.

I’m quite sure every developer who has spent a significant amount of time developing web applications in various application containers will nod their head when I say that a great deal of time is wasted watching the log output from an application container restart fly by.

For me, JRebel showed me a problem area of my application development which I really didn’t know existed. I had simply accepted it as a part of the development cycle. In this article we will look at how JRebel reduces the need for container restarts in a small web application project. We’ll perform some changes to our code and see how testing in Tomcat with and without JRebel behaves.

http://www.flickr.com/photos/giovannijl-s_photohut/ / CC BY-SA 2.0

What’s JRebel?

JRebel is a  JVM agent which instantly reloads your code upon change without having to restart the container or redeploy the application[1]. It integrates into your JVM as a classloader extension and enables reloading of classes without having to create a new classloader which is often the case when redeploying or restarting application containers.

One of the major differences from other hot swap tools is the support for method signature changes and configuration changes for frameworks such as Spring and Guice. This means you can perform major refactoring of your classes without having to restart or redeploy.

Lets go through the steps to get it all up and running – so you can see for yourself!

JRebel with Tomcat and Eclipse

In this article we will use JRebel with Eclipse Galileo and Tomcat 6.0. I will not be guiding you through the installation and setup of JRebel, as there are excellent, easy to understand guides for this over on the JRebel home pages. We will also be using Spring Framework, to show some of the benefits of JRebel’s Spring application context support.

Our example project

Our example project in this article will be a simple web application created using the Maven webapp archetype. We will create a simple controller and view using Spring MVC, and perform various changes to the controller – to see how a Tomcat instance with and without JRebel will behave and cope with these changes.

To simplify the tutorial I’ve set up the basic demo project for you, which is ready to be imported into Eclipse and used as the basis for the rest of this article. Download the project package here.

Here are the different modifications we will perform and compare the behaviour of Tomcat with and without JRebel:

1. Modify the request handler method, alter the content of our model.
2. Modify the request handler method by refactoring.
3. Method signature modification.
4. Dependency injection using Spring’s autowire feature.

These are three rather small modifications to our project, but they are sufficient to show the power of JRebel in many web application developments.

Let’s get down to business!

I’ll assume you have gotten our example project imported into Eclipse and performed a test deployment on the Tomcat server.

1. Modify request handler method, alter the content of our model.

First we do a very simple modification and alter the message that we are putting into the model:

model.put("message", "Hello, Codemunchies fans!");

This change is easily handled by both Tomcat instances and we immediately see the change in our browser, as well as JRebel telling us that the IndexController has been reloaded to reflect the changes.

JRebel: Reloading class
    'com.codemunchies.jrebel.IndexController'.
JRebel-Spring: Reconfiguring bean 'indexController'
    [com.codemunchies.jrebel.IndexController]

2. Modify request handler method by refactoring

Our request handler method currently puts a simple message into the model, which is then rendered in the JSP. Our second modification will be to extract this into a separate method and change the message.

Our code now looks like this:

@RequestMapping("/index.html")
public String handleRequest(ModelMap model) {

	populateModel(model);
	return "index";
}

private void populateModel(ModelMap model) {
	model.put("message", "Hello, JRebel tester!");
}

Upon saving the IndexController.java file we immediately get a hot swap error from Eclipse telling us certain code changes cannot be swapped.

In our JRebel instance of Tomcat, you will currently not see any log output indicating that a change to the .class file has been made. Don’t worry, this is perfectly normal, as JRebel will not act on your changes until resources are requested. We do a reload in our browser and watch JRebel kick into action – lightning fast:

JRebel: Reloading class
    'com.codemunchies.jrebel.IndexController'.
JRebel-Spring: Reconfiguring bean 'indexController'
    [com.codemunchies.jrebel.IndexController]

No context reloading is performed by Tomcat and the change we made to our class is live in a few milliseconds. In order for our non-rebellious Tomcat instance to reflect the changes a restart was necessary, and the server spent 2.2 seconds restarting with my test setup. It shall be noted that you can achieve faster reload times by only reloading the module you’re working on through the Tomcat Manager application.

These reload times may not seem like much, but consider a much heavier application, with a dozen controllers, a couple of data sources and Hibernate session factories… You’re quickly spending a significant amount of time waiting for the context reloading!

3. Method signature modification

The limitations of the hot swapping feature provided by the JDPA are clear. Many developers may find it sufficient for their needs, but the rest of these examples will show what you gain by using JRebel.

In this third example we’re going to change the signature of our populateModel method to take a second parameter which will be the message we want to put into our model. Our code should now look like this:

@RequestMapping("/index.html")
public String handleRequest(ModelMap model) {

	populateModel(model, "Message after method signature modification.");
	return "index";
}

private void populateModel(ModelMap model, String message) {
	model.put("message", message);
}

Again, JRebel kicks in upon a refresh in our browser and the changes are immediately visible:

4.  Dependency injection using Spring’s autowire feature

Our last example will be a little more extensive – this is where the fun starts. We will introduce a new service class which we will inject into our IndexController using Spring’s autowire feature, and finally use this service to obtain the data we want to put into our model.

First we create our service class, let’s call the interface DataService and our implementation DataServiceImpl. The example code is shown below.

public interface DataService {
	String getData();
}

import org.springframework.stereotype.Service;

@Service
public class DataServiceImpl implements DataService {

	@Override
	public String getData() {
		return "Hello! I'm a rebel in disguise!";
	}
}

We then inject this service into our IndexController and modify our populateModel method to obtain the model data from the service, as shown below:

@Controller
public class IndexController {
	@Autowired
	private DataService dataService;

	@RequestMapping("/index.html")
	public String handleRequest(ModelMap model) {
		populateModel(model);
		return "index";
	}

	private void populateModel(ModelMap model) {
		model.put("message", dataService.getData());
	}
}

Remember to touch, or otherwise mark the context file(s) where your beans are defined as edited, or JRebel will not reload your context. This is especially important when you are using the component scan feature of Spring – it’s easy to forget when you’re never editing those XML files.

Upon refresh, JRebel immediately reloads the Spring context and our bean:

INFO: Loading XML bean definitions from file
    [.../jrebel-demo/src/main/webapp/WEB-INF/jd-servlet.xml]
JavaRebel-Spring: Reloading Spring bean definitions in
    '.../jrebel-demo/src/main/webapp/WEB-INF/jd-servlet.xml'.
INFO: Pre-instantiating singletons in ...
JRebel: Reloading class 'com.codemunchies.jrebel.IndexController'.
JRebel-Spring: Reconfiguring bean 'indexController'
    [com.codemunchies.jrebel.IndexController]

And our browser shows us that the changes we made are in effect:

Again, JRebel has saved us from a tiresome Tomcat reload and if we multiply these reload times with the number of such changes we normally do during an average day of development, we quickly see that there’s time to save.

JRebel is not perfect and you will need a container restart now and then, but it is still a huge time and frustration saver and is well worth the license fee. At the beginning of February JRebel displayed the following statistics for my last 30 days of development:

Over the last 30 days JRebel prevented the need for at least 215 redeploys/restarts. JRebel saved you between 5.7 and 11.6 hours.

Deployment and container restart times may vary depending on the container you use and your development pattern. This article is by no means attempting to benchmark Tomcat or JRebel, but is showing how you in many cases may save valuable development time.

References

[1] http://www.zeroturnaround.com/jrebel/faq/#What_is_JRebel