PHP やPython、Rubyといった動的型付けのインタプリタ言語を使っているWebアプリケーション開発者達は、アプリケーションを変更してブラウザを更新することで、すぐに確認できることに慣れている。JSPのページではこの機能が概ねサポートされているのに対し、JavaEEの世界では、変更した箇所をテストしたいときにはいつも、開発者はビルドとデプロイを繰り返さなければならず、この手順はインクリメンタルな開発のスピードを急激に落とすことがある。
多くのベンダがJavaのこの状況を改善しようとしており、広く、2つの手法が使われている。
1つ目の最も確立されている手法は、クラスローダ全体のリロードを必要とするものである。このアプローチは、例えばWebLogicのChangeAwareClassLoaderで使われているものである。この方法には2つの重大な欠点がある。1つ目は、状態に関する情報が失われるため、再作成しなければならないことである。2つ目は、一般的には全体を再配備するよりは速いが、それでも時間がかかることであり、それは必要なステップがたくさんあるからである。アプリケーションサーバの環境では、以下のようなステップが行われるだろう。
- 実行中の全てのリスナ（HTTPEventListners等）、サーブレット、フィルタの破棄
- 新しいクラスローダの生成
- リスナ、サーブレット、フィルタの再初期化
- 状態に関する情報のリストア
Aranea フレームワークのブログの中で書かれているとおり(source)、オブジェクトの状態のリロードはSerializableを実装したオブジェクトに限られており、シリアライズできないフィールドを持つことはできない。JBossは2つのクラスローダを使用してSeamとJava EE 5用に拡張を行った。クラスローダのひとつはSeamコンポーネント用の、もうひとつはEJB3/Hibernate等のためのものである。Seamコンポーネントや設定で何かが変更されると、Seamは全体を再配備する必要なしにリスタートされる。EJB/Hibernateコンポーネントの変更には、依然として全体の再配備が必要であるが、これはHibernateのメタモデルを動的にロードする方法が今のところ無いからである。JBoss Tools (サイト・英語)IDEのプロジェクトでは、これが開発者にとって可能な限りシームレスになることを目指している。シリアライゼーションの技術は、Rifeや Tapestry 5などのいろいろな他のフレームワークでも機能すべきである。
2つ目のアプローチは、JVMレベルのホットスワッピングである。Java SE 5では限定された形のホットスワッピングが導入され、クラスローダの削除や存在しているエンティティの破棄をすることなく、実行時にクラスを再定義する機能が提供されている。しかしながら、クラスの宣言されたフィールドやメソッドを変更することはできず、そのために実用性が限られている。現在、多数のベンダがこの状況を改善しようとしており、その中にはZeroTurnaroudやBEAが含まれている。
ZeroTurnaround は先ごろ、Java Rebel 1.0(サイト・英語)の最終リリースを発表した。このリリースでは、性能の向上やリフレクションのサポート、より手厚いJava 1.4のサポートといった、初版リリースへの多くの改善が見られる。サポートされているWebアプリケーションサーバも増えており、以下のサーバが含まれている。
- 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)
こちらで書かれているように(source)、カスタム・クラスローダを使用して、GlassfishやWebSphereなどといったサポートされていないアプリケーションサーバで動作するようにすることも可能かもしれない。リリース1.0では、まだアノテーションをサポートしていないが、1.1では予定されている。Java Rebelは商用ソフトウェアであり、開発者１人あたり149ドルかかる。無償の試用版の入手が可能である。
BEA ではFastSwapと呼ばれるChangeAwareClassLoaderの代わりとなるものを提供しており、性能や制限はJava Rebelと非常に似通っているが、当然ながらWebLogicサーバに限定されている。現在は、WebLogic 10.3のテクノロジー・プレビュー版(サイト・英語)で利用が可能になっており、詳細についてはこちら(PDF・英語)に書かれている。
Java のような静的型付け言語用のフル・ホットスワッピングは、いまだ活発に研究されているトピックであり、成し遂げることはできないかもしれない。しかしながら、JSR 292(サイト・英語)で行われている、Java 7で動的言語をサポートするための作業は、JVMがターゲットとしている動的言語のために状況を改善しようとしている。invokedynamicとフル・ホットスワッピングの組み合わせにより、PythonやRuby、Groovyといった言語の実装がJVMのオブジェクトモデルを直接使用できるようになることが期待される。これにより、これらの言語のJVM上での性能はかなり改善されるだろうし、Java言語自身のためのさらに先進的なホットスワッピングが次々と排出されるはずである。