Play Framework (2.4)、sbt (0.13.17) 的热重载以及整个项目被完全重新编译的原因答案

【问题标题】：Hot reloading of Play Framework (2.4), sbt (0.13.17) and reason for complete project being entirely recompiledPlay Framework (2.4)、sbt (0.13.17) 的热重载以及整个项目被完全重新编译的原因
【发布时间】：2019-05-29 10:07:31
【问题描述】：

我的 Web 应用程序项目及其内部依赖项目前似乎有问题：如果我修改某些类的公共非静态 Java 方法的 body，我的整个项目都会重新编译。这太浪费我的时间了，我该如何调试并修复它？

如果可能的话，我希望 sbt 告诉我增量编译依赖树（即：修改“myMethod”触发重新编译类 A1 和 B1，重新编译 A 触发重新编译 A2，重新编译 B1 触发重新编译 B2，等等。这可能会给我一些线索。这甚至存在吗？

【问题讨论】：

Play 框架在更改/修改代码导致重新编译时没有任何问题。这基本上是 Play 框架的一个功能，称为“热重载”。
但是为什么需要重新编译整个项目（所有 Java 和 scala 源代码），这需要很长时间？这真的是预期的行为吗？
请看看这是否回答了您的问题

标签： java scala playframework sbt

【解决方案1】：

当更改/修改代码导致重新编译时，Play 框架没有任何问题。这基本上是 Play 框架的一个功能，称为“热重载”。

现在进入问题的第二部分，您需要了解玩热重装的工作原理

假设您的播放服务器正在运行并且您进行了代码更改。然后按照以下步骤进行

它会编译您的类文件并检查任何编译问题。
然后编译剩余代码以检查新代码更改是否破坏了代码的任何其他部分。
如果有任何编译问题，都会抛出异常。
假设编译成功，我们需要更新JVM中加载的类。为此，我们只需删除旧的应用程序类加载器，并使用更新的类创建一个新的类加载器。
Play 应用程序已重新启动。

总而言之，play 框架丢弃了旧的类加载器并使用更新的类创建了一个新的类，因此重新编译了完整的项目。

希望能回答你的问题！！！

【讨论】：

这个答案指出了一些关于热重载工作原理的有用信息，但忽略了我怀疑有问题的原因：二进制兼容性。 Afaik，修改方法的主体不会改变二进制兼容性，因此使用我更改的类的文件不需要重新编译。