Sami Dalouche

Java HotSwap support is being improved with each release. More information about it can be found in Jonas Bonér and Geert Bevin posts.

The goal of hot swapping is to allow the JVM to take new versions of the classes into considerations without reloading the JVM/Application.
Jonas believes it is a bad idea, but I think he refers to the ability of HotSwap to be used for AOP-like byte code instrumentation. Jonas seems to be heavily involved in AOP framework development, so I am not going to contradict any of his claims.

However, I DO believe that HotSwap can be used to improve the developer’s experience. Consider a web application that contains 100 Hibernate classes and takes 20-30 seconds to load. Most of the development time is spent loading and reloading the context, for each slight change in the Controller and View layers. Baiscally, if you want to add some stuff in a web page, you have to

1] Modify the action (Struts/Webwork Action, Spring MVC Controller, or Tapestry Page) to load the data from a database

2] Modify the view (.jsp/.jtl for Spring/Struts/Webwork, .html for Tapestry)

3] Deploy the application (30 seconds)

4] Test it. See that there is an error.

5] Correct the error, re-déploy the application (another 30 seconds)

and so on…

So, one of the solution is to use Jetty to deploy the application (for instance, using the Maven2 Jetty6 Plugin). This allows for hot-redeployment of JSP pages, but does not take the new classes changes into consideration. Jetty + Tapestry 5 is an attractive option for developers since it allows for hot deployment of both the HTML and Java code. This is awesome, except that I believe it should not be the MVC Framework’s job to do all the gory details of detecting new classes, re-loading the new ones, and so on. It is necessary to have a generic solution that will benefit all frameworks without specific support from them.

And this solution is called Java HotSwap. I am looking forward to having IDE support for that, that will allow to forget, once for all, this costly  change-build-redeploy  process.

This entry was posted on Wednesday, December 6th, 2006 at 9:20 am and is filed under Java. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.