用于热类重新加载的各种Java插件之间有什么不同，哪个是最直观的？

Question

目前，我正试图在应用程序中实现热类重载，但是有太多插件可供选择，我无法在这些选项之间找到一个很好的比较。而且，这些插件的网站并不都很清楚具体的功能是什么，以及如何使用它们。

也有一个选择，使一个定制的热类重新加载ClassLoader，但我觉得这类似于“重新发明车轮”，如果已经有这么多的插件可以完成这项工作。其他人是否同意这点？

我发现的Java插件(我认为它可以完成这项工作)：

• JRebel
• 动态代码进化虚拟机(DCEVM)
• Fakereplace
• (JCI) FileAlterationMonitor
• AgentSmith
• Feenix
• 播放框架
• JBoss/WildFly
• OSGi

那么，有没有人碰巧知道插件之间有什么区别呢？另外，哪个插件最直观？

顺便提一句:我实际上想做的是重新加载我的java应用程序的..jar文件依赖项。我有一些java代码，经常会自动重新编译，然后转换成..jar文件。它是我的java应用程序的依赖项，我的应用程序每次都需要使用这个..jar文件的最新版本。

Answer 1

免责声明：--我参与了JRebel开发，因此我的回答可能有点偏颇，但我会尽力解释。

为了回答这个问题，我首先想提请大家注意，您列出的名称中的一个主要区别是:一些解决方案要求您更改应用程序设计，而另一些解决方案则没有。

模块化解决方案，如OSGi或JBoss Modules，如果您遵循正确的路径并模块化应用程序，就会带来好处。否则，如果部署一个筒仓包，基本上意味着重新启动/重新部署整个应用程序，从而减少了从这种方法中获得的任何好处。

Play Framework实际上是一个具有热部署功能的全堆栈框架。这些功能根据您使用的框架的版本而有所不同。但是，同样地，与模块化相同的故事-框架执行一个特定的编程模型。

Apache 实际上不是热更新代码的解决方案。AFAIK，它只是通过新的类加载器编译和加载类。这还涉及更改应用程序代码，就像上面提到的情况一样。我不太确定它是好是坏。缺点是你很难以这种方式与生态系统进行任何广泛的整合。这种方法对于使用此特性的自制框架来说是相当可行的。我自己更愿意使用类似Groovy、JRuby或JavaScript这样的脚本语言来实现同样的目标。例如，类似于这。

JRebel、Fakereplace和DCEVM --这些家伙不关心编程模型。但两者之间的差别是相当大的：

DCEVM对JVM进行了修补，其目标是提供一个完整的hotswap解决方案。

JRebel是一个java代理(与-javaagent VM参数挂钩)，它通过对类进行版本控制来检测应用程序代码并加载它们的新版本。JRebel的主要价值在于它提供了灵活的配置以及一个大量的框架特定集成，因此您可以做的不仅仅是一堆java类。例如，在Spring应用程序上下文中添加和自动创建新bean，动态添加新的EJB，以及新的Struts操作等等。

Fakereplace也是一种工具代理，就像JRebel一样，但是它对Java代码更改的支持要少得多(我认为)，而且支持的框架的数量也没有那么多。

Java可以在允许的范围内完成更多的任务。这基本上意味着它在JVM的标准HotSwap之上并没有真正增加价值。AgentSmith也是如此

更新:这个答案促使Feenix的作者提出了一个新的版本--Feenix2.0，类似于JRebel处理类的方式。但正如作者自己所言，菲尼克斯仍远不如JRebel。还有几种类似的解决方案，比如HotswapAgent和Spring加载的--这些工具也提供类似的功能，但以自己的方式受到限制。

现在有点关于您的具体问题，如何用JRebel解决这个问题：

应用程序的每个模块都应该有自己的配置文件rebel.xml。对于模块，我们指的是WEB/lib中的EAR、WAR或任何JAR依赖项(如您的例子)或特定于服务器的库。指向编译类所在的目录的配置文件和JRebel将直接从该位置加载类。这都意味着，一旦对类进行了更改，就不需要组装整个JAR了。而不是，您可以进行更改并编译源代码(利用IDE，而不是构建脚本)。一旦在应用程序代码中调用该类，JRebel将重新加载已编译的类。

Answer 2

在这个块上有一个新的孩子，RelProxy，它是开源的，不像JRebel那么高级，但是它可以用来在运行时自由地更改代码的子集，并且在开发和生产中不需要重新加载上下文(如果您愿意的话)，几乎不需要性能损失。