Java8U31插件导致签名小程序的加载速度大大降低

我注意到，最新的插件（包含在Java8U31和7u75中）加载签名小程序的速度要慢得多。我对这种情况进行了大量调试，发现问题与jnlp文件中引用的jar文件的大小直接相关。问题是，每次小程序启动时，都会对缓存的jar文件进行一些“重新索引”，这需要时间

为了重现这一问题，我做了以下工作： 我创建了一个最小的applet，在我用来部署它的jnlp文件中，我添加了几个不相关的.jar文件（这些文件甚至没有被引用，因此类加载器不会加载它们），它们的大小相当大（例如30MB）。当然，我在jnlp中使用版本控制并捕获所有http流量，以确保延迟不是因为流量（重新下载或证书吊销检查等）造成的。我在启用跟踪的情况下运行小程序，然后查看xml跟踪日志文件，发现延迟来自何处：它们总是来自JarSigningVerifier

还有人见过这样的事吗

这是很容易看到和复制这种行为，我想知道是否有什么我忽略了。在过去的几年里，我一直在广泛地研究applet，我完全不知道会发生什么。我可以验证恢复到插件的前一个版本（以及之前的每一个版本）是否如预期的那样工作

我已经向oracle提交了一份bug报告，但我还没有得到回复。任何信息或想法都会有所帮助，

---

TIA在这里也一样。我以为我已经疯了。谢谢分享

我们使用的是JavaWebStart，但它也面临着同样的问题，即重新索引所有jar文件（在我们的例子中，它是一个包含相当多jar的应用程序，因此启动需要花费很多时间）

除了Oracle突然决定检查deploy TLS的证书这一事实之外，这在Linux和Mac上引起了一些小问题（我们在那里使用了StartSSL证书，它不包含在Java密钥库中-在Windows上，它也使用平台根证书）

更糟糕的是，在Windows x86上，如果JVM参数中存在-XX:+DoEscapeAnalysis或-XX:+OptimizationStringConcat，则8u31会自动消失，尽管这两个参数在Java 8中都是标准的（但在7中不是，这就是为什么它们仍然被包括在内）。64位引擎没有这个问题

他们改变的下一件事是，如果开始图标被更改，它们现在将覆盖它们（我们将它们更改为将64位引擎的路径放在其中），因此每次都会顽固地将路径更改回32位引擎

Oracle的行为毫无帮助，因为他们没有在变更日志中宣布任何这些更改，更不用说在几天前宣布证书更改了

我希望听到任何人分享的问题和可能的解决办法

---

Patric

您是否尝试过没有版本控制的jnlp？根据我的经验，Java jnlp非常有缺陷，特别是如果更改jnlp默认值。版本控制支持已被支持禁用，因此请在不进行版本控制的情况下尝试，看看是否仍然很慢

---

对我来说，当我使用update=“background”值时，我注意到了一些错误，所以我不再更改默认的更新方法。我的理论是，在发布新的Java版本之前，Oracle只会根据默认值测试jnlp。

您能解决这个问题吗？你对甲骨文有什么反应吗

更新开始

---

• 我已经想尽一切办法解决了这个问题 问题，所以我

• 并被后传到at 至少是我测试过的Java8U51。他们又设法增加了 应用程序的启动时间

结束更新

我们将JavaWebStart用于一个基于EclipseRCP的应用程序，其中JAR都是经过签名的。 IDE中的启动时间是8秒，Java版本在这里似乎并不重要。有了web start，情况就不同了。每一次Java更新都会变得（更）糟糕：

---

• 7u？？（我没有，我也不能。如果不进行版本控制，它将使用http调用检查每个jar，这将导致与我试图避免的延迟完全相同的延迟。我理解，但使用Java，你永远不知道。放弃版本控制可能会更快。我还想在使用后台更新选项时避免http调用。但结果是http打电话查看文件是否有更改无论如何都很快，并且在后台没有太大帮助。尝试使用和不使用版本控制并计时，看看哪一个加载得更快。感谢您的想法；我们已经花了几个小时/天/周来测量和优化这些延迟。版本控制对于小程序的加载速度来说是必须的（至少在我们的案例中是这样）。虽然这里的要点是有些东西坏了，但我希望要么是我弄错了，要么是Oracle会修复它（或者存在一个解决方案，我错过了它），我们将切换到getdown（）我一直在使用它，它看起来是一个很好的替代品。虽然它是JWS的引导，但它的其余部分确实是FASTHOY，我试用过了，下载后启动得很快。我可能会等到七月/ 8月，检查这个问题是否已修复，但肯定会考虑GATDOWN。希望它能安装一个书桌。带有自动更新功能的顶部/任务栏图标。getdown确实支持您在表单中看到的内容。我对它印象深刻，它是开源的-因此您不再被专有错误困扰。您解决了问题吗？我尝试过Java 8u51，它应该有Oracle错误修复的后端口，但它看起来仍然是jar验证tak大约20秒（在一台速度非常快的开发人员pc上）。我们把它取下来，而不是jnlp。然而，在一些内部测试中，我们做了，似乎新版本确实解决了问题。然而，损害已经造成了…我已经尝试了我能想到的一切，但仍然没有解决问题，所以我发布了这个问题：在此期间，我是al