是否有实际的理由来执行JDK版本的构建？

Question

存在可以强制构建仅在特定JDK版本上运行的maven强制执行器插件。

我想知道有没有什么实际的理由？我们已经构建了配置来指定源和目标版本。据我所知，这已经足够了，因为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。问题更多的是，编译版本8的java源/目标项目和JDK的8、9、10或11是否有任何实际差异。。。

Answer 1

有很多原因。我要指出的一点是在企业环境中部署。

假设你在一家公司里有数千台维护的机器，你不可能在每台计算机上安装每一个java版本。此外，安全性通常不允许下载（通常根本不允许直接访问互联网），每一个可用的Java版本都需要维护安全性，需要进行大量的书面工作和讨论（例如安全性）。

Botomline是：在企业中，可用的Java版本集非常有限，通常不是最先进的。

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

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

Answer 2

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

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

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

Answer 3

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

据Brian Goetz称，这起到了重要作用：

有时，JVM的改进可以更好地将源代码转换为字节码。例如，在5之前，Foo。类被转换为反射调用；之后，提交给LDC。

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

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

注意：正如Basil所建议的那样，让我提及JDK 9的javac-release标志，它阻止使用较新JDK的API，同时保持较旧的语言级别。