Matt Raible has been building web applications for most of his adult life. He started tinkering with the web before Netscape 1.0 was even released. For the last 16 years, Matt has helped companies adopt open source technologies (Spring, Hibernate, Apache, Struts, Tapestry, Grails) and use them effectively. Matt has been a speaker at many conferences worldwide, including Devoxx, Jfokus, ÜberConf, No Fluff Just Stuff, and a host of others.

Matt is a DZone MVB and is not an employee of DZone and has posted 143 posts at DZone. You can read more from them at their website. View Full User Profile

All Java web frameworks should support hot deploy of a single class

01.24.2008
| 8838 views |
  • submit to reddit

In Anyone else using Groovy?, Tim Fennell (inventor of Stripes) raves at how much he likes Groovy now that it supports Java 5 features. He writes that Groovy might offer a solution to make development with Stripes faster:

The other thing I've been wondering about is that if there were enough demand for it we could try adding "improved" groovy support. E.g. throw your groovy actions under WEB-INF and we'll use groovy's built in stuff to do auto-reloading etc.

Gregg Bolinger responds with an excellent idea:

It would be really cool if Stripes could automatically discover and load changes to action beans (including new ones) without the entire app restarting, regardless of what the action bean is written in. But I realize that is a pretty tall order. :)

I agree that it might be a tall order, but I don't think it's impossible. In fact, I think all Java-based web frameworks should support hot deploy of a single class. We shouldn't have to buy JavaRebel to do this. It should be mandatory.

When an application reaches a certain size, the startup time can get pretty lengthy. This is lost development time. Furthermore, if any part of the development cycle takes longer than 15 seconds, there's a good chance developers will do something else (check their e-mail, move onto another task, etc.). Multi-tasking may be a good skill to have, but it's a horrible way to be productive.

Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? Maybe someone should just buy ZeroTurnaround and give away JavaRebel for free.

If I had one wish for 2008, it would be for all Java web frameworks to support this feature. Pretty Please?

Published at DZone with permission of Matt Raible, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Jim Bethancourt replied on Thu, 2008/01/24 - 11:55pm

I found that I've been able to set up a debug port and hot deploy code when I attach the debugger, but it has its limitations. Maybe Sun could buy JavaRebel, especially since they've been on a buying spree lately. :-)

Cheers,
Jim Bethancourt
President, Houston Java Users Group
Technical Architect, ROME Corporation

Rick Hightower replied on Fri, 2008/01/25 - 6:03am

Yeah this would be a great feature. Faster turnaround. Back in the day (if my memory serves me correct and I imagine still), Resin could scan a source directory and automatically deploy Java source files in a web application. It was not perfect. This gave the Java app more of a PHP feel for rapid-redeploy. It worked pretty well.

RE: Of the frameworks I'm familiar with, only Tapestry 5 and Seam support reloading single classes without restarting the whole application. Why can't the other frameworks "borrow" Tapestry 5's code? 

That would be great. How does Tapestry do that?

RE: Maybe Sun could buy JavaRebel, especially since they've been on a buying spree lately. :-)

Or... they could take the money from JRuby support budget and write it themseleves. Oh wait. Flame bait. Sorry.

Perhaps this could make it into Java 7.

I use the maven jetty plugin and it starts up darn quick even on rather large apps. Or maybe, I have been conditioned to slowness.

 

Thinking about this more... Wow wouldn't it be great to take this out as an argument against Java? It kind of takes the steam out of a lot of arguments if this support was built-in to the JVM. Good post Matt.

Seems like this should be a much higher priority than a lot of other things.

rick hightowercto of arcMindbloglinkedin

Steven Devijver replied on Fri, 2008/01/25 - 7:23am

Actually, reloading a controller/action class is pretty easy to implement. Grails and Tapestry 5 have it. Spring supports reloading of Groovy classes.

It's important to understand that reloading classes involves playing with the Java ClassLoader so there's no difference between Java and Groovy. You also don't need expensive products :-)

The hard part is reloading domain classes ...

Jevgeni Kabanov replied on Fri, 2008/01/25 - 8:10am

The hard part is reloading domain classes ...
And thats where "expensive" products come in. JavaRebel really does reload everything and always.

Steven Devijver replied on Fri, 2008/01/25 - 9:30am in response to: Jevgeni Kabanov

The hard part is reloading domain classes ...
And thats where "expensive" products come in. JavaRebel really does reload everything and always.
It's not the actual reloading that is hard, it's letting an application work without a glitch after reloading. If this expensive product can keep a Hibernate SessionFactory object working after a reload of domain classes, I'd be impressed.

replied on Fri, 2008/01/25 - 10:26am

During development, I can run a web project on Jetty configured as a Java Application debug configuration in Eclipse. The debug mode supports "hot replacement" which allows you to change quite a few things in your code without restarting. It requires restarting only when you change signatures or other stuff which seems reasonable to me. I use this approach whenever possible and it does increase productivity a lot. It is important that this scenario does not require any deployment or package building since Jetty picks up your Eclipse project classpath automatically. This really helps.

Also, it is important to design your components to be easily replaceable by stub/simple implementations so you can make your restart as fast as possible when necessary. For example, you can use specific Spring configurations for different cases and do the selection of the context configuration to load at startup using a command-line switch or a system property. This way you can avoid your database code startup if you're now working on UI by replacing your DAOs with memory-based stubs.

KiLVaiDeN CH replied on Fri, 2008/01/25 - 10:34am

I think that the required time to restart an application in a case of a change is negligible compared to the time required to provide the real important changed parts of the code.

But I must agree to the fact that it's inconvenient, having a hot swap system is very practical.

I just wonder how a product like JavaRebel is not open source, it sounds to me like a perfect candidate for an open source library, when you see products like Tomcat, Jetty, Drools, Hibernate and such are available for free, I doubt that paying for a product like JavaRebel makes sense..

Jevgeni Kabanov replied on Fri, 2008/01/25 - 10:45am

I just wonder how a product like JavaRebel is not open source, it sounds to me like a perfect candidate for an open source library, when you see products like Tomcat, Jetty, Drools, Hibernate and such are available for free, I doubt that paying for a product like JavaRebel makes sense..

It's the same as wondering why IntelliJ IDEA isn't open source if Eclipse and NetBeans are available. Sorry, but some things are just worth paying for.

150$ is basically 3 developer hours. If this tool can save you as much, it just paid for itself. And we estimate that it saves at least 5% of Java development time, so it will save you as much in a week and a half. A lot of people understand this and are enjoying at the moment not only increased productivity, but also plain pleasure from dropping the redeploy wait.

Jevgeni Kabanov replied on Fri, 2008/01/25 - 10:51am

If this expensive product can keep a Hibernate SessionFactory object working after a reload of domain classes, I'd be impressed.

Domain classes will update without a glitch, but of course you need to rebuild the session factory at the moment. It's really not that much of a problem, as database schema does not update too often. Of more concern are Dependency Injection frameworks like Spring, since business layer is updated much more often. We do have some plans for those.

Steven Devijver replied on Fri, 2008/01/25 - 11:05am in response to: Jevgeni Kabanov

If this expensive product can keep a Hibernate SessionFactory object working after a reload of domain classes, I'd be impressed.
Domain classes will update without a glitch, but of course you need to rebuild the session factory at the moment. It's really not that much of a problem, as database schema does not update too often. Of more concern are Dependency Injection frameworks like Spring, since business layer is updated much more often. We do have some plans for those.
So this expensive product actually can not reload applications when things get hairy. On top of that, it does nothing more than what Grails does in terms of reloading or what any other web framework could implement.

Jevgeni Kabanov replied on Fri, 2008/01/25 - 11:29am

So this expensive product actually can not reload applications when things get hairy. On top of that, it does nothing more than what Grails does in terms of reloading or what any other web framework could implement.

It reloads any changes to classes and works for all containers and all frameworks. Whereas Grails only works for Grails. And you will never get anything near the same level of support in web frameworks (at least not the Tap5 way). It works for pretty special cases, when the whole state of the instances is reconstructible, since without dropping all existing instances the classes will not reload. And even at that there are cases when it will fail due to classloader conflicting. JavaRebel uses a completely different approach.

Leo de Blaauw replied on Fri, 2008/01/25 - 12:42pm

Well,

 For a development setup I would suggest to check out JavaRebel, wich allows for just that.

Later

Leo 

Steven Devijver replied on Fri, 2008/01/25 - 4:32pm in response to: Jevgeni Kabanov

So this expensive product actually can not reload applications when things get hairy. On top of that, it does nothing more than what Grails does in terms of reloading or what any other web framework could implement.
It reloads any changes to classes and works for all containers and all frameworks. Whereas Grails only works for Grails. And you will never get anything near the same level of support in web frameworks (at least not the Tap5 way). It works for pretty special cases, when the whole state of the instances is reconstructible, since without dropping all existing instances the classes will not reload. And even at that there are cases when it will fail due to classloader conflicting. JavaRebel uses a completely different approach.
What works for Grails can work for any other web framework. It just takes a guy - me? - to write a few classes and open-source them. As for JavaRebel, those are some extraordinary claims. Since there are no technical details and its not open source there's no way to know what is and what is not.

Jevgeni Kabanov replied on Fri, 2008/01/25 - 6:53pm

As for JavaRebel, those are some extraordinary claims. Since there are no technical details and its not open source there's no way to know what is and what is not.

Ehmh... This really isn't some cat in a bag. Just download and try. We have a lot of happy users, which will testify for that as well.

Steven Devijver replied on Sat, 2008/01/26 - 6:11am in response to: Jevgeni Kabanov

As for JavaRebel, those are some extraordinary claims. Since there are no technical details and its not open source there's no way to know what is and what is not.
Ehmh... This really isn't some cat in a bag. Just download and try. We have a lot of happy users, which will testify for that as well.
Eh eh, no can do. I'm an open-source developer. I can't look at closed-source, IP-protected, subpoena-able software.

Jevgeni Kabanov replied on Sat, 2008/01/26 - 8:34am

Eh eh, no can do. I'm an open-source developer. I can't look at closed-source, IP-protected, subpoena-able software.

Right. It might jump up and bite you :) 

KiLVaiDeN CH replied on Mon, 2008/01/28 - 7:36am

Well, the (commercial) explanation on how and why people should buy JavaRebel is a little bit over estimated, 150$ is the price of 1GB memory which in my opinion improves much further the development time.

I kinda agree with sdevijver, and I see what his point might be. This looks like a niche software which exists for the sole reason of the money it can bring. I must congratulate you on your good commercial work for being able to sell a software with such little technical innovation at this cost !

Jevgeni Kabanov replied on Mon, 2008/01/28 - 8:42am in response to: KiLVaiDeN CH

I must congratulate you on your good commercial work for being able to sell a software with such little technical innovation at this cost !

You are not the first to say that, for some reason people believe that genuine technical innovation is impossible outside big companies and open source (whereas in reality startups provide a lot of it). I can only suggest you to take a look at this: http://www.zeroturnaround.com/blog/debunking-javarebel-myths/ and check JavaRebel out yourself.

Magir Nrave replied on Sat, 2008/02/02 - 12:10pm

Yea - let Sun just buy ZeroTurnaround and give away JavaRebel for free.

But till that happens, i'm more than glad to give $150 once, and earn

$200 per week more that i used to.

 

And don't forget, it's always a matter of what you give and what you get,

even in opensource floks. 

 

Freddy Daoud replied on Mon, 2008/08/11 - 9:28pm

Stripes now has a plugin to reload updated and discover newly added Action Beans, Type Converters, and Formatters. The plugin also reloads changes to the Resource Bundles. See Stripes-Reload.

 

Groovy Flow replied on Fri, 2009/02/27 - 10:14am

There is a very easy solution that's been available for Groovy ever since I patched the GroovyScriptEngine in groovy 1.5.7. Now, in devlopment mode, it's possible to scan a whole directory structure and reload instantly, using the new improved GroovyScriptEngine. This means you don't have to settle for reloading a single class, which has always been a very minor convenience. Reloading a directory structure makes development a totally different, and rather pleasurable experience.


The GroovyFlow open source project makes implements the solution (http://code.google.com/p/groovyflow/) but it's important to realize that anyone could do the same thing easily. Why's that important? Well, you might not care for GroovyFlow's reliance on JSON, or the way GroovyFlow imimitates Rails partials so that there's no Tiles xml nightmares when working with AJAX. Of course, I suspect you'll actually like these features, but if you just want full Groovy reloading, you don't need GroovyFlow. If anyone's interested, I'll be glad to break the reloading capability out of GroovyFlow, at least to demonstrate how you can do it yourself. My email address is GroovyFlow@gmail.com.

Tadeusz Skrzyszowski replied on Fri, 2009/03/13 - 5:09pm

This sounds pretty interesting, doesn't it ?

Sfafaef Adfasg replied on Fri, 2012/06/01 - 10:21am

The debug mode supports "hot replacement" which allows you to change quite a few things in your code without restarting. 10mb Internet

Passion Lab replied on Wed, 2012/06/06 - 9:10am

Thinking about this more... Wow wouldn't it be great to take this out as an argument against Java? It kind of takes the steam out of a lot of arguments if this support was built-in to the JVM. Good post Matt. Scottsdale Mountain

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.