JRebel (formerly known as JavaRebel) has been an increasingly popular item in the Java—and other JVM language—developer's tool chest. After making modifications to a Java class definition, JRebel notices such changes and reloads the modified class inside a running JVM. That, in turn, makes it unnecessary to restart a running application during development, an often time-consuming and frustrating task. JRebel has also proven useful in deployment environments where application restarts are not an option: Upon deploying a new WAR file in a Web application, for instance, JRebel arranges the changed elements in the WAR to update in the running JVM without having the restart the VM itself.

A common thread in JRebel updates has been for the tool to make increasingly more intelligent decisions about what needs to be reloaded into a VM, primarily by JRebel observing an wider array of artifacts in Java APIs and frameworks. In that vein, JRebel 3.0 adds support to EJB, JSF, and JPA development. Making changes to a JPA configuration, for instance, will also trigger a reload of all related Java classes into the VM.

Hibernate, Spring, and JSF are also supported more extensively in the latest release. As well, configuration changes in Guice, Struts, log4j, Stripes, Tapestry, Wicket, Velocity, and some other frameworks are also supported now. Thus, it is possible to work, for instance, on a Java project in Eclipse, make a change to a log configuration, and observe the effects of that change right after saving the changed configuration file, without having to restart Tomcat or some other app server used during development.

What do you think of the latest JRebel features?