甲骨文的观点：

• 不再有JRE（来源：尝试找到oracle提供的版本8以上的JRE-它不存在）。
• 相反，你用模块编写你的应用程序，并使用jlink工具来制作一个“树摇动”JVM，这是一个JVM，包含了所有你用作基础的模块甚至不需要的东西。你为每个平台制作一个JVM，你有兴趣导出为独立的安装程序。
• 然后你编写一个安装程序，在某个地方安装树抖动JVM，和 * 你的应用。树抖动JVM没有**注册为“系统JVM”，事实上，在PC上安装了JVM，你可以使用注册表键或通过查找C:\Program Files\JavaSoft等已知位置找到它的概念已经过时。你不这样做，JVM只适用于该应用。那个应用程序知道在哪里可以找到它，而系统上的其他任何东西都不知道。每个基于Java的应用程序都有自己的JVM副本（树摇动与否），只有它自己使用。
• 作为“供应商”，你要承担维护的责任。如果你提供的JVM有一个巨大的安全漏洞，并且被滥用，那就是你没有更新它的错，而不是甲骨文的错。甲骨文没有运行jusched.exe或任何其他工具来确保它保持最新。

一个简单的替代方案是，你只需将拥有一个可以运行你的应用程序的java运行时的责任转移到用户的肩上。（因为JDK可以运行Java应用程序，实际上比JRE更好），告诉他们确保它在$PATH上或在已知位置/告诉您在哪里可以找到它/设置JAVA_HOME，并且 * 他们 * 负责保持它最新。
其他供应商的观点：

• 很多其他厂商也为更现代的版本提供了JRE。我不知道这些JRE是否附带jusched.exe或其他更新机制，以及这些JRE如何（甚至 * 如果 *）注册它们的存在，以便您的应用/安装程序可以确定它们的位置。您必须进行调查。

您不需要对JVM进行树型改造，您也可以随应用提供一个完整的JDK。例如，如果您的安装程序最终执行以下操作：

• 将“程序安装根目录”（“根目录”）设置为C:\Program Files\EmilysAwesomeGame
• 将适用于Windows x64的JDK 17解压缩为ROOT\jdk。
• 将所有依赖关系jar解包到ROOT\lib中。
• 将您的主应用解包到ROOT\emilygame.jar中
• 创建一个运行%~dp0\jdk\home\bin\java -jar %~dp0\emilygame.jar的.BAT文件，并且该jar具有一个MANIFEST，其中Class-Path条目包含例如lib\javafx.jar lib\someotherdep.jar，然后..这将工作得很好，并且将该bat文件替换为执行相同操作的exe也工作得很好（并且“在子目录中运送您自己的JVM”是像launch 4j和类似工具已经支持很长时间的模型）。

不使用树型结构的缺点是JDK太大了，包含了各种各样你不会用到的东西。但是，这只是节省磁盘空间的问题，一个不使用树型结构的JDK不会运行得更慢，那些不用的部分最终将永远不会被加载。
一个非常常见的“部署模型”是，你为windows-x86提供一个带有exe的msi，告诉其他人自己负责安装JDK，并为其他人（linux用户、mac用户、windows-aarch 64等）提供普通的jar。

这个问题被问了一遍又一遍。因此，有一个广泛的讨论这个主题在这里的SO。见：https://stackoverflow.com/tags/javafx/info与您最相关的部分是关于“ Package ”的部分。