In my last blog post, I lamented the slow turnaround and overall heaviness of enterprise Java development. I also said that I would be checking out JRebel, a tool designed to let you make code changes and push them out to a running application without restarting the application. My verdict? I loved it, convinced my boss to buy it, and am an enthusiastic user. But it is not flawless, so adopters should keep expectations realistic.
We should keep in mind the scope of what JRebel is trying to accomplish. It's not just a matter of reloading updated classes. Enterprise Java has gotten very complex and bulky. Even if you don't use most of them, there are a zillion frameworks in the ecosystem to choose from. They use proxies, AOP, XML configuration files and annotations. What good is the ability to hotswap a class if what you changed is a DB named query that is living in an XML file somewhere? The prevalence of dependency injection frameworks and annotation-based object instantiation means it's not straightforward to even update a running object -- with all its dependencies -- in-place. JRebel tries to handle all that, along with multiple versions of Java, EJB, application servers and IDEs. It's a complex tool for a complex platform. Unfortunately, glitches come with the territory.
Some of JRebel's limitations comes from its sheer ambition. It needs to keep up with Java's vast and fast-moving ecosystem. For example, at the time of writing JRebel's Hibernate plugin still does not support Hibernate 4, though they say it's a priority. Everything else works, but I'm mainly missing its ability to deploy changed named queries in XML files that I mentioned earlier. Or conversely, their Spring WS plugin only supports Spring WS 2, so I disable it when I'm working with Spring WS 1.x.
Some of my colleagues have also seen glitches from the way we configure JRebel. If you have code in multiple modules, you are supposed to write a rebel.xml file that points to the classes in those modules. This adds to your running application's classpath. Because rebel.xml allows wildcard expressions, it is possible to drag in way more stuff than you realized. The result is that we have seen weird glitches in the running application because things are appearing in the classpath due to an over-promiscuous rebel.xml. This is probably a newbie mistake, but one that is easy to make and hard to diagnose, adding to the overall complexity.
So if JRebel can have glitches, may not support all your libraries, and does not reduce complexity, why do I love it so much? To put it simply, when I get it working right, Java development is a dream. Any interruption in the development process can interrupt your mental flow. Wait a few minutes to build, or even a minute to restart the server, and you get thrown off. Distracted. On the other hand, you work in a completely different mental mode when all those accidents vanish. The path from thought to code to reality is effortless. Change the code, refresh the browser, see your changes. Recently, I was making code changes to two different applications simultaneously running under JRebel and talking to each other. Again, it was effortless: change the code, refresh the browser, see my changes.
Another thing I like about JRebel is that the commercial company backing it, ZeroTurnaround, provides excellent support. They are very responsive when we have questions, and they fix bugs rapidly. JRebel itself is under active development and gains new features rapidly.
Ideally, an application platform should be designed from the ground up to be hot deployable. Grails is a joy to work not just because of its hot deploy capability, but also because everything just works. It comes ready to go "out of the box": build system, application server, database (even an SQL console) and command line interface. Just add your browser and enjoy. By contrast, JRebel has a tougher job because it retrofits a platform seemingly designed to thwart programmer productivity. But no other product comes close to what JRebel can do. Precisely because JRebel largely succeeds in what it claims to do, I wholeheartedly recommend it for those of us doing conventional Java enterprise development.