我最近使用了一个 Java Web Start 应用程序。我使用我正在查看的页面中的嵌入式 jnlp 链接从我的网络浏览器启动它。该应用程序已下载、启动并运行良好。它可以访问我的本地文件系统并记住我在重新启动它之间的偏好。
我想知道的是为什么 Java Web Start 应用程序对于 web 上的复杂应用程序不是更流行的交付格式？当使用 Java 和 Java Web Start 可以更轻松地交付桌面应用程序的功能时，为什么开发人员经常花费大量时间和精力在 html/javascript 中复制桌面功能？
我知道在某些公司环境中，例如银行，它们是向客户提供复杂交易应用程序的相对流行的方式，但为什么它们没有在整个网络中普遍存在？
（为了讨论，让我们假设一个世界：下载源是“可信的”，应用程序是“签名的”（即没有安全问题），下载速度很快（加载时间很快），并且开发人员知道 Java（在他们知道html/js/php))。
我认为原因不是应用程序的安全性或启动时间。在找出根本原因之前，让我们先了解幕后情况。
Java 控制面板具有允许用户使用默认浏览器的代理设置或覆盖它们的设置。换言之，基础架构团队能够自定义 Windows 或操作系统安装映像，以使 JVM 预安装企业代理设置。所以我相信这根本不是问题。
Java Web Start 实际上会在 Java 控制面板中缓存所有具有可自定义设置的应用程序。一旦应用程序被缓存，应用程序就会像其他应用程序一样被“安装”。虽然第一次执行可能很慢，但由于 JVM 的智能内存分配技术，第二次会很快。所以启动时间可能是个问题，但是很多网站（甚至是企业内部的）现在都迁移到了门户网站。Web 门户通常包含许多用于开发目的的未使用库，因为门户本身并不预期在特定页面上构建和部署哪些类型的 portlet。因此，下载单个门户页面可能会消耗高达 MB 并在 5 秒以上的时间内完成一个页面；这只是一页，缓存可以帮助高达 30%，但每次仍然需要下载大量 HTML/Javascript/CSS 组件。有了这个，我确信 Java Web Start 在这里是一个优势。
只要服务器副本未升级，Java Web Start 就不会再次下载。因此，如果像MS Project这样的项目管理软件，使用SmartClient（类似于JWS）来完成，客户端和服务器之间的信息交换将是纯粹的数据，没有像浏览器的整页刷新那样的呈现。即使在 Ajax 的帮助下，它也不能完全消除整页下载。此外，很多公司都认为 Ajax 还不成熟且不安全。这就是为什么 Ajax 在开发人员圈子中是一个热门话题，但在企业软件中还不是。考虑到这一点，JWS 应用程序肯定具有更多优势，例如 JWS 应用程序如何在沙箱中部署和执行、签名以及具有更多交互式 GUI。
其他优势包括更快的开发（更容易调试代码和性能）、响应式用户界面（不需要 Comet 服务器提供 PUSH 功能）和执行速度更快（当然，因为客户端计算机无需像 HTML/Javascript/CSS 那样翻译即可呈现 GUI，和更少的数据处理）。
毕竟这些，我还没有触及这个问题，为什么JWS没有那么有名？
我的观点是，这与 Brian Knoblauch 的评论相同，没有意识。
IT 人员也被 Web 技术、Ajax PUSH、GWT 的炒作所吸引，所有这些流行语使他们偏向于使用不同技术或解决技术挑战的乐趣，而不是真正为客户工作的东西。
看看思杰。我认为 Citrix 实际上是一个好主意。Citrix 允许您在幕后构建自己的应用程序场。您可以在不影响客户体验的情况下采用大量升级和实施策略。Citrix 部署非常简单、稳定和安全。企业仍在使用它。但是，我认为 JWS 甚至比 Citrix 还要好。JWS 的想法是在客户端机器上运行应用程序，而不是托管大量的服务器场，让客户端机器能够自己运行这些应用程序。这为公司节省了很多钱！！！使用 JWS，开发团队仍然可以在服务器端构建业务逻辑和数据。但是，没有Web处理单元，让客户端计算机来做渲染过程，大大降低了网络消耗量和服务器处理能力。
为什么 JWS 是一个了不起的想法的另一个例子是 Blackberry MDS。黑莓应用程序实际上是从 Javascript 翻译而来的 Java 应用程序。使用 BB 的 MDS 工作室，您可以使用 GUI 工具构建 BB 应用程序 GUI，用 Javascript 编写 GUI 逻辑。然后应用程序被翻译并部署在 BES 服务器上。然后 BES 服务器会将这些应用分发给 BB。在每个 BB 上，它运行一个仅具有 GUI 呈现和网络功能的瘦 Java 应用程序。每当应用程序需要数据时，它都会通过 Web 服务与 BES 通信，以使用来自其他服务器的服务。这不就是JWS BB版吗？它非常成功。
最后，我认为 JWS 不受欢迎是因为 Sun 宣传它的方式。BB 从不宣传他们的 BB Java 应用程序有多好，他们相信客户甚至不会关心它是什么。BB 宣传使用 MDS 开发应用程序的好处：快速、节省成本、业务回报。
只是我的，有点长，2美分...... :)
Java Webstart 的一个主要障碍可能是您仍然需要安装 JVM，然后它才能尝试下载和启动您的应用程序。每个人都有一个浏览器。不是每个人都有 JVM。
编辑： 我已经获得了一些动手的 webstart 经验，现在可以添加这两点：
我认为这主要是由于缺乏意识。它工作得很好。相当无缝。应用程序仅在第一次、有升级或最终用户清除缓存时才下载。部署成熟的桌面应用程序的好方法，用户不必担心手动升级！
Webstart 的问题在于，您实际上必须“启动”一些即使连接速度也没有那么快的东西，而使用 web 应用程序，您输入 URL 并且应用程序就在那里。
webstart 也可能出现很多问题。可能目标用户没有所需的权限，或者 webstart 的代理配置错误，或者 jre 依赖项出现问题，或者根本没有安装 java。因此，对于互联网上的普通 john doe 来说，它一点也不讨人喜欢。
在像公司这样的受控环境中，在许多情况下，它是一个很好且简单的解决方案。
几年来，我已经在数千名用户基础上开发了一个 JWS 部署的应用程序，它的自动升级实际上是一个巨大的痛苦。
由于某种原因，每次更新都会有数十名用户“卡在中间”。你得到的只是“找不到类”异常（如果你很幸运的话），或者在 JWS 到达你的代码之前就从 JWS 中“无法启动”。看起来更新已下载一半。或者，换句话说，它不会自动下载和应用更新并且缓存很差，因此从相同的 URL 重新启动应用程序并不能解决任何问题。
除了清除 JWS 缓存或提供不同的 URL（例如?dummyparam=jwssucks在末尾附加）之外，没有其他方法可以解决它。即使我作为开发人员有时也会遇到它并且看不到解决方法。
当它起作用时，它就会起作用。但通常情况并非如此，这对您和您的帮助台来说是一个巨大的痛苦。我不建议将它用于企业或关键任务用途。
有一个非常大的问题，即它不允许“立即启动程序，然后在后台检查并下载任何更新”部署，这是应用程序的实际行为正在趋同的。
我个人认为这非常令人烦恼，以至于我们正在积极寻找另一种提供这种技术的技术。
从这些帖子中可以看出，在使用 Web 启动时，好好照顾服务器很重要。每次启动时下载应用程序的“巨大痛苦”可能是由于服务器传递的时间戳不正确造成的。这里不是应用程序，而是服务器必须配置为正确使用缓存，而不仅仅是禁用它。关于错误启动，我不太确定，但在我看来，这也可能是由不可靠的连接引起的。
Web start 的重要优点是它可以很好地与 Linux 下的 OpenJDK 配合使用。一些快乐的开发人员的客户只使用 Windows，但我的客户不使用。
在最初的问题中提到的 HTML 和 JavaScript 是较轻的方法，可以很好地处理较小的任务，例如动画按钮甚至交互式表格。Java 利基似乎围绕着更复杂的任务。
Java Web Start 是 Java Applet 的继承者，Applet 在新千年左右被烧毁。但是，我仍然认为 Java Applets 比 GWT 或 Javascript 地狱要好得多。