Share

From this page you can share Reloading in Java to a social bookmarking site or email a link to the page.
Social WebE-mail
Enter multiple addresses on separate lines or separate them with commas.
Reloading in Java
(Your Name) has forwarded a page to you from Ajaxonomy
(Your Name) thought you would like to see this page from the Ajaxonomy web site.

Reloading in Java

Tagged:  

When Ruby on Rails was all the rage a few years ago, it really shook up the Java community. Many people tried to understand the impact of Rails, what made it so appealing, and how its success could be translated into Java. As a result of all this soul-searching, lots of reasons were given for Rails' popularity, but the most compelling one was the fact that its fast turnaround allowed developers to stay in the "hot zone" while they were coding: make a change and--bam!--see it instantaneously. This was, at the time, the very antithesis of the compile and (re-)deploy cycle that Java developers were used to.

But how could this be done in Java? It was certainly no easy task: though Java could load classes dynamically, redefining their definitions during execution was entirely another matter. In 2002 Sun had introduced a promising experimental technology in to the 1.4 JVM called Hotswap that was incorporated into the Debugger API. The idea was that you could recompile your code while you were still in debug mode and have the JVM pick it up instantly without needing a restart, thus enabling all kinds of developer productivity. The problem was, though, that Hotswap was very limited--it could only replace the body of a method--and most of the time you needed to restart the program anyway, so the productivity never really materialized.

Well, years passed (imagine a tableau of changing seasons) and Rails, though still a popular framework, never really gained the larger foothold among developers that its initial trajectory promised. The buzz died down, and Java developers by and large stuck to their old habits. But the promise of greater productivity in Java still remained, and has inspired a few to pursue it...

JRebel

One of those few is ZeroTurnaround, maker of the award-winning JRebel. (They've even released a free version recently, though it has a few string attached.) JRebel makes use of some pretty sophisticated classloading tricks (with just a dash of instrumentation) to accomplish dynamic reloading of class definitions: within the classloader, it uses one master class and several anonymous support classes backed by the JIT transformation runtime. JRebel has its limitations as well, most notably in the area of redefining class hierarchies.

JRebel is by far the most well-known product in this area, and presumably with the one with the most commercial success. But it does have competition...

FastSwap

Weblogic 10.3 (+) has a new feature called FastSwap. It has its limitations, but is generally a step forward--if you program on Weblogic, that is.

Javeleon

There's another product, Javeleon, which also does dynamic redefinition of Java classes at run time. Javeleon has been developed at the University of Southern Denmark in collaboration with Sun Microsystems/Oracle as a research project. It also claims to have advantages over JRebel and FastSwap in what type of redefinitions it can support at runtime.

DCEVM

But you're thinking: shouldn't this type of functionality just be provided within the JDK itself?

Well that's exactly what another, less-known alternative does: the Dynamic Code Evolution VM. DCEVM is a modification of the Java HotSpot VM (applied directly as a patch) that allows unlimited redefinition of loaded classes at runtime. DCEVM was developed as a research project of the Institute for System Software at the Johannes Kepler University Linz, and supported by Oracle and Guidewire Software.

In my personal experience with DCEVM (full disclosure: it is the only product listed in this article that I have direct experience with), I've found it to be really rock-solid and dependable. The only drawback that I have noticed is that it has stayed at version 0.2 for quite some time now, and seems to be slipping in its support of newer versions of the JDK. Now that one of the leads of the project (Thomas Würthinger) is an Oracle employee, one would hope that Oracle would eventually integrate this into the JDK itself. This would give all Java developers access to the amazing productivity gains that class redefinition provides.

Conclusion

Class redefinition is really a no-risk technology: in the worst-case scenario, the redefinition fails and you have to restart the Java program to debug--something you would have had to do anyway. So you really can't go wrong in upgrading your current option (Hotswap) with something far more capable. You won't just be saving yourself those reboots: you'll also be keeping yourself mentally in the "hot zone" where true productivity is found.