Java Web Start - 流行度
我最近使用了 Java Web Start 应用程序。 我使用我正在查看的页面中嵌入的 jnlp 链接从网络浏览器启动它。 该应用程序已下载、启动并且运行良好。 它可以访问我的本地文件系统，并在重新启动它之间记住我的首选项。
我想知道的是，为什么 Java Web Start 应用程序不是 Web 上复杂应用程序更流行的交付格式？ 为什么开发人员经常花费大量时间和精力？ 当使用 Java 和 JavaScript 可以更轻松地提供桌面应用程序的功能时，可以在 html/javascript 中复制桌面功能。 Java Web 启动？
我知道在某些企业环境（例如银行业）中，它们是向客户提供复杂交易应用程序的相对流行的方式，但为什么它们没有在整个网络上普及？
（为了讨论方便，我们假设一个世界：下载源是“受信任的”，应用程序是“签名的”（即没有安全问题），下载速度很快（加载时间很快）并且开发人员了解 Java（在数字中）他们知道 html/js/php))。
I recently used a Java Web Start application. I launched it from my web browser using an embedded jnlp link in the page I was viewing. The application was downloaded, launched and worked just fine. It had access to my local file-system and remembered my preferences between restarting it.
What I want to know is why are Java Web Start applications not a more popular delivery format for complex applications on the web? Why do developers often spend considerable time & energy replicating desktop functionality in html/javascript when the power of a desktop application could be delivered more easily using Java & Java Web Start?
I know that in some corporate environments, e.g banking, they are relatively popular ways of delivering complex trading applications to clients, but why are they not pervasive across the web as a whole?
(For the sake of discussion let's assume a world where: download sources are "trusted" & applications are "signed" (i.e. no security concerns), download speeds are fast (load time is quick) and developers know Java (in the numbers they know html/js/php)).
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我认为原因不是应用程序的安全性或启动时间。 在找出根本原因之前，让我们先了解一下幕后的情况。
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 允许您在幕后构建自己的应用程序农场。 您可以采用大量的升级和实施策略，而不会影响客户体验。 Citrix 部署极其简单、稳定且安全。 企业仍在使用它。 不过，我认为 JWS 甚至比 Citrix 更好。 JWS 的想法是在客户端计算机上运行应用程序，而不是托管大量服务器群，客户端计算机能够自行运行这些应用程序。 这可以为公司节省很多钱！ 通过JWS，开发团队仍然可以在服务器端构建业务逻辑和数据。 然而，如果没有网页处理单元并让客户端计算机进行渲染处理，则大大降低了网络消耗量和服务器处理能力。
JWS 是一个令人惊奇的想法的另一个例子是 Blackberry MDS。 黑莓应用程序实际上是从 Javascript 翻译而来的 Java 应用程序。 通过 BB 的 MDS studio，您可以使用 GUI 工具构建 BB 应用程序 GUI，用 Javascript 编写 GUI 逻辑。 然后，应用程序将被翻译并部署到 BES 服务器上。 然后BES服务器会将这些应用程序分发给BB。 在每个 BB 上，它运行一个仅具有 GUI 渲染和网络功能的瘦 Java 应用程序。 每当应用程序需要数据时，它就会通过 Web 服务与 BES 通信，以使用来自其他服务器的服务。 这不是JWS BB版本吗？ 这是非常成功的。
最后，我认为 JWS 不受欢迎是因为 Sun 的广告方式。 BB 从不宣传他们的 BB Java 应用程序有多好，他们相信客户甚至不会关心它是什么。 BB 宣传使用 MDS 开发应用程序的好处：快速、节省成本、业务回报。
只是我的，有点长，2 美分...:)
I think the reason is not security nor startup time of the app. Let's understand what's behind the scene before we find out the root cause.
Java Control Panel has settings that allow users to use the default browser's proxy settings or to override them. In other words, infrastructure teams are able to customize the Windows or OS installation images to have JVM pre-installed with enterprise proxy settings. So I believe this is not an issue at all.
Java Web Start actually caches all apps with customizable settings in Java Control Panel. Once the app is cached, the app is "installed" just like other apps. Although first time execution may be slow, the second time will be fast due to JVM's smart memory allocation technique. So start up time could be an issue but a lot of web sites (even enterprise internal) are now migrated to portal. A web portal normally contains lots of unused libraries for development purposes due to the fact that the portal itself does not anticipate what kinds of portlets are built and deployed on a specific page. Therefore, downloading a single portal page could consume up to MBs and complete a page in more than 5 seconds; this is only one page and caching helps up to 30% but there are still lots of HTML/Javascript/CSS components required to download every time. With this, I am sure Java Web Start is an advantage here.
Java Web Start does not download again if it is cached as long as the server copy is NOT upgraded. Therefore, if, e.g. a project management software like MS Project, is completed using SmartClient (similar to JWS), the information exchange between the client and server would be purely data without presentation like browser's full page refresh. Even with the help of Ajax, it doesn't eliminate full page download entirely. Besides, a lot of companies consider Ajax to be immature and unsecured still. That is why Ajax is a hot topic in the circles of developers but not within enterprise software yet. With that in mind, JWS apps definitely have more advantages such as how JWS apps are deployed and executed in sandboxes, signed, and have much more interactive GUI.
Other advantages include faster development (easier to debug in code and performance), responsive user interface (does not require Comet Servers to provide PUSH functionality), and executing faster (for sure because client computers renders GUI without translation like HTML/Javascript/CSS, and less data processing).
After all these, I haven't touched the question yet, why JWS is not so famous?
My opinion is that it is the same as Brian Knoblauch's comment, it's without awareness.
IT folks are too attracted by the hype of Web Technologies, Ajax PUSH, GWT, and all those buzz words make them bias towards the fun of using different technologies or to resolve technical challenges instead of what's really working for the clients.
Take a look at Citrix. I think Citrix is actually a great idea. Citrix allows you to build your own app farms behind the scene. There are tons of upgrade and implementation strategies you can go for without impact to client experience. Citrix deployment is extremely easy, stable and secure. Enterprises are still using it. However, I think JWS is even better than Citrix. The idea of JWS is to run apps on client machines instead of hosting tons of server farms where client machines are capable of running these apps themselves. This saves a company a lot of money!!! With JWS, development team can still build business logic and data on server side. However, without the web processing unit and let the client computers do the rendering process, it greatly reduces the amount of network consumption and server processing power.
Another example of why JWS is an amazing idea is Blackberry MDS. Blackberry apps are actually Java apps translated from Javascript. With BB's MDS studio, you use the GUI tool to build BB app GUI, coding GUI logic in Javascript. Then apps are then translated and deployed on a BES server. Then the BES server will distribute these apps to BB. On each BB, it runs a thin Java App with GUI rendering and networking capability only. Whenever the app requires data, it communicates with the BES through web services to consume services from other servers. Isn't this just JWS BB version? It's been extremely successful.
Finally I think JWS is not popular because of how Sun advertises it. BB never advertises how good their BB Java apps are, they believe clients won't even care what is it. BB advertises the benefits of using MDS to develop apps: Fast, Cost Saving, Business Return.
Just my, a bit long, 2 cents... :)
Java Webstart 的一个主要障碍可能是您仍然需要安装 JVM，然后它才能尝试下载并启动您的应用程序。 每个人都有一个浏览器。 并不是每个人都有 JVM。
编辑：
我已经获得了一些 Webstart 实践经验，现在可以添加这两点：
A major roadblock for Java Webstart is probably that you still need to have a JVM installed before it can even attempt to download and start your application. Everyone has a browser. Not everyone has a JVM.
Edit:
I've since acquired some hands-on webstart experience and can now add these two points:
我认为这主要是由于缺乏认识造成的。 它运作得很好。 相当无缝。 仅当第一次、升级或最终用户清除了缓存时，应用程序才会下载。 部署成熟桌面应用程序的好方法，用户无需担心手动升级！
I think it's mostly due to a lack of awareness. It works very well. Quite seamless. App only downloads if it's the first time, there's been an upgrade, or if the end-user has cleared the cache. Great way to deploy full-blown desktop apps that user won't have to worry about manually upgrading!
Webstart 的问题是，你实际上必须“启动”一些东西，即使连接速度很快，但速度也不是那么快，而使用 Web 应用程序时，你输入 URL，应用程序就在那里。
Webstart 也可能会出现很多问题。 也许目标用户没有所需的权限，或者 webstart 的代理配置错误，或者 jre 依赖项出了问题，或者根本就没有安装 java。 因此，对于互联网上的普通约翰来说，这根本不令人高兴。
在像公司这样的受控环境中，在许多情况下这是一个很好且简单的解决方案。
The problem with Webstart is, that you actually have to 'start' something which isn't at all that fast even with a fast connection, while with a webapp you enter the URL and the app is there.
Also a lot of things can go wrong with webstart. Maybe the intended user doesn't have the privileges needed, or the proxy of webstart is configured wrong, or something went wrong with jre dependencies or there is simply no java installed in the first place. So for the average john doe in the internet it is not at all pleasent.
In controlled environments like a company it is a good and easy solution in many cases.
我在一个 JWS 部署的应用程序上工作了几年，用户群有几千人，它的自动升级实际上是一个巨大的痛苦。
每次更新时，由于某种原因，数十名用户都会“陷入困境”。 您得到的只是“未找到类”异常（如果您幸运的话），或者在 JWS 到达您的代码之前就从 JWS 获得无信息的“无法启动”。 看起来更新下载了一半。 或者，换句话说，它不会自动下载和应用更新，并且缓存很差，因此从同一 URL 重新启动应用程序不会修复任何问题。
除了清除 JWS 缓存或提供不同的 URL（例如在末尾附加
?dummyparam=jwssucks）之外，没有其他方法可以解决该问题。 即使我作为一名开发人员有时也会遇到这种情况并且找不到解决方法。当它起作用时，它就起作用。 但往往情况并非如此，这对您和您的服务台来说是一个巨大的痛苦。 我不会推荐它用于企业或关键任务用途。
I've worked on a JWS-deployed application for a few years over a user base of a few thousands and its automatic upgrades are actually a huge pain.
On every update for some reason dozens of users get "stuck in the middle". All you get is the "class not found" exception (if you're lucky), or uninformative "unable to launch" from JWS before it even gets to your code. Looks like the update is half-downloaded. Or, in other words, it does not download and apply the update atomically AND has poor caching so that relaunching the app from the same URL does not fix anything.
There's no way to resolve it other than clearing JWS cache or providing a different URL (e.g. append
?dummyparam=jwssucksat the end). Even I as a developer hit it sometimes and don't see a way around.When it works, it works. But too often it doesn't, and then it's a huge pain for you and your helpdesk. I would not recommend it for enterprise or mission-critical use.
有一个非常大的问题，即它不允许“立即启动程序，然后在后台检查并下载任何更新”部署，而这正是应用程序的实际行为所趋同的。
我个人认为这非常令人烦恼，因此我们正在积极寻找另一种能够提供这种服务的技术。
There is a very big issue namely that it doesn't allow for "start the program instantly and THEN check for and download any updates in the background" deployments, which is what the defacto behaviour of applications are converging to.
I consider this personally so big an annoyance that we are actively looking for another technology which provides that.
从这些帖子看来，在使用 Web start 时，照顾好服务器非常重要。 每次启动时下载应用程序的“巨大痛苦”可能是由于服务器传递的错误时间戳造成的。 这里不是应用程序，而是服务器必须配置为正确使用缓存，而不仅仅是禁用它。 关于启动错误，我不太确定，但在我看来，这也可能是由不可靠的连接引起的。
Web start 的重要优点是它可以与 Linux 下的 OpenJDK 很好地配合使用。 一些快乐的开发人员的客户只使用 Windows，但我的客户不使用。
在最初的问题中提到的 HTML 和 JavaScript 是更轻量级的方法，可以很好地处理较小的任务，例如动画按钮甚至交互式表格。 Java 的利基市场似乎围绕着更复杂的任务。
From these posts it looks like when using Web start, it is important to make a good care about the server. The "huge pain" of downloading application on every startup may be caused by incorrect time stamp delivered from the server. Here not the application but the server must be configured to use caching properly and not just to disable it. About buggy start, I am not that much sure, but it seems to me that this also may be caused by unreliable connection.
Important advantage of Web start is that it works nicely with OpenJDK under Linux. Clients of some happy developers use Windows only but my clients do not.
HTML and JavaScript, mentioned in the initial question, are lighter approaches that work fine with smaller tasks like animated buttons or even interactive tables. Java niche seems around much more complex tasks.
Java Web Start 是 Java Applet 的继承者，Applet 在新千年左右就被淘汰了。
但是，我仍然认为 Java Applet 比 GWT 或 Javascript 地狱要好得多。
Java Web Start 与嵌入式 Java Applet
Java Web Start is kind a successor of Java Applets, and applets got burned around the new millenium.
But, I still think Java Applets are way better than GWT or Javascript hell.
Java Web Start vs Embedded Java Applet