Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Multiple Techniques Seek to Bring Dynamic Deployment to JEE

Multiple Techniques Seek to Bring Dynamic Deployment to JEE

This item in japanese

Web application developers using dynamically typed interpreted languages like PHP, Python or Ruby are used to being able to make a change in their application and see it immediately by refreshing the browser. Whilst this capability is generally supported for JSP pages, in the Java EE world a developer typically needs to go through a build and deploy cycle each time they want to test a change, a process which can dramatically slow down incremental development.

A number of vendors are looking to improve the situation for Java and, broadly, two techniques are being used.

The first and most well established involves reloading the entire ClassLoader. This is the approach that is used by WebLogic's ChangeAwareClassLoader for example. The method has two substantial limitations. The first is that state information is lost and has to be re-created. The second is that, whilst typically faster than a full re-deploy, it is still time consuming since a number of steps need to be performed. In an application server environment these may include:

  1. Destroying all running listeners (HTTPEvenListeners etc.), Servlets and Filters.
  2. Creating a new ClassLoader.
  3. Re-initialising listeners, Servlets and Filters.
  4. Restoring state information

Reloading of object state is typically restricted to objects that implement Serializable and do not contain any non-serializable fields as described in the context of the Aranea framework in a blog entry here. JBoss has done some work to extend it for Seam and Java EE 5 using two ClassLoaders, one for the Seam components and one for EJB3/Hibernate etc. When something changes in the Seam components or configuration, Seam is re-started without a full re-deploy being required. Changes for EJB/Hibernate components still require a full re-deploy since there is currently no way to dynamically load the Hibernate metamodel. The JBoss Tools IDE project aims to make this as seamless as possible to the developer. The serialization technique should also work for a number of other frameworks such as Rife and Tapestry 5.

The second approach is JVM level hotswapping. Java SE 5 introduced a limited form of hotswapping providing the ability to redefine a class at runtime without dropping its ClassLoader or abandoning existing entities. However the declared fields and methods of the class cannot be changed, which limits its usefulness. A number of vendors are now stepping in to try and improve the situation, amongst them ZeroTurnaroud and BEA.

ZeroTurnaround have recently announced the final release of Java Rebel 1.0 which sees a number of improvements over the first public release including better performance, reflection support, and better support for Java 1.4. The number of supported application and web servers has also increased and includes:

  • BEA WebLogic 8.x, 9.x, 10.x
  • 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)

It may be possible to get unsupported Application Servers such as Glassfish or WebSphere to work using a custom ClassLoader as described here. The 1.0 release does not yet support annotations though this is planned for 1.1. JavaRebel is commercial software with a developer seat costing $149. A free trial is available.

The BEA offering is an alternative to their ChangeAwareClassLoader called FastSwap with very similar capabilities and limitations to JavaRebel though it is also obviously restricted to the WebLogic server. It is currently available in the technology preview of WebLogic 10.3 and described in more detail here (PDF file).

Full hotswapping for a statically typed language like Java is still very much an active research topic and may never be achieved. However the work that is going on under JSR 292 for dynamic language support in Java 7 is looking to improve the situation for dynamic languages that target the JVM. The hope is that the combination of invokedynamic and full hotswapping should allow implementations of languages like Python, Ruby and Groovy to use the JVM object model directly. This will improve the performance of those languages on the JVM considerably and that work should in turn help drive out more advanced hotswapping for the Java language itself.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • current hotswap often good enough

    by Patrick Mueller,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    My experience with hotswap is that often you aren't creating new fields or methods in Java, during medium-long development strides; ie, I might go an hour futzing with just the bits in a method body. In that case, I can stay linked up with my runtime, in Eclipse, and have those changes loaded dynamically, during debug. Sure, it would be nice to support MORE situations; especially, probably, just adding methods and fields, which seems like a fairly safe thing to do; but the current situation is not too terrible.

  • A story of a Java Rebel

    by Tomasz Blachowicz,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    A cartoon: A story of a Java Rebel is classic one! Hilarious :)

  • Class reloading+config file reloading=save time

    by Chetan Mehrotra,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I always wanted that feature in Java. With all the different frameworks the dev time gets waste considerably in server startup. I generally prefer following in my dev
    1. Use exploded directory deployement format
    2. IDE Hotswap
    3. Some custom jsp to reload xml configuration required by framework like Spring,Struts e.g. reloading validation.xml for validator framework, properties file for message resources in Struts etc. Specially working with web ui it always happen that you miss out something

    Apart from class file reloading I would also want various framework should also have such options of auto reloading config files without server restart

    Javarebel looks promising but its commercial :)

  • Re: Class reloading+config file reloading=save time

    by Jevgeni Kabanov,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Well think of the time you save and especially of the nerves you save by not being constantly interrupted. We actually have a calculator for financial implications in this executive presentation:

  • Anyone try FastSwap yet?

    by David Cabelus,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Has anyone tried FastSwap yet? We've seen dramatic improvements in iterative development cycle times with this new feature in WebLogic Server 10.3. I'd be interested in hearing feedback.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p