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

【问题标题】：Is there practical reasoning to enforce JDK version for build?是否有实际理由强制执行 JDK 版本进行构建？
【发布时间】：2019-06-27 01:09:16
【问题描述】：

存在 maven enforcer plugin 可以强制构建仅在特定 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 源/目标项目是否有任何实际区别......

【问题讨论】：

【解决方案1】：

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

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

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

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

PS。正如Basil 所建议的那样，让我提一下JDK 9+ 的javac --release flag，它阻止了在坚持旧语言级别的同时使用较新JDK 的API。

【讨论】：

【解决方案2】：

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

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

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

【讨论】：

【解决方案3】：

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

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

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

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

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

【讨论】：