Question

有存在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源/目标项目时是否存在任何实际差异。

Answer 1

这样做的主要原因可能是较新的JDK的编译器中有一些更好的优化。因此，即使目标字节码 level 与旧的编译器相同，目标字节码本身也可能会得到改善。

According to Brian Goetz，这可以减轻重量：

有时候，通过JVM的改进，可以实现从源代码到字节码的更好转换。例如，在5之前，Foo.class被转换为反射调用；之后，去最不发达国家。

因此，您可能合理地希望在组织中坚持给定的语言级别（由于共享代码），但是特定的应用程序仍可以利用VM改进的优势。

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

PS。根据{{3}}的建议，我要提到JDK 9+的Basil，它会在坚持较旧的语言级别的同时，阻止使用更新的JDK的API。

Answer 2

一点也不。 Source 主要是关于语法的。 Target 是关于特定字节码魔术数字和功能的信息。

但是您可以很好地编写Java 7兼容代码，该代码使用仅jdk 8或更高版本提供的单个类X。然后，当您使用Java JDK 8，即编译器会发现，X类和构建精细。但在Java 7 JVM运行代码时，在Java 8级X丢失，从而导致运行时异常。

所以：迫使JDK阻止您使用您的目标版本后添加到Java的类。

Answer 3

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

可以说您在一家公司中有数千台维护机器，而您不能在每台计算机上都安装Java的每个版本。同样，安全性通常不允许下载（通常根本没有直接的互联网访问权限），并且关于安全性需要维护每个可用的Java版本-涉及大量的书面工作和讨论（例如安全性）。

Botomline是：在企业中，可用的Java版本非常有限，通常没有最新的优势。

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

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