用于重载类的各种Java插件之间有什么区别，哪个是最直观的？

Question

我目前正在尝试在Java应用程序中实现 热类重载 ，但是有太多的插件可供选择，我在这些选项之间找不到很好的 比较
。此外，插件的网站还不清楚其确切 功能 以及如何使用它们。

还有一个选项可以使 自定义的热门类重新加载ClassLoader ，但是如果已经有很多可以完成此工作的插件，我觉得这类似于 “重新发明轮子”
。其他人也同意吗？

我发现可以完成此任务的Java插件：

• 叛逆者
• 动态代码演化虚拟机（DCEVM）
• 假货
• Apache Commons Java编译器接口（JCI）FileAlterationMonitor（FAM）
• 史密斯
• 菲尼克斯
• 播放框架
• JBoss / WildFly
• OSGi

那么，有没有人碰巧知道插件之间的 区别 呢？还有哪个插件使用起来最 直观 ？

附带说明：我真正想做的是重新加载Java应用程序的.jar文件依赖项。我有一些Java代码，这些代码经常会自动重新编译，然后转换为.jar文件。这是我的Java应用程序的依赖项，我的应用程序每次都需要使用此.jar文件的最新版本。

Answer 1

免责声明： 我参与了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重新加载已编译的类。