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. 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.dirs has limitations in support of new classes and resource propagation. That's why we implemented something we call a virtual classpath. The -Drebel.path property 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. It is still an experimental feature and will be improved on in the next milestone 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.

Congrats on the release. I haven't tried your product yet but I will in the near future. An important issue for me is wether or not you support Seam. Is Seam supported in this release?

Congrats on the release. I haven't tried your product yet but I will in the near future. An important issue for me is wether or not you support Seam. Is Seam supported in this release?

Changes to backing beans are supported, but new methods might not yet be visible in JSF. We need a special plugin for that. The linked download is a trial version.

We need a special plugin for that.

Do you know if such a plugin is on the roadmap?

We need a special plugin for that.

Do you know if such a plugin is on the roadmap?

That very much depends on the community involvement. Each plugin we had so far has either been contributed, or helped with by a member of the corresponding community. We just don't have the time/resources necessary to become experts in Seam ourselves.

Is there a trial version available?

Been using JavaRebel for longer than a year now. It's worth its price in gold. Time saving results in money saving, doesn't it. Keep it up. Don't bloat it. That's unwanted pregnancy. Make plug-ins plug-able and don't force them on users. That's terrorism. Don't burden users with configuration details for basic usage. That's good sense. Thanks for a great tool.

Been using JavaRebel for longer than a year now. It's worth its price in gold. Time saving results in money saving, doesn't it.

Thanks, Florin! We will start including plug-ins in JavaRebel, though. We want more and more things to just work out of the box without any additional user actions.

Interesting. The website mentioned support for Weblogic 10.x and the Install.html mentioned you can use it for EAR file as well. Sounds like this will be able to use for EJB as well not just the war files. Does this conflict with Weblogic's autodeply feature ? or Do you have to disable one to use another ?

also does JavaRebel support Glassfish ?

also does JavaRebel support Glassfish?

JavaRebel supports all major containers including Weblogic 10 and Glassfish.

also does JavaRebel support Glassfish?

JavaRebel supports all major containers including Weblogic 10 and Glassfish.

Do you know the answer to my prev. question ?

Does this conflict with Weblogic's autodeply feature ? or Do you have to disable one to use another ?

Does this conflict with Weblogic's autodeply feature ? or Do you have to disable one to use another?

It doesn't conflict with it, it will be disabled automatically when JavaRebel is enabled.