Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
See all our reports

New and Noteworthy in JavaRebel 2.0

  • Packaged deployment. We now support deployment as WAR/EAR with exactly the same feel that exploded development has. All the classes and resources will be reloaded on the fly as soon as you hit Save. All you have to do is create a rebel.xml configuration file that will tell JavaRebel where to find the updated classes and resources. On top of that we now provide a Maven plugin that will do this configuration for you!
  • Very low performance overhead. The performance of the application with JavaRebel enabled is now pretty much the same as without JavaRebel.
  • Better startup time. Application or server startup time should be much nearer to the usual one, though there still is more work to be done when starting with JavaRebel, so some slowdown is expected.
  • Spring, Guice, Stripes, Tapestry 4 and Struts2 reload out of the box. Plugins for those frameworks are now included with JavaRebel and allow configuration to be changed instantly, just as classes.
  • Better compatibility. We’ve done a whole lot of work on making JavaRebel more compatible with Java projects in the wild. This involved making sure that Reflection API behaves 100% predictably, extensive test suites in many environments and lot of integration work. In particular AspectJ load-time-weaving, IBM WebSphere and Groovy are now fully supported.
  • Pingback: JavaRebel 2.0 is released – improves upon the award-winning 1.0 | ZeroTurnaround.com()

  • How do you use this with groovy (within IDEA)? IDEA compiles into classes and javarebel picks up the recompiled class changes yet groovy related (closures) are not.

  • How do you use this with groovy (within IDEA)? IDEA compiles into classes and javarebel picks up the recompiled class changes yet groovy related (closures) are not.

  • I’m not sure what Groovy closures are compiled to. Could you post this on the forum, with some examples?

  • I’m not sure what Groovy closures are compiled to. Could you post this on the forum, with some examples?

  • It appears that groovy closures are compiled into classes versioned by a static integer.

    However, you state that the JavaRebel does work with groovy. I looked for the plugin yet it does not appear to be available.

    My question is, how do you provide support for groovy?

    Thanks

  • It appears that groovy closures are compiled into classes versioned by a static integer.

    However, you state that the JavaRebel does work with groovy. I looked for the plugin yet it does not appear to be available.

    My question is, how do you provide support for groovy?

    Thanks

  • There is no specific plugin, but we do have some special support for groovy that fixes call-site caching in reloaded classes. I’m not sure about closures, Groovy support was tested by Groovy users, not ourselves. I don’t see why closures wouldn’t be reloading though, if they are compiled to such classes.

  • There is no specific plugin, but we do have some special support for groovy that fixes call-site caching in reloaded classes. I’m not sure about closures, Groovy support was tested by Groovy users, not ourselves. I don’t see why closures wouldn’t be reloading though, if they are compiled to such classes.