存在maven enforcer plugin可以强制构建将只在特定的JDK版本上运行。
我不知道是否有任何实际的理由有这样的？我们已经建立的配置来指定源和目标版本。据我了解，这应该是绰绰有余，因为Java是向后兼容的。例如如何在外观的gradle：
compileJava {
sourceCompatibility = '1.8'
targetCompatibility = '1.8'
}
这就是它的外观在行家：
<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 ...
造成这种情况的主要原因可能是较新的JDK的编译器的一些更好的优化。因此，即使目标字节码级别是一样的与旧的编译器，目标字节码本身可能得到改善。
According to Brian Goetz，这个拉它的重量：
有些时候从源代码到字节码更好的翻译是由JVM改进成为可能倍。例如，前5，
Foo.class被翻译到反射呼叫;之后，最不发达国家。所以，你可以合理地要坚持给定的语言水平跨越组织（因为共享代码），但是特定的应用程序仍然可以采取的VM改进的优势。
编辑：对不起！带引号的鸣叫即将与源比目标低（例如-source 8 -target 11）编译，所以这是什么OP询问不同。然而，甚至当目标保持不变较新的编译器可以产生更好的字节码。
PS。诚如通过Basil，让我提JDK 9+，而坚持旧的语言水平，从使用较新的JDK的API阻止的javac --release flag。
一点也不。资料来源主要是关于语法。目标是对特定的字节码的幻数和能力。
但是，你很可能编写代码，使用一个类X只有JDK 8或更高版本提供了Java 7相容代码。然后，当您使用Java JDK 8，即编译器会发现，X类和建立的罚款。但在Java 7 JVM运行的代码时，在Java 8类X丢失，导致运行时异常。
所以：迫使JDK阻止您使用您的目标版本后添加到Java的类。
那么有多种原因。在一个我想指出的是在企业环境中部署。
比方说，你有成千上万的公司运行维护的机器，你就不能在每台计算机上安装Java的每一个版本。另外安全性通常不允许下载（往往没有直接的互联网接入的话）和每一个Java版本的安全性方面要保持现有的需求 - 用大量的文书工作和讨论的（例如安全）。
Botomline是：在一个企业，你有一组可用的Java版本的非常有限的，往往不是最前沿。
现在，让我们说可用的版本就是Java 8.现在，如果你想在aplication在你必须确保环境中运行，它实际上可用的版本（如Java 8）运行。如果将使用不可用的东西在该版本中，它只是不能运行或崩溃。从本质上说这样的应用仅仅是在企业中无法使用。这意味着企业会寻找不同的解决方案，他们可以在自己的环境中实际使用。
所以能够告诉编译器目标版本有很大帮助，创建一个能够而且将会实际使用（和用户的机器上没有崩溃）的应用程序。