将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在路径中（更重要的是，如果没有，我们的用户可能不知道如何添加它），还有哪些替代方案？

- Jeff Storey

---

你可以提供两个版本的应用程序吗？一个带有JRE捆绑包，另一个没有，让用户决定下载哪一个？ - Ivan

@Ivan 那肯定是一种可能性。 - Jeff Storey

考虑到用户可能没有安装系统范围的JRE，我们可以设置一个安装逻辑，如果缺少系统范围的JRE，则捆绑JRE，并提供选择32位和64位JRE的选项。如果存在系统范围的JRE，则可以使用本地应用程序JRE以避免替换系统范围的JRE。 - ecle

如果从JRE中删除不必要的内容，它可以缩小到10MB大小，这并不算是“大得多”。证明 - Display Name

Answer 1

1. Java Web Start。JRE将在路径上。
2. 有关版本控制，请参见Java Web Start - Runtime Versioning，特别是Earlier Version。
3. JWS可以在64位和32位JRE之间分配资源。

因此，“捆绑JRE是个坏主意”。改用Web Start。

- Andrew Thompson

---

在这种情况下，用户有时也没有互联网连接。他们会得到一张带有应用程序的光盘。 - Jeff Storey

好的，说得有道理。我对网站没有太多经验。但是如果他们的计算机上没有安装Java，那么JavaWebstart真的对我有用吗？ - Jeff Storey

那么，接下来你需要使用 deployJava.js，这是一个可能会自动下载的文件（可能来自公司服务器），需要点击几下才能完成。 - Andrew Thompson

然而，同样的问题是并非总是有网络。如果Java不存在，他们可以让IT人员来安装，但不能自己下载并安装。 - Jeff Storey

我的意思是可以从CD上的WebStart链接安装它，然后将应用程序作为WebStart应用程序安装，包括deployJava.js等内容（如果需要）。无论哪种情况...我认为WebStart是一个很好的选择，但大多数人都误解了它...其他选项是软件包管理器和安装程序，它们只是一种不同类型的痛苦...这是OP的选择;-)...在任何情况下...不要捆绑jre IMHO。 - Manfred Moser

Answer 2

我建议不要捆绑JRE虽然我经常看到它是一种普遍的做法。

相反，我会使用Webstart（也可以离线使用）或其他安装程序或包管理器解决方案，以确保Java已安装并包含正确的版本。 这将广泛取决于您期望运行的操作系统。

选择包含Java的方式将引发一个问题，您想包含什么其他内容，以确保...这将使您需要考虑整个操作系统和所有需要考虑的事情。

我还建议仔细研究将安装该应用程序的用户类型，并根据此进行适应，并估计他们的能力。

- Manfred Moser