java rebel vs grails

[Jason Mayer]

How is this different than the way grails allows hot deployment? I took the time to learn a little bit about groovy and grails this weekend, and was very impressed with the ability to make changes on the fly.

That question aside, my jaw did drop when I saw the demo. Excellent work

[Jevgeni Kabanov]

Grails uses the same approach as Tapestry 5, RIFE and some others. It involves wrapping a class (or classes) in a distinct classloader and when the class changes dropping the old classloader, creating a new one and loading the class anew.

The problem with this solution (or one of the problems) is that with the old classloader and the old class you also have to drop all existing instances of the class. In some cases (like when class is serializable or it is a singleton and has no identifying state) instances are easy to reconstruct. In general this is not the case.

Grails wraps all controllers and some singleton components into this classloader, but this does not apply to the rest of the code like utility classes and etc. Also you may get ClassCastExceptions unless you use the "var" notation.

JavaRebel on the other hand preserves all existing instances as is, reloads all classes indiscriminately and does not create any new classloaders. We actually discussed getting JavaRebel to work with Groovy with Groovy developers since it also works e.g. for Scala. At the moment it waits for a fix for call site caching feature of the Groovy compiler.

[Jevgeni Kabanov]

Oh, and I wrote a blog post about the multiclassloader trick some time ago:
http://blog.araneaframework.org/2006/11/21/zero-turn-around-in-java/

[Jason Mayer]

thanks for the quick response! that cleared it up for me