美好的一天。在本文中，我将讨论我所工作的公司中诸如Java Web Start之类的工具的“现代化”，或更确切地说，是将其替换为替代的开源解决方案。关于我自己
我叫Ildar，我在一家德国公司工作，与许多德国公司一样，该公司使用旧技术堆栈并尝试迁移到新堆栈。问题
我将从问题的描述开始。我们公司是系统中最重要的部分，它是用Java 6编写的旧应用程序，部分是用Java 8编写的。它是在Java 8中启动的。要使用该应用程序进行生产，用户可以从站点下载jnlp文件并在自己的家中运行它在计算机上。因此，该公司幸福地存在了很长时间，直到甲骨文宣布停止支持Java版本8，将Java Web Start技术标记为已弃用，并决定从Java 11开始将其淘汰。这意味着还有更多的JWS应用程序，其中还有很多将不会收到包括安全更新在内的信息。当然，很少有人对此表示满意。也有来自Karakun的思想爱好者决定写出他们的JWS替代品。在我们公司中，前一段时间，他们开始使用Spring Boot作为后端以及React作为前端来重写应用程序，但是该过程并不快，并且现在没有更新。寻找解决方案
因此，开发团队面临着寻找替代解决方案的问题。总的来说，有必要认识到有不止一种解决方案。最初，架构师选择了两个GetDown解决方案和相同的OpenWebStart。在做出最初决定时，选择权就落在了第一个选项上，因为OpenWebStart甚至没有在第一个版本下发布（只有一些开发和计划）。每个解决方案都有其优点和缺点，但是该公司决定不等待OpenWebStart的发布，而是开始实施基于GetDown的概念证明。在花费了几周的时间之后，一位开发人员完成了这项任务，我们意识到，原则上，我们可以通过花费更多时间来实现一个满足我们要求的完整解决方案。同时，其他紧迫的任务也到达了，开发团队将精力从PoC阶段转移到Java Web Start替换的完全实施阶段。截止期限
每个人都过着幸福的生活，直到管理层意识到该结束并替换Java Web Start的时候了。直到现在，我还没有参与这个项目，但是在这里他们也使我联系在一起。首先，我决定再次寻找有关解决问题的信息。所以说从零开始进入解决方案。因此，我发现了OpenWebStart的存在。我在本地进行了测试，遇到了一些问题（然后我们也遇到了其他问题）并解决了它们。结果，每个人都喜欢该解决方案。不用说，管理层特别喜欢它，因为它不必像GetDown那样花时间在开发上。但是最后，我们花了一些时间使系统与OpenWebStart一起使用。关于OpenWebStart的快速信息
OpenWebStart基于Java Web Start的另一种实现-IcedTea -Web和JNLP规范JSR-56。在撰写本文时，该项目存在于1.1.4版本中，并计划实现Java Web Start的主要功能（可以在此处观察到进展）。我看不到列出所有可能的设置的意义，这可能需要很长时间。这里只是其中一些：- 缓存管理（大小，位置...），
- 安全设置（允许用户运行未使用证书签名的应用程序，而不显示警告弹出窗口...），
- 将服务器地址添加到白名单，
- 远程调试设置，
- 安全证书管理
- JRE / JDK版本控制，
- 其他
使用OpenWebStart的功能以及我们遇到的问题
安装OpenWebStart
安装OpenWebStart非常简单。在网站上下载适合您平台的安装文件并按照安装程序的说明就足够了。但这真是不幸。在我们的情况下，用户约为10,000个客户，对于每个客户我们公司的支持服务都必须安装此工具。解决方案很快找到：可以使用所谓的后台安装。您需要将安装文件上载到每台计算机并运行特殊命令（为此，该公司已拥有一个工具）：OpenWebStart_windows_Setup.exe -q -varfile response.varfile
，其中response.varfile是具有某些设置的文件，可以由安装程序预先设置。例如，用于安装OpenWebStart的文件夹以及其他一些文件夹。好吧，我们解决了这个问题。此外，所有客户端都必须以某种方式安装特定版本的AdoptOpenJDK并将其链接到OpenWebStart，这很容易通过用户界面完成，但这不是我们的情况。
我们在设置中发现可以指定URL，OpenWebStart将从该URL获取设置文件，在其中可以指定所需JRE的URL。带有设置文件的URL本身可以在上述的response.varfile中指定（这很复杂）。带有不同版本的JRE的JSON设置文件本身如下。在设置中，如果在JSON文件中指定了多个JRE，则还可以指定JRE的版本和供应商。我们仅指示了一个，并使用所需的JRE将JSON文件和存档上传到了Amazon S3存储桶。经过测试，我们发现使用所下载的JRE版本，该应用程序无法启动。事实证明，我们的Java在存档中的结构略有不同。我们整理了一个批处理脚本，该脚本重新构建了JRE存档的结构。“好了，现在一切都会很好，”我们认为。首次启动应用程序时，将自动加载JRE，以备将来使用。但是，我们正在等待下一个惊喜。不幸永远不会孤单
但是正如通常发生的那样，我们不仅限于一个问题。假设我们的应用程序具有一项功能。实际上有两个。一个应用程序（一个jnlp文件）启动另一个应用程序（第二个jnlp）。在这种情况下，第二个应用程序没有启动。在日志中，您可以看到应用程序陷入了死锁。从隐身痕迹中，可以清楚地看出原因是OpenWebStart内部日志记录机制。通过禁用OpenWebStart的内部日志记录解决了该问题。当然，我们的应用程序日志仍然保留。
这些设置也已在后台安装期间使用的response.varfile文件中关闭。而现在，在克服了这些和其他一些障碍（我不必再提所有人）之后，我们设法启动了我们的应用程序，该应用程序目前正在接受测试，然后再发布到产品中。经过测试，OpenWebStart的版本从1.1.1升级到1.1.4。其中的显着变化增加了远程首次亮相的功能。
也许我的文章对像支持旧版应用程序这样的艰巨工作的人很有用。如果您有任何疑问-询问，我会尽力回答。PS所有图像均来自OpenWebStart官方网站。