打包/发布 Java 17 应用程序的标准方法是什么？

Question

我有一个公开可用的 Java 8 桌面应用程序，其中包含 MSI 安装程序，我想将其更新到 Java 17。

目前的用户体验是这样的：

1. 用户下载 MSI 安装程序并运行它
2. MSI 安装程序会检查兼容的 Java 8 VM，如果不存在，则会提示用户从http://java.com安装一个。
3. 用户启动application.exe这是一个基本上运行的垫片java jar application.jar。

我很难理解的是用户应该在 Java 9+ 世界中安装什么。例如，如果我将用户发送到： https: //www.oracle.com/java/technologies/downloads/，他们会收到下载 Java 开发工具包的欢迎，这对用户来说安装起来是一件令人困惑的事情（“这是对的吗？我不想开发东西？？”）。

此外，当你登陆http://java.com时，它会说“如果你被要求下载 java，很可能就是这个”，这意味着如果你发布应用程序，你应该使用 Java 8（并且忘记 JavaFX 灾难）是 OpenJDK 11 之前的版本，并且只需使用 Orcale Java）...

我的印象是，在 Java 9 之后，Jigsaw 的承诺是构建一个包含本机运行时和 jar 的包，所有这些都整齐地捆绑在一起，以便最终用户必须安装 JVM 的日子结束了。然而在网上搜索，我发现 Gradle 或 IntelliJ（或 Eclipse）不支持这一点，所以这看起来有点像一个死的白日梦？

如果我想发布 Java 17 应用程序，用户是否需要安装 JDK？如果没有，我该如何打包和运送我的申请？

Answer 1

甲骨文的观点：

• 不再有 JRE（来源：尝试查找 Oracle 为您提供的高于版本 8 的 JRE - 它不存在）。
• 相反，您使用模块编写应用程序，并使用jlink工具创建一个“摇树”JVM，这是一个JVM，其中包含您用作基础的模块甚至不需要的所有内容。您可以为每个有兴趣作为独立安装程序导出的平台生成一个 JVM。
• 然后，您编写一个安装程序，在某个地方安装 tree-shaken JVM和您的应用程序。Tree Shaken JVM 没有注册为“系统 JVM”，事实上，PC 上安装了 JVM 并且您可以使用注册表项或通过查找已知位置等方式找到它的观念已经C:\Program Files\JavaSoft过时了。你不需要这样做，JVM 仅适用于该应用程序，该应用程序知道在哪里可以找到它，而系统上的其他任何东西都不知道。每个基于 Java 的应用程序都有自己的 JVM 副本（无论是否经过 Tree Shaking），仅供其使用。
• 作为“供应商”，您需要承担维护责任。如果您发布的 JVM 存在严重的安全漏洞并被滥用，那么这是您没有更新它的错，而不是 Oracle 的错。Oracle 不会运行jusched.exe任何其他工具来确保其保持最新。

一个简单的替代方法是，您只需将拥有可以运行应用程序的 java 运行时的责任转移到用户的肩上即可。告诉他们去下载JDK（因为 JDK 也可以运行 Java 应用程序，实际上比 JRE 更好），告诉他们确保它位于$PATH或在已知位置/告诉你在哪里可以找到它/设置JAVA_HOME，他们有责任保持最新状态。

其他厂商的观点：

• 许多其他供应商确实为更现代的版本制作了 JRE。我不知道这些 JRE 是否附带jusched.exe或其他更新机制，以及这些 JRE 如何（甚至是否）以您的应用程序/安装程序可以找出它们所在位置的方式注册它们的存在。你必须调查一下。

无需真正对 JVM 进行 Treeshake，您也可以仅随应用程序提供完整的 JDK。例如，如果您的安装程序最终执行以下操作：

• 将“程序安装根”（“root”）设置为C:\Program Files\EmilysAwesomeGame
• 将适用于 Windows x64 的 JDK17 解压为ROOT\jdk.
• 将所有依赖项 jar 解压到ROOT\lib.
• 将您的主应用程序解压到ROOT\emilygame.jar
• 制作一个.BAT运行的文件%~dp0\jdk\home\bin\java -jar %~dp0\emilygame.jar，该 jar 有一个 MANIFEST ，Class-Path其中包含一个条目，例如lib\javafx.jar lib\someotherdep.jar, then.. 这会工作得很好，并且用执行相同操作的 exe 替换该 bat 文件也可以正常工作（并且“将您自己的 JVM 发布在a subdir' 是像 launch4j 和类似工具已经支持很长时间的模型）。

不进行 treeshaking 的缺点是 JDK 相当大，并且包含各种您不会使用的东西。但是，这只是节省磁盘空间的问题，非 treeshaken JDK 的运行速度不会变慢，那些未使用的部分最终将永远不会被加载。

一个非常常见的“部署模型”是，您提供一个带有 windows-x86 的 exe 的 msi，并告诉其他人自行安装 JDK，并为其他人（linux 用户、mac 用户、windows-aarch64 ， ETC）。