JavaRebel is a JVM plugin (-javaagent) that enables to reload changes made to Java class files on-the-fly, saving developers the time that it takes to redeploy an application or perform a container restart. It is a generic solution that works for Java EE and Java standalone applications. Find out more.
It is our great pleasure to present the first milestone of the 2.0 release. It includes numerous changes, both visible and under the hood, with yet more to come in the next milestones. Download it now or read the changes below.
The major themes of this release were:
- Startup time and performance overhead.
We have optimized or otherwise eliminated most of the bottlenecks that made the previous versions slow for some of our users. For this release we mainly focused on the runtime performance overhead, which has been decreased more than an order of magnitude and should be negligible in most cases. This should also directly affect the long startup time, as it was often caused by prolonged initialization routines in the previous versions.
Compatibility was a strong concern for this release. We have devoted a lot of time to tweak reflection and annotations support as well as integration with specific frameworks. We also compiled an extensive test suite that should make JavaRebel work out of the box for most users.
- Embedded plugins: Spring and Guice.
We now support distributing the plugins along with JavaRebel instead of downloading and installing them separately. With this release we have included Spring and Guice, so you should be able to load new components and dependencies without redeploying. More plugins will be included as they are stabilized or contributed.
- Virtual classpath.
Another concern for many of our users is configuring the existing build/deploy environment to make use of JavaRebel class reloading. Not everyone can use the exploded development and
-Drebel.dirshas limitations in support of new classes and resource propagation.
That’s why we implemented something we call a virtual classpath. The
-Drebel.pathproperty behaves similar to the
-Drebel.dirs, except that instead of directories you can add WARs directly, with EARs and more advanced options coming soon. Virtual classpath will also propagate new classes and update your resources, like HTML or JSP files. It does require some extra configuration so take a look at the configuration manual.
NB! Virtual classpath is only supported on Tomcat, Jetty and WebLogic containers in this release.
- Improved API.
Besides the embeddable plugins we also now support third-party instrumentation. This will allow us to support e.g. AspectJ load-time weaving. Unfortunately the plugin itself didn’t make it into this release, but since the required infrastructure is now in place we can release it retroactively as a plugin.