All Java web frameworks should support hot deploy of a single class
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?
+1 to it.
Yesterday started Tap5 development, it's _awesome_. It's like back to PHP again :) working so damn fast.
But there is a serious drawback from live reloading - I can't work with any other framework (e.g. Tap4), the container restart is killing my productivity :( the only way is to rebell?
Posted by Renat Zubairov on January 24, 2008 at 04:54 PM MST #
I agree that java/j2ee has typically had a inefficient reload cycle. In 1997 nettdynamics, a java framework had hot reload!
Ways I combat the problem.
Posted by James Law on January 24, 2008 at 05:12 PM MST #
As a person who spent a lot of time working on getting the class reloading to work, here's my 2 cents:
BTW just as a side point next week we are releasing the JavaRebel 1.1M1 with full support for annotation reloading and start working on frameworks like Stripes reloading their metadata without application redeploy. If anyone is interested in contributing, join our community.
Posted by Jevgeni Kabanov on January 24, 2008 at 05:41 PM MST #
Posted by Damian Harvey on January 24, 2008 at 10:43 PM MST #
Posted by Nick Lothian on January 25, 2008 at 12:25 AM MST #
It's true that there's some leaky metaphors with live reloading; Tapestry requires that the components be in specific packages to allow for live reloading (note: I consider this a plus even if live reloading wasn't available), and you get some class cast exceptions if you reference classes *inside* those packages from *outside* those packages.
However, as nice as 100% full reloading across all logical and physical layers would be, you get tons of bang for your buck with what's available in T5. My catch phrase is "I've never changed an EJB because I didn't like the color." As you move away from the database (changes are somewhat glacial) and towards the user ("can I use a different font here?") you need a tighter feedback loop for your modifications.
When a data transfer object (or Hibernate entity) changes, yes a full restart is required, taking (with Jetty) all of maybe three seconds. But with view logic changes, generally a give-and-take between the template and the component class, there's no waiting at all.
Yes, it's impossible to go back once you have this.
Posted by Howard M. Lewis Ship on January 25, 2008 at 12:53 AM MST #
If a full restart takes 3 seconds what do you need live reloading for? The last project I worked on, full restart took 2.5 minutes! And Jetty does not make much of a difference, it's a great light container, but most of the reloading time goes to the applications.
Posted by Jevgeni Kabanov on January 25, 2008 at 02:12 AM MST #
Posted by Renat Zubairov on January 25, 2008 at 04:02 AM MST #
I personnaly thing that all web container shoul support hot deploy of a single class. It's web container responsability, not web framework ?
Posted by Jean-Christophe Lagache on January 25, 2008 at 04:34 AM MST #
The annotation reloading in M1 sounds good, but wouldn't it be necessary to also update the internal metadata cache for each framework? Sounds like a tedious task to do, given the amount of java frameworks around (my vote goes for Stripes :-).
Are there any plans or JSR's for JDK7 for better support of class reloading at the vm level? I heard something about better support for dynamic languages, maybe Java could use some of this as well. Any info anybody?
Posted by digital.alterego on January 25, 2008 at 05:30 AM MST #
Yep. We are releasing the SDK as Open Source and hope for some contribution from community. Anyway, it is not always as hard as it seems. I did Guice in two days, and I never seen the codebase before.
It is likely that Java 7 will get INVOKEDYNAMIC opcode, but this doesn't solve class reloading. Seeing that Java module system is slated to be included in Java 7 it's unlikely that any other classloading modifications will be included.
Posted by Jevgeni Kabanov on January 25, 2008 at 07:06 AM MST #
To re-iterate/re-enforce: the point of class reloading is to avoid container redeployment, since that will lose all session state and context.
Yes, Hibernate adds to the startup time, but just another couple of seconds (that's nice to avoid, with live reloading). Tapestry's class transformer and template parser and related technology are all very fast: in a very non-scientific test, I can see that the very first request into my integration test suite has to transform, parse and load 65 pages and a smattering of components, this all happens in 4451ms, about the time it takes to compile and load a JSP (order of magnitude, anyway). And having your start page hit 64 other pages is very rare, a typical application start page will have page links to only a smattering of other pages.
Posted by Howard M. Lewis Ship on January 25, 2008 at 09:23 AM MST #
Posted by Bryan Noll on January 25, 2008 at 11:10 AM MST #
@HLS: In some applications the hibernate startup time can be much longer. Our app takes about 15 seconds to do a full redeploy and the vast majority of that time, 12-13 seconds, comes from the hibernate startup. Maybe we have a more complex schema/more entities than is common, I don't know.
Also, Tomcat (not sure about other containers) have ways of persisting sessions across redeploys. We use it and it's worked well for us. So we do have to wait the 15 seconds for a redeploy, which sucks, but our sessions and context are still valid.
Posted by Tim Fennell on January 25, 2008 at 01:39 PM MST #
So let me get this straight: we're worrying here about developer productivity (via bouncing the app server) and the answer to this is hot deploy....while simultaneously and constantly talking about which web framework is the best?
How much developer productivity is lost di**ing around with adopting the framework of the moment? How many times do you need to relearn the same old stuff, albeit with a different framework?
How often do we need to hear the same old garbage arguments about Struts vs. JSF vs. Wicket vs. Tapestry vs. SpringMVC vs. RoR and how a "real developer" should be able to "pick it up in a few days"?
Posted by Tony on January 26, 2008 at 04:48 PM MST #
Posted by Anonymous on January 27, 2008 at 03:50 AM MST #
Posted by Eelco Hillenius on January 29, 2008 at 12:10 AM MST #
Posted by Eelco Hillenius on January 29, 2008 at 12:14 AM MST #
I've found that you can enable true hotswap deployment in Jetty by hooking up a remote debugger to your Jetty server from Eclipse. Instructions here:
http://www.clickonchris.com/2010/05/configuring-jetty-maven-and-eclipse-together-with-hot-deploy/
Posted by Christopher Johnson on May 28, 2010 at 08:10 AM MDT #
Posted by Stephen Haberman on August 18, 2010 at 09:24 AM MDT #
Posted by Zofren on March 15, 2012 at 09:45 AM MDT #