当前位置：文江博客话题详情

对 Java Webstart 有异议吗？

发布于 2024-07-05 15:48:16 字数 224 浏览 6 评论 0原文

自从 Adobe AIR 发布以来，我想知道为什么 Java Web Start 过去没有获得更多关注，因为在我看来，它似乎非常相似，但 Web Start 的可用时间要长得多。

这主要是因为 Sun 的营销不佳，还是除了需要安装正确的 JVM 之外还有更多技术问题？您在使用 Web Start 时有过不愉快的经历吗？如果是，是哪一个？使用 Web Start 分发应用程序时您有什么建议？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

So要识趣 2024-07-12 15:48:16

我曾经在 JWS 做过一个项目，运行起来很痛苦。更糟糕的是，我什至没有处理整个互联网，它只是一个小型应用程序，只有我办公室里的少数人会使用。在配置服务器和帮助他们在客户端计算机上设置应用程序时，我不止一次厌恶地举起双手。

我认为 AIR 现在变得越来越流行（尽管我永远不知道它会走多远），因为它有人们真正想要使用的应用程序（说出您最喜欢的 JWS 应用程序...继续，我在等待），例如 twhirl。我仍然不太喜欢 AIR 的工作方式，但它比 JWS 好得多。

回复收藏 0 原文

花辞树 2024-07-12 15:48:16

以下是 mindprob 的列表：

Java Web Start 应用程序的启动速度非常慢。监视器为其自身和每个应用程序加载新的 JVM。应用程序始终在网络上检查更新、下载和处理整个新的 JNLP 文件，而不仅仅是检查其日期。但是，如果检查新版本需要 80 秒左右，则意味着您的代理服务器可能出现问题。启动 javaws.exe 并单击编辑 ⇒ 首选项 ⇒ 网络设置 ⇒ 直接。您不希望 JWS 尝试使用 Google Accelerator 代理。另外检查 IE，单击工具 ⇒ Internet 选项 ⇒ 连接 ⇒ LAN 设置，并确保一切都如您所愿。
下载更新所需的时间与原始应用程序的下载时间相同。几乎没有采用任何巧妙的方法来使更新变得紧凑。
它需要在 ISP 上运行自定义代码才能正确提供 jardiff 文件或使用即将推出的 pack200 超压缩。
自最初发布以来，它没有太大变化。它可能是又一个孤儿产品。这是不值得的。然而，在一年左右没有发生任何事情之后，Sun 发布了新的 beta 1.2，并且它已经集成到 JRE 中，所以我们将看看它是否再次恢复活力。他们忽略了一些主要问题，例如证书 OK 隐藏在启动屏幕后面，并且要求每个 jar 分别为 ok。即使是孤儿，也不会发生什么可怕的事情。除非您编写未签名的 JWS 应用程序并使用 JWS 沙箱，否则您的 JWS 应用程序将独立运行良好。
它需要在 ISP 和客户端浏览器中对 JNLP MIME 类型进行特殊配置。这些都不在开发商的直接控制之下。
如果您有紧急更新，则无法在应用程序再次运行之前强制安装它。
它需要一个严格的方案来分配客户端计算机上的硬盘空间，该方案具有以下属性：
- 分配的目录名称必须避免与其他供应商发生名称冲突。它们应该包含应用程序的主包名称。
- 名称必须对最终用户有意义。当他需要使用桌面工具查找文件时，它们应该是他能够记住、找到和输入的内容。
- 该方案必须为每个用户和每个应用程序文件提供一个位置。
- 程序应该可以在任何平台上运行，无需修改即可处理查找其文件的问题。

Here is a list from mindprob:

Java Web Start applications are painfully slow to start. The monitor loads a fresh JVM for itself and for each application. Applications always check on the web for updates, downloading and processing an entire new JNLP file, rather than just checking its date. However, if it takes 80 seconds or so to check for a new version, it means you are likely having trouble with a proxy server. Start javaws.exe and click edit ⇒ Preferences ⇒ Network Settings ⇒ Direct. You don’t want JWS trying to use the Google Accelerator proxy. Also check in IE, click tools ⇒ Internet Options ⇒ Connections ⇒ LAN Settings and make sure all is as you expect.
Updates take just about as long to download as the original application. There has been almost no cleverness applied to make the updates compact.
It requires custom code running on the ISP to properly serve the jardiff files or to use the coming pack200 hyper compression.
It has not changed much since its initial release. It may be yet another orphaned product. It does not deserve to be. However, Sun has released a new beta 1.2 after a year or so of nothing happening, and it has been integrated into the JRE, so we’ll see if it is picking up steam again. There are some major problems they have ignored, such as the certificate OK hiding behind the splash screen, and requiring ok for every jar separately. Even if it is orphaned nothing to terrible will happen. Unless you write unsigned JWS apps and use the JWS sandbox, your JWS apps will run fine standalone.
It requires special configuring of the JNLP MIME type both at the ISP and in the client’s browser. Neither of these are under the developer’s direct control.
If you have an urgent update, you can’t force it to be installed before the app is ever run again.
It needs a rigid scheme to assign hard disk space on the client’s machine that has the following properties:
- The names of the directories assigned must avoid name clashes with other vendors. They should incorporate the main package name of the application.
- The names must be meaningful to the end user. They should be something he can remember, find and type when he needs to find files with desktop tools.
- The scheme must provide a place both for per-user and per-application files.
- A program should work on any platform without modification to deal with finding its files.

回复收藏 0 原文

信仰 2024-07-12 15:48:16

Java Web Start 是启动大型 Java 应用程序的正确方法，因为它可以轻松更新和安装/下载应用程序，并且比 Java 小程序提供更好的 UI/UX。

但是，使用具有默认设置的常见浏览器从网页启动 Java Web Start 应用程序存在一些障碍：

Sun/Oracle 无法创建有效的浏览器集成。有关 Google Chrome / Chromium 的示例，请参阅 http://crbug.com/10877。基本上，Java 插件无法实现所需的 NPAPI 内容，无法让 Firefox 和 Chrome 可靠地将 MIME 类型 application/x-java-jnlp-file 转发到 javaws / < code>javaws.exe 二进制文件。
Sun/Oracle 无法获取 Java Web Start .jnlp 文件的真实注册 MIME 类型。 application/x- 前缀从技术上讲意味着草稿或私有。
当 Java Web Start 处理应用程序下载和启动时，Sun/Oracle 未能使用 URL 方案而不是 MIME 类型。例如，如果不使用诸如 https://example.com/app/launch.jnlp 之类的 URL，Java Web Start 会作为 javaws://example.com/app/launch 启动.jnlp 事情会更加顺利。这是因为在这种情况下，Web 浏览器甚至不需要加载 .jnlp 文件，它只需将完整的 URL 传递给方案处理程序（这将是 javaws 二进制）。

注意重复的部分（“Sun/Oracle 失败了...”），您不再需要想知道为什么 Java Web Start 从未获得太多关注。最大的缺失部分是获取一个网页链接，以使用给定的 .jnlp 文件可靠启动 javaws 二进制文件。这在技术上应该非常简单（只需在安装 javaws 二进制文件时注册一个新的 URL 方案即可），但 Sun/Oracle 未能做到这一点。我个人认为整个混乱是由于试图弄乱 MIME 类型而不是简单地使用新的 URL 方案造成的。甚至 MIME 类型的东西也做得非常糟糕，因为大声哭泣。

如果您仍然想使用 Java Web Start，只需准备好文档来正确配置浏览器即可解决 Sun/Oracle 留下的混乱问题。好的一点是，只需完成一次，并且它适用于任何使用 Java Web start 的站点。不好的部分是，通常浏览器从未被配置为使用 .jnlp 文件执行正确的操作，并且您会因使用“难以使用的技术”而受到指责，因为用户不想仅仅为了使用您的应用程序而配置他们的浏览器。我有没有提到 Sun/Oracle 无法自动配置浏览器？

Java Web Start is the right way to start bigger Java applications because it allows for easy updating and installing/downloading the application and allows for better UI/UX than Java applets.

However, there are some roadblocks for launching Java Web Start applications from a web page using common browsers with default settings:

Sun/Oracle failed to create a working browser intergration. See http://crbug.com/10877 for example about Google Chrome / Chromium. Basically the Java plugin fails to implement the required NPAPI stuff to get Firefox and Chrome to reliably forward the MIME-type application/x-java-jnlp-file to javaws / javaws.exe binary.
Sun/Oracle failed to get a real registered MIME-type for Java Web Start .jnlp files. The application/x- prefix technically means draft or private.
Sun/Oracle failed to use URL scheme instead of MIME-type when the intent is that Java Web Start handles the application downloading and launching. For example, if instead of using URL such as https://example.com/app/launch.jnlp Java Web Start were launched as javaws://example.com/app/launch.jnlp things would work much smoother. This is because in this case, the web browser does not need to even load the .jnlp file, it just passes the full URL to the scheme handler (which would be the javaws binary).

Notice the repeating part ("Sun/Oracle failed ...") and you no longer need to wonder why Java Web Start never got much traction. The big missing part is getting a web page link to reliably launch the javaws binary with the given .jnlp file. That should be technically really easy (just register a new URL scheme when the javaws binary is installed), yet Sun/Oracle failed to do that. I personally think that the whole mess was caused by trying to mess with the MIME-type instead of simply using a new URL scheme. And even the MIME-type stuff was done really badly, for crying out loud.

If you still want to use Java Web Start, simply prepare good documentation for correctly configuring the browser to workaround the mess left by Sun/Oracle. The good part is that it's only needs to be done once and it will work for any site that uses Java Web start. The bad part is that usually the browser has never been configured to do the right thing with .jnlp files and you get the blame for using "hard to use technology" because users do not want to configure their browsers just to use your application. Did I mention that it was Sun/Oracle that failed to configure the browser automatically?

回复收藏 0 原文