我感受到你的痛苦，我在JWS中遇到的最大问题是可见性，也就是说，它在做什么，为什么这样做。我们的大多数问题都与内部代理有关（Java似乎真的不喜欢验证代理），皱纹似乎暂时得到了解决。尽管如此，我确实考虑过简单地写一个替代品。这并不像听起来那么疯狂，JWS做了很多我并不真正关心的事情，即与Web浏览器集成并检查JVM版本。请考虑以下情形：
- 启动 Java 应用程序（启动应用程序）。此应用程序采用单个参数，该参数是 JNLP 文件的 URL。
- 启动应用对 URL 进行哈希处理，并将其用作本地文件夹（存储库）的基础，在该文件夹中存储应用的任何已下载 jar。如果存储库不存在，它将创建它。
- 启动应用尝试下载 URL 所指向的 JNLP。如果它无法下载它，它将只启动存储库中的任何内容（可能会警告用户）
- 如果它可以下载 JNLP，请对其进行解析并列出任何需要下载的 jar。如果您已经拥有jar，请使用Apache HttpClient之类的东西来确定服务器是否具有较新版本并在需要时下载。重要的一点是，任何下载都应存储在临时文件夹中。所有下载都成功后，您可以将这些下载应用到本地存储库。理想情况下，您将备份已经存在的内容，以便允许某种回滚过程。
与常规 JNLP 相比，这应该会提供一些非常显著的优势：
- 可见性，您可以准确记录正在发生的事情
- 更好的故障模式：如果下载被中断，只需启动已经存在的版本（显然，如果在第一次下载时发生干扰，这将不起作用），如果您想告诉用户，请这样做。
- 通过作为本地应用程序运行，您应该避免遇到jar签名问题，老实说，我不了解Java Web Start关于签名jar的安全模型，但似乎如果涉及不同的类加载器，JWS会抱怨它（我认为）
可悲的是，我无法因为上述工作版本而解雇你，我确实启动了一个原型，但暂停了它。我可能不得不在将来返回它，在这种情况下，我很乐意分享完成的版本。
干杯，菲尔
