With its commitment to shared-memory concurrency, Java applications have traditionally followed a pattern of big initialization up front. This is great for production where that extra spin-up time will presumably be amortized over the running life of the application. It sucks for the developer making frequent, incremental changes.
Modern frameworks like Play! and Grails offer ways around this. But they aren’t perfect and of course, you have to already be using the frameworks to benefit from them. And reloading code in an arbitrary setting is a much trickier problem than reloading code between web requests. The JVM itself has limited framework-independent powers of reloading, it can hotswap code inside method bodies but thats about it. Want to add a new method? You have to start again from Compile.
Enter Spring Loaded: a -javaagent that sledgehammers your bytecode into a form that allows arbitrary changes to be implemented on top of plain old JVM method body hotswapping. It comes from an upcoming version of Grails where it replaces classloader-style reloading but works equally well with Groovy’s venerable antecedent.
As a demo, I’ve forked a sample Prime Faces app I found on github and added reloading support: here. In order to have new methods and bean properties picked up by JSF in EL expressions, I had to implement a Spring Loaded plugin to clear a metadata cache inside javax.el.BeanELReloader. This jar is vendored in the demo project and the sources are here. If you want to build Spring Loaded from source, I implemented a Gradle build for the project which I will try to get integrated back into the main Spring Loaded repo, but which is available separately here (branch: gradle-build).