众多技术正在探求向 JEE 中加入动态部署特性

使用动态型别解释型语言（如 PHP，Python 或 Ruby）的 Web 应用开发人员已经习惯于修改应用后刷新浏览器就可以看到最新结果。虽然 JSP 页面也 提供了这种特性，但是在 Java EE 的世界中，开发者每次想要测试一个变化时，通常还是要经历构建和部署的循环，极大的降低了开发效率。

很多厂商都正在探索如何改善 Java 所面临的处境，现在已经有两种技术得到了广泛应用。

第一种，也是得到了最佳完善的技术，利用了重新载入整个 ClassLoader。WebLogic 的 _ChangeAwareClassLoader_ 便用到了这种方式。它有两种实质上的局限。其一是所有的状态信息会全部丢失，需要重新创建。其二是，虽然这样做比完全的重新部署要快，但仍然会带来时间消耗，因为有不少步骤需要执行。在一个应用服务器环境中，这些步骤可能会包括：

1. 部署所有运行的 listeners（如 HTTPEvenListeners 等等），Servlets 和 Filters。
2. 创建一个新的 ClassLoader。
3. 重新初始化 listeners，Servlets 和 Filters。
4. 还原状态信息。

重新载入对象状态，这种做法基本上都限制于那些实现了 _Serializable_ 接口，并且不包含非序列化字段的对象，有一篇 blog 在 描述 Aranea 框架的背景时也谈到了这点。JBoss 针对 Seam 和 Java EE5 对此作了扩展，使用了两个 ClassLoaders，一个用于 Seam 组件，一个用于 EJB3/Hibernate 等等。当 Seam 组件或是配置发 生变化时，Seam 会被重启而无需完全重新部署。但由于目前还没有任何机制可以动态的载入 Hibernate 元模型，所以如果 EJB3/Hibernate 组件发生变化时，便需要全部重新部署。 JBoss Tools IDE 项目的目的便是让这一切尽可能的对开发人员透明。序列化机制同样可以应用于其他框架中，如 Rife 和 Tapestry 5。

第二种方式是 JVM 层次上的热交换（hotswapping）。Java SE 5 提供了一个有限形式的热交换，可以在运行时重新定义一个类，而不需要停掉它的 ClassLoader 或是抛弃现有的实体。不过类中声明的成员变量和方法 不能改变，从而限制了这种技术的可用性。有不少厂商也正在尝试使用这种技术，并试图加以改进，其中包括 ZeroTurnaroud 和 BEA。ZeroTurnaround 最近发布了 Java Rebel 1.0 的最终版，它在第一个公众发行版的基础上带来了很多改进，例如更佳的性能，对反射的支持和对 Java1.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（基于 Java 5 或更新版本）
• Jetty 5.x，6.x（基于 Java 5 或更新版本）

按照这篇博客中 的说法，开发者还可以用自定义的ClassLoader 来让尚未支持的应用服务器——如Glassfish 或WebSphere 来与JavaRebel 一 起工作。1.0 版也没有对注解提供支持，不过这已经列在了1.1 的计划中。JavaRebel 是一个商业软件，价格为每个开发者149 美元。此外还提供了 免费的试用版。

BEA 提供了名为 _FastSwap_ 的技术作为 _ChangeAwareClassLoader_ 的替代方案，它和 JavaRebel 有着非常相似的作用和局限性，而且它很明显只能在 WebLogic 服务器上使用。目前我们可以在 WebLogic 10.3 技术预览中看到它的身影，在这个PDF 文件中也有更详尽的描述。

在类似Java 这种静态型别语言中，完全的热交换还是非常吸引人的。人们正在对它进行深入探索，也许这会是一个永无止境的话题。不过，那些在 JSR 292 之下为 Java 7 提供动态语言支持的工作正在想方设法改善 JVM 平台上动态语言的处境。希望 _ 动态调用 _ 和完全热交换的合并，可以让 Python、Ruby 和 Groovy 这些语言的实现能够直接使用 JVM 对象模型。它会大幅度地提高这些语言在 JVM 上的性能，而后反过头来给 Java 语言自身带来更好的热交换。 查看英文原文： Multiple Techniques Seek to Bring Dynamic Deployment to JEE