JRebel

Today I’ve got a chance to play with the JRebel library a bit.

It’s really cool for J2EE developers who do not wish to restart application server after rebuilding application code. It can save you a large amount of time.

JRebel provides its own classloader which wraps every class of the application with a small additional logics. It allows you to replace classes in runtime without redeploying/restarting your application and allows to see class changes immediately.

It’s very easy to configure JRebel:

  1. Download JRebel archive from http://www.zeroturnaround.com/jrebel/
  2. Unpack archive to some folder
  3. Add -javaagent:<JRebel JAR path> JVM parameter to the batch file which starts your application server
  4. Run your application server. As a result you should see JRebel’s greeting in the console:

    #############################################################
    JRebel 2.1a (200910071200)
    (c) Copyright ZeroTurnaround, Ltd, 2007-2009. All rights reserved.
    …….
    #############################################################

  5. Now set the output of your project in IDE to the application server folder where your application is deployed. So the classes will be reloaded every time you compile project in your IDE! Some IDEs(like Eclipse) do not allow to specify output folder out of the project scope, in this case you can create a trivial batch file which will copy all the compiled classes to the exploded WAR/EAR.

This technology is quite similar to JVM HotSwap, which was first introduced in JDK 1.4. It also allows to change code in runtime but JRebel has very huge benefits. HotSwap does not allow changing schema, like creating/removing classes/annotations/methods/constructors/fields in runtime, while JRebel does. So HotSwap allows you to make changes only within the method, while the scope of changes allowed by JRebel is really fantastic.

Please refer to the following links to get deeper into this topic:

  • JRebel
  • HotSwap