A couple of days ago, I’ve attended Philly JUG for a talk titled Non-stop Java Development, presented by Ivo Magi of Zero Turnaround. The focus was on their product JavaRebel and how it can speed up development by cutting down on deployment time and on server restarts.

So what problem is JavaRebel trying to solve?  When you make code changes in the application you go through the usual cycle of:

{make-a-change} -> {waitFor: build-deploy-serverRestart} -> {check-the-change}.

JavaRebel claims to eliminate the second step of waiting for build/deploy and the need for restarting application server for the code changes to take affect.

No need to mention that I’m a big fan of open source model, JavaRebel is not in that category, it is a commercial tool. The presenter discussed about the available non-commercial options and why this product is better than the existing tools. As far as the available options (or approaches) there are two major ones — hot deploy and hot swap.

Hot deployment: When a class is changed build-deploy takes place without a need for a container restart. My experience with this so far has resulted in varied degrees of success. It works fine for a few times but had to restart the container/server after a few changes. (I also don’t have enough confidence that it can work effectively in a clustered production environment, but that is not the concentration of this post, it is the development time and how to minimize the wait time). OSGi approach is perhaps very similar to hot deploy except that it works at granular level on individual bundles, as opposed to updating the entire application.

Hot swap: An ability to change the class while a JVM is running, without the application ever noticing that. This is useful for the quick reload of classes during the debug time. If you change some functionality in the existing methods that works fine, but if you add a new method to a class or if you add a new class the changes are not detected.

Another option is that you may try your luck with some class loader hacks — loading the changed class in a different class loader, etc. I never tried it. Again, if anybody used this approach successfully please provide your comments. There are a few frameworks that were mentioned in the presentation that use this approach, I can only remember Tapestry at the moment.

As far as JavaRebel goes it extends the hot swap functionality.  It is implemeted as a JVM plugin (-javaagent). In simple terms an agent in JVM works like an interceptor in front of your main method. The -javaagent command line option is used to register custom instrumentation plugins. What I understood from the talk is that JavaRebel works at the class loader level, it doesn’t create new ones but extend the functionality of the existing class loaders.

Saving the application state after class reloads saves quite a bit of time, especially if you are working on a work flow kind of application and you are testing some step 8 of 10.  You can continue your test from where you stopped and doesn’t have to go back to step 1.

JavaRebel also seems to have some plugins to support popular web frameworks. I remember Spring, Guice and Struts were mentioned.

Obviously, I haven’t tried the tool so I can not make any recommendations. Try it for yourself and see if it suits your needs.

Share and Enjoy:
  • del.icio.us
  • DZone
  • Digg
  • StumbleUpon
  • Technorati
  • Reddit
  • Facebook
  • Twitter
  • Google Bookmarks
  • FriendFeed
  • Tumblr
  • HackerNews