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

Automate your reports FREE 90 Day Trial
iServer Express for BIRT eclipse.dzone.com

Free Open Source Project Hosting Disappointed with SourceForge?
Host your project at JavaForge! JavaForge.com

Ads by DZone

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?

Average:

Average: 1 (1 vote)

(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 Fri, 2008/01/25 - 12:55am

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 - 7: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 hightower

cto of arcMind

blog

Steven Devijver replied on Fri, 2008/01/25 - 8: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 - 9:10am

And thats where "expensive" products come in. JavaRebel really does reload everything and always.

Steven Devijver replied on Fri, 2008/01/25 - 10:30am in response to: ekabanov

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.

ivan_memruk replied on Fri, 2008/01/25 - 11: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 replied on Fri, 2008/01/25 - 11: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 - 11:45am

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 - 11: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 - 12:05pm in response to: ekabanov

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 - 12:29pm

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 - 1: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 - 5:32pm in response to: ekabanov

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 - 7: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 - 7:11am in response to: ekabanov

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 - 9:34am

Right. It might jump up and bite you :)

KiLVaiDeN replied on Mon, 2008/01/28 - 8: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 - 9:42am in response to: kilvaiden@gmail.com

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 - 1: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 - 10: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.