JRE这个概念已经过时了- JRE1.8是最后一个。许多供应商（如阿苏尔）都为更新的版本开发了JRE，但它不再是一个受支持的部署平台。
因此，难怪你的最终用户安装了它。JRE1.8是不再支持和非常老，当然太老了，以运行你编译，你编译了最新的Java版本。
例如，您可以让java生成与javac --release 8 *.java兼容的JDK 8代码（或者查看您的构建工具文档，了解如何告诉它添加此参数），但这意味着您不能使用此后引入的任何API（而且已经引入了很多），也没有从那时起引入任何Java语言特性（所以，没有X1 M1 N1 X，没有X1 M2 N1 X，没有X1 M3 N1 X字符串，等等）。

但是，您的部署模型已过时！

您的部署模型是：

• 你，最终用户，安排一个JRE的存在。我所能做的就是告诉你去某个地方下载一个。
• 我会寄给你一个jar文件。
• 双击它。

这种模式不再推荐或可用。现在找到JRE相当困难，期望用户拥有它是不合理的。最好的情况是，您可以提供大量的文档，说明他们可以在哪里获得JRE（不再是openjdk.org或java.com！）
这是有原因的：它真的从来没有工作得很好，甲骨文/团队OpenJDK的选择，以摆脱JRE与JDK的分布模式，也许更多的是他们刚刚醒来，并意识到如何在现实世界中一直在部署Java应用程序，而不是他们试图惹恼你改变事情的工作方式。
新的模式包括你将java运行时与你的应用程序一起交付，你负责维护它。
有很多教程介绍如何使用jlink，jlink是其中一个关键部分（所以请在搜索中包含它）。或者，这也不是特别困难，因为这在10年前JRE部署模型还很流行的时候就已经很流行了：你可以把整个JDK和你的jar一起发布，然后做一个简单的安装程序，像launch4j这样的东西可以让你的用户真实的容易地启动它（只需点击EXE）。
简单地说，JRE部署模型的问题是：

• 您的最终用户将与oracle“签订合同”以下载JRE，并将其安装在他们的系统上，oracle+用户将一起工作以使其保持最新。如果未能做到这一点（例如，用户从他们的系统启动文件夹中获取jusched.exe），则意味着oracle会因为JRE可能不安全（由于未更新）而受到攻击。
• 作为应用程序供应商，你所能做的就是告诉用户他们需要先访问oracle.comjava.com或诸如此类的网站。
• 你不能真实的保证他们的JRE是兼容的。Java基本上是向后兼容的，但很容易发生这样的情况，比如说，你的应用程序不能在java 10上运行，但它可以在java8上运行。如果有人安装了JRE 10，那么你的应用程序“运行”和崩溃。在JRE 8，9，10，11，12，13，14，15，16，17，18上测试你的应用程序是非常困难的。19个，所以人们没有这样做，这导致了应用程序一直失败。
• 因为它是一个系统，所以JRE需要声明它所在的位置，并将自己注册为运行任何.jar文件的对象，这使得安全情况变得相当棘手。

与新模型（由于上面列出的旧模型的问题，在它成为官方模型 * 之前 *，许多人已经使用了这个模型）形成对比：

• 您可以精确地部署所需的JDK/JRE，并使用进行测试。
• 无需通知用户需要访问java.com
• 此JDK/JRE不需要向系统通告其自身。
• 不太需要不断更新;考虑到它不会自行注册以运行.jar文件，也不会参与执行除您的应用之外的任何内容，并且大多数JDK安全问题无法被利用，除非应用“参与其中”/可以在应用端修复。
• • 它与intellij和eclipse等主要Java应用程序已经在做的事情相匹配 *。

这种新模式的缺点是编写安装程序要花很多精力。JRE的一个优点是它们的大小更小，可以用jlink复制，jlink可以制作一个树形抖动JDK（一个JDK，其中包含了特定应用不需要的所有部分）。