java（运行时可执行文件）只能运行类文件。直到java 12，一个 * 普通 * 的JDK发行版（而不是像阿苏尔这样的一些打包商发布的奇怪的JRE ^1）有一个java.exe，它 * 可以 * 直接运行java文件。这很简单--当然，编译器仍然参与其中。只是java会为你执行它。
你不需要--source 12;只要java MySourceFile.java就可以了。编辑源文件顶部的注解，它应该是#!/usr/bin/java。您需要的是命令行PATH上的java是java v12或更高版本，而它不是。对于此问题，您的java源文件无能为力，你将不得不强迫你的用户至少安装java 12，否则它就不能工作了。apt或yum或snap或任何软件包管理器都会告诉您如何修复此问题：安装java 17，然后卸载其余的，或者使用java-alternatives或者任何你的软件包管理器设置默认可执行文件的机制（/usr/bin/java链接到的那个）。阅读提供java 17的软件包的文档，可能通过一些链接到通用的java基础设施软件包，它会告诉你。
大多数情况下，这是一个红鲱鱼，这只是不是java文件的分发方式。这实际上是没有意义的，因为：

1. Java不是一种倾向于用于快速shell脚本风格的语言。这种东西往往是自我实现的预言：因为没有人这样做，所以库的作者在开发API时不会考虑到这一点，而库的用户也不会为此提出增强请求。因为当用于快速的即兴shell脚本时，公共库并不方便，所以java并不用于此，从而使循环永久化。
   1.任何严肃的java应用程序都肯定会涉及包、依赖项等等--而这样的应用程序不能像这样运行。
   1.类文件和源文件一样是平台不可知的。没有理由将Java编写的shell脚本风格的工具作为源文件而不是jar来分发，* 除了 * 对它们进行即兴编辑，这让您回到第1点和第4点。
2. Java核心API在最小公分母模型上工作：如果有一个主要操作系统不能或不能以某种方式工作，那么java根本不公开这个。例如，在所有posix系统上（除了Windows之外，几乎所有主要的操作系统），你有你通常的TERM，KILL，HUP，Java核心库不允许与它们交互（除非你使用了隐藏的sun.misc.* API，它在一开始就不能可靠地工作）。这使得java extra不适合快速命令行脚本，你需要一个不同的模型：如果至少有一个操作系统可以做到这一点，那么该语言应该有一个库，如果你试图在一个不支持它的操作系统上使用它，这个库应该很快崩溃。一个简单的解决办法是使用第三方库，增加对特定操作系统的支持，但是你的分发模型（把#!/usr/bin/java放在顶部，分发一个源文件）不能包括依赖项。
3. Java作为一个运行时模型，主要关注于 * 最终 * 非常快速地运行东西，代价是 * 开始 * 缓慢。这对于需要高效运行但将运行相当长一段时间的Web服务器来说是极好的。但它完全不适合shell脚本。
   结论：即使你能让#!/usr/bin/java工作，你也不想把它粘在顶部。
   [1]JRE是一个没有编译器和其他开发工具（如jstack）的java发行版。显然，它们不能运行java SomeSourceFile.java;他们没有编译器。2但是，JRE已死亡-不再有JRE; JDK 8是最后一个附带官方JRE的版本。JRE作为一个分发模型：最终用户安装JRE，然后您将jar发送给他们。（你现在要负责获得一些可以在部署机器上运行你的类文件的东西），因此JRE死了。然而，一些OpenJDK构建的打包者，比如阿苏尔，仍然发布它们，这让事情变得混乱。因此，'bizarro'。Azul和co有相对好的理由这样做，但是，除非你真的知道你在做什么，否则你不应该使用这些。