In case you missed it, on-the-fly reloading is the hot thing right now.
A great argument in the everything-vs-Java flame war says that you can miss your children growing while waiting for the change-redeploy-test cycle to complete. Matt Raible and Tim Fennell expressed it as a reasonable idea: web frameworks should redeploy actions on the run.
Changing JVM bytecode has been possible since JVM 1.4: your IDE will send updated bytecode to the debugged VM, given that no changes affect the class structure (attributes or methods), and JavaRebel was born to fill that niche. Starting with JavaRebel 1.1M1, there is a SDK to be notified about class reloading events. After seeing how Jevgeni successfully connected JavaRebel with Google Guice, I reserved a weekend to peek at the promising new release (isn't that what weekends are for? no? really?).
Three hours. That's all it took.
Within three hours, Loom was detecting and redeploying modified actions. Configure your eclipse project to use uncompressed folders (which you should have done already), add the javarebel agent ("-noverify -javaagent:${REBEL_HOME}/javarebel.jar"), and that's all. Changes to action classes will be applied on the next browser refresh.
The point you should remember is the following: it took me a couple of hours to get it working. Start making noise in your favorite forums: hibernate, struts, wicket, whatever - there is no such concept as "loud enough". Reclaim your hot-redeploy features.
I would love to see this feature included in the JDK some day :)
P.S.: To be fair, getting the first action reloaded took was really fast, but a real polished behavior in jetty and tomcat, reloading as the affected JPA classes were modified took a bit more.
UPDATE: ZeroTurnaround has issued an open letter to the Java Community expressing their intention of supporting Java frameworks that plan to integrate on-the-fly class reloading.