免责声明： 我参与了JRebel开发，因此我的回答可能看起来有些偏颇，但是我会尽力解释。
为了回答这个问题，我首先要引起您的注意，您列出的名称之间的主要区别是：有些解决方案需要您更改应用程序设计，而其他不需要。
模块化解决方案，如 OSGi的 或 JBoss的模块 提供的好处，如果你按照正确的道路和 模块化
应用程序。否则，如果部署一个孤岛捆绑包，则基本上意味着您要重新启动/重新部署整个应用程序，从而削弱了从这种方法中获得的任何好处。
Play框架 实际上是具有热部署功能的全栈框架。这些功能取决于您使用的框架版本。但是同样，与模块化相同的故事-框架强制执行某种编程模型。
Apache Commons JCI
并不是真正热更新代码的解决方案。AFAIK，它只是通过新的类加载器来编译和加载类。如上面提到的情况，这还涉及更改应用程序代码。我不确定这是好是坏。缺点是您几乎无法通过这种方式与生态系统进行任何广泛的集成。对于使用此功能的自制框架，此方法相当可行。就我自己而言，我宁愿使用Groovy，JRuby或Javascript之类的脚本语言来实现相同的目的。例如，类似这样的东西。
JRebel ， Fakereplace 和 DCEVM- 那些家伙不在乎编程模型。但是差异很大：
DCEVM 对JVM进行了修补，其目标是提供一个完整的热交换解决方案。
JRebel 是一个Java代理（与-javaagent
VM参数挂钩），它检测应用程序代码并通过对类的新版本进行加载。JRebel的主要价值在于它提供了灵活的配置以及大量特定于框架的集成，因此您不仅可以完成Java类的热交换，还可以做更多的事情。例如，在Spring应用程序上下文中添加和自动装配新bean，动态添加新的EJB，以及新的Struts操作，等等。
Fakereplace 也是插桩剂，如 JRebel的
，但它对于Java代码的变化少了很多的支持（我认为），并支持框架的数量是不一样令人印象深刻。
Feenix* 可以完成Java Instrumentation
API所允许的所有工作。这基本上意味着它并没有真正在JVM的标准HotSwap之上增加价值。与 AgentSmith 相同 *
更新：这个答案促使Feenix的作者提出了一个新版本 -Feenix 2.0 ，它类似于JRebel与类一起工作的方式。但是正如作者自己说的那样-
Feenix仍然远不及JRebel。还有一些类似的解决方案，例如 HotswapAgent 和 Spring Loaded-
这些工具也提供了类似的功能，但受其自身方式的限制。
现在介绍您的特定问题 ，如何使用JRebel解决：
应用程序的每个模块都应具有自己的配置文件rebel.xml。对于模块，我们的意思是EAR，WAR或WEB-
INF /
lib中的任何JAR依赖项（如您的情况）或服务器特定的库。指向已编译类所在目录的配置文件，JRebel将直接从该位置加载类。这一切都意味着，一旦对Java类进行了更改，
就 无需组装整个JAR。 相反
，您可以进行更改并编译源代码（利用IDE而不是构建脚本）。在应用程序代码中调用该类后，将由JRebel重新加载已编译的类。
