将JRE与应用程序捆绑在一起？

Question

我一直在讨论是否将JRE与我的应用程序捆绑在一起。我已经在下面列出了一些原因，为什么我认为它会有用，但我也犹豫不决，因为它使应用程序更大。

为什么我认为它会有用：

1. 现在，通过运行批处理文件来运行应用程序（嗯，批处理文件的快捷方式，它通过批处理文件运行）。它只调用java -jar XXX，这需要Java在路径中，但情况并非总是如此。

2. 我们是一个小团队，并没有完全在Java 7上运行（我们正在尝试调试一些奇怪的错误）。如果用户使用Java 7，他们可能会遇到令人不快的软件体验 - 这对我们不利。打包特定版本的JRE确保我们对其进行了全面测试。

3. 我们支持32位和64位Windows平台。当用户下载软件时，他们选择32位或64位，但这是在询问他们使用的是哪个版本的Java。大多数用户不知道他们的64位平台上是否安装了32位Java，即使他们的操作系统是64位，下载32位也会让人感到困惑。

有一些很好的理由可以不打包它：

1. 如果Java中存在安全漏洞或者对JRE进行了其他重要更新，我们需要使用新的Java版本分发新版本的应用程序。我们通常每两周更新一次我们的应用程序，所以我现在不太关心这个。

2. 该应用程序现在会更大，因为它包含一个打包的JRE。

是否有人可以提供一些指导（根据这些要求）是否认为打包JRE是个好主意？如果没有，那么只是希望java在路径中有什么替代方案（更重要的是，如果不是这样，我们的用户可能不知道如何添加它）。

Answer 1

1. Java Web Start。 JRE将走上正轨。
2. 有关版本控制，请参阅Java Web Start - Runtime Versioning＆amp;特别是Earlier Version。
3. JWS可以在64位和16位之间划分资源。 32位JRE。

所以，'捆绑JRE的坏主意'。请改用web-start。

Answer 2

我建议不要捆绑JRE，尽管我经常将其视为常见做法。

相反，我要么使用webstart（也可以脱机使用）或其他安装程序或pacakge管理器解决方案，以确保安装Java，包括正确的版本。这将在很大程度上取决于您希望运行的操作系统。

沿着包含Java的方式提出问题还有一个问题，那就是为了确保...这将引导您进入整个操作系统以及最终所需的一切。

我还建议仔细研究一下哪些类型的用户会安装该应用并对其进行调整，然后根据它们的具备能力做出某种估计。