是否有实际理由强制执行 JDK 版本进行构建？

Question

存在maven enforcer 插件，它可以强制构建仅在特定 JDK 版本上运行。我想知道是否有任何实际的理由可以做到这一点？我们已经构建配置来指定源和目标版本。据我了解，这应该绰绰有余，因为Java是向后兼容的。例如它在 gradle 中的外观：compileJava   {  sourceCompatibility = '1.8'  targetCompatibility = '1.8'}这就是它在maven中的样子：  <properties>    <maven.compiler.source>1.8</maven.compiler.source>    <maven.compiler.target>1.8</maven.compiler.target>  </properties>如果您发现任何需要确切 jdk 版本的理由 - 请您也将其写下来。UPD。问题更多是关于使用 JDK 8、9、10 或 11 编译版本 8 的 java 源/目标项目是否有任何实际区别......

Answer 1

造成这种情况的主要原因可能是在较新的 JDK 的编译器中进行了一些更好的优化。因此，即使目标字节码级别与旧编译器相同，目标字节码本身也可能会得到改进。

根据 Brian Goetz的说法，这很重要：

有时，通过 JVM 改进可以更好地从源代码转换为字节码。比如5之前，Foo.class被翻译成反射调用；之后，去LDC。

因此，您可能有理由希望在整个组织中坚持使用给定的语言级别（因为共享代码），但特定应用程序仍然可以利用 VM 改进。

---

编辑：对不起！引用的推文是关于使用低于目标（例如）的源进行编译-source 8 -target 11，因此它与 OP 询问的内容不同。尽管如此，即使目标保持不变，也许更新的编译器也可以生成更好的字节码。

---

PS。根据Basil的建议，让我提一下 JDK 9+ 的javac--release标志，它可以防止在坚持旧语言级别的同时使用较新 JDK 的 API。

Answer 2

一点也不。来源主要是关于语法。目标是关于特定的字节码幻数和功能。

但是您可以很好地编写符合 Java 7 的代码，使用只有 jdk 8 或更新版本提供的单个 X 类。然后，当您使用 Java 8 jdk 时，该编译器将找到该类 X 并构建良好。但是在 Java 7 jvm 上运行该代码时，Java 8 类 X 丢失，导致运行时异常。

所以：强制 jdk 会阻止您使用在目标版本之后添加到 Java 的类。

Answer 3

那么有多种原因。我要指出的是在企业环境中部署。

假设您在公司中运行着数千台维护的机器，您只是无法在每台计算机上安装每个版本的 java。此外，安全性通常不允许下载（通常根本无法直接访问 Internet），并且每个可用的 Java 版本都需要在安全性方面进行维护 - 需要大量文书工作和讨论（例如安全性）。

底线是：在企业中，可用的 Java 版本非常有限，而且通常不是最前沿的。

现在，假设可用版本是 Java 8。现在，如果您希望应用程序在您必须确保的环境中运行，它实际上在可用版本上运行（如 Java 8）。如果它使用该版本中不可用的东西，它就不会运行或崩溃。本质上，这样的应用程序根本无法在企业中使用。这意味着企业会寻找不同的解决方案，他们可以在他们的环境中实际使用。

因此，能够告诉编译器目标版本有助于创建一个可以并且将实际使用的应用程序（并且不会在用户机器上崩溃）。