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:
- Destroying all running listeners (HTTPEvenListeners etc.), Servlets and Filters.
- Creating a new ClassLoader.
- Re-initialising listeners, Servlets and Filters.
- 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.