【发布时间】：2015-01-27 15:59:28
【问题描述】：
我注意到使用最新插件（包含在 java 8u31 和 7u75 中）签名的小程序加载速度要慢得多。我已经调试了很多情况，我发现问题与 jnlp 文件中引用的 jar 文件的大小直接相关。问题是每次小程序启动时，都会对缓存的 jar 文件进行一些“重新索引”，这需要时间。
为了重现这个问题，我这样做了： 我创建了一个最小的小程序，并且在我用来部署它的 jnlp 文件中，我添加了几个不相关的 .jar 文件（甚至没有被引用，因此类加载器不会加载它们），它们的大小相当大（例如 30MB）。当然，我在 jnlp 中使用版本控制并捕获所有 http 流量，以确保延迟不是因为流量（重新下载或证书吊销检查等）。我在启用跟踪的情况下运行小程序，然后查看 xml 跟踪日志文件并找出延迟的来源：它们总是来自 JarSigningVerifier ....
有没有其他人看到过类似的东西？
很容易看到和重现这种行为，我想知道我是否忽略了某些东西。在过去的几年里，我广泛地研究了小程序，我完全迷失在可能发生的事情上。我可以验证恢复到插件的先前版本（以及之前的所有其他版本）是否按预期工作。
我已经用 oracle 提交了一个错误报告，但我还没有收到回复。任何信息或想法都会有所帮助， TIA
【问题讨论】：
-
您的问题解决了吗？我尝试使用 Java 8u51，它据说有 Oracle 错误修复的反向移植，但似乎 jar 验证仍然需要大约 20 秒（在非常快的开发人员电脑上）。
-
我们使用 getitdown 而不是 jnlp。然而，在我们进行的一些内部测试中，似乎新版本确实解决了这个问题。然而，损害已经造成......
-
我已经尝试了我能想到的一切，但仍然没有解决这个问题，所以我发布了这个问题：stackoverflow.com/questions/31568627/… 同时我也放弃了 Java Web Start。我将创建自己的更新脚本，它可以在我们公司的 LAN 上运行，它会进行简单的版本检查并简单地从网络共享中复制文件。
-
getitdown 的好处是您不需要对 jar 文件进行签名，也不需要在启动时验证它们。您只需要签署非常小的 getdown 小程序。
标签： java plugins applet java-web-start