주의:이 페이지 정보는 10월 2009에 종료되었습니다

최신 정보는 밑의 링크를 참고하세요.

또는 이 상품의 특정 라이센스를 구입하실 경우는, 가격 및 제품 취급 상황에 관해서는 이쪽 으로 연락 주시기 바랍니다.

이 페이지에 표시된 정보는 최신정보가 아닐 경우가 있습니다.

ZeroTurnaround 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.

The major themes of this release were:

• Startup time and performance overhead.
  ZeroTurnaraound have optimized or otherwise eliminated most of the bottlenecks that made the previous versions slow for some users. For this release they 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. ZeroTurnaraound have devoted a lot of time to tweak reflection and annotations support as well as integration with specific frameworks. ZeroTurnaraound also compiled an extensive test suite that should make JavaRebel work out of the box for most users.
• Embedded plugins: Spring and Guice.
  ZeroTurnaraound now support distributing the plugins along with JavaRebel instead of downloading and installing them separately. With this release ZeroTurnaraound 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 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 ZeroTurnaraound implemented something they 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 which is explained in more detail in the configuration manual. NB! Virtual classpath is only supported on Tomcat, Jetty and WebLogic containers in this release.
• Improved API.
  Besides the embeddable plugins ZeroTurnaraound now support third-party instrumentation. This will allow ZeroTurnaraound 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.

What's changed in JavaRebel V1.2.2?

• Fixed a NPE in Method.getParameterTypes()
• Fixed Class.getMethods() not showing some of the added methods
• Fixed a classloader deadlock
• Added support for JBoss 5

JavaRebel monitors class file modification times and reloads classes when needed. This solution introduces Ruby like development to Java developers and saves the time spent waiting for the changes to propagate with redeployment or container restarts. JavaRebel: No more redeploys.

JavaRebel integrates with all the major JEE containers, JVM implementations and is completely IDE agnostic.

Developers can add/change/remove classes/methods/fields/annotations to Java classes without restarting the application. All state is preserved while reloading the changes as no classloaders are dropped and no serialization/deserialization happens in the background.

JavaRebel reloads individual class files by default (e.g. the ones in WEB-INF/classes. This makes it very comfortable to use incremental compilation available with modern IDEs and immediately see the changes in code in your application. JavaRebel can also reload classes bundled in JARs, WARs and EARs.

JavaRebel reloads classes lazily. This means that if you have (re)compiled a class file it will get reloaded once an instance of the class or the class itself is used - method call is made, field is accessed etc.

JavaRebel supported JVMs

• Sun Java 1.4.x
• Sun Java 5.x
• Sun Java 6.x
• JRockit JVM 8.1 sp6 or later
• JRockit JVM 9.x 1.5.0_06 or later
• IBM J9 1.4x
• IBM J9 5.x
• IBM J9 6.x
• Apple MRJ 1.4.x
• Apple MRJ 5.x

JavaRebel supported Containers:

• IBM WebSphere
• BEA Weblogic 8.x, 9.x, 10.x
• GlassFish v2
• Oracle OC4J 9.x, 10.x
• Tomcat 4.x, 5.x, 6.x
• JBoss 3.x, 4.x (on Java 5 or later)
• Jetty 5.x, 6.x (on Java 5 or later)
• Equinox OSGi (including Eclipse plugins)
• IntelliJ IDEA plugins

JavaRebel works best with:

• Java EE
• Java standalone apps
• Groovy
• Spring
• Struts2
• Google Guice
• Tapestry 4

JavaRebel Plugins
JavaRebel’s ability to reload classes and configuration changes is extensible - so you can add new functionality that is specific for your setup with ease. Plugins can be created using the JavaRebel SDK. The following are included in the JavaRebel installation so you do not need to download them individually.

• JavaRebel Guice plugin - Supports discovering new Guice (implicit) components, adding/removing implicit setter and field dependencies and reconfiguring @Singleton’s.
• JavaRebel Spring plugin - Takes advantage of JavaRebel class reloading to reload Spring dependencies. It supports registering new Spring beans, adding/removing dependencies and adding new MVC controllers and handler methods. These can be done using either XML configuration or annotations.
• JavaRebel Struts2 plugin - Supports reconfiguring Struts actions when the action class changes.
• JavaRebel Tapestry 4 plugin - Supports adding, changing, deleting Tapestry listeners without container restarts.
• JavaRebel Stripes plugin - Adds reloading of Stripes ActionBeans.

Why buy JavaRebel?

One of the selling points of PHP, Ruby, Python and other interpreted languages is faster development. This is not based on the superiority of the language constructs, but instead on the minimal turnaround time in development environments.

JavaRebel aims to provide the same productivity in Java.

JavaRebel Deployment Process
The typical JEE developer spends their day in the development-compile-deploy-test cycle.

• Sourcecode change <1 second
• IDE compilation finished <1 second
• Appserver deployment 20 seconds to 2 minutes
• Caches reloaded  <1 second
• State deserialized <1 second
• Browser refreshed <1 second

Total Time: 21 seconds to 2 minutes

As developers perform this cycle several times a day it is a significant financial loss for SWD departments, additional risks appear, developers typically get bored and either read a Slashdot article or grab another cup of coffee etc.

Faster Deployment with JavaRebel
As opposed to a usual deployment procedure JavaRebel does not spend any time on reinitializing the application and does not interrupt the developer routine. Instead it reloads the code for updated classes only and continues to run the application as is.

• Sourcecode change <1 second
• IDE compilation finished <1 second
• JavaRebel code reloading <1 second

Total Time: 1 second

JavaRebel Benefits

• Saves deployment cycle costs (could be hundreds of dollars per month)
• Developer can program continuously, without breaking concentration
• Allows rapid debugging sessions, seeing the results of small changes immediately
• Decreases new developer’s training costs