java 8u31插件导致签名小程序加载速度慢得多
我注意到使用最新的插件（包含在java 8u31和7u75中）加载签名的applet要慢得多。 我已经调试了很多情况，我发现问题与jnlp文件中引用的jar文件的大小直接相关。 问题是每次applet启动时，都会对缓存的jar文件进行一些“重新索引”，这需要花费时间。
为了重现这个问题我做了这个：我创建了一个最小的applet，在我用来部署它的jnlp文件中，我添加了几个不相关的.jar文件（甚至没有被引用，所以类加载器不加载它们）相当大（例如30MB）。 当然我在jnlp中使用版本控制并捕获所有http流量以确保延迟不是因为流量（重新下载或证书撤销检查等）。 我在启用了跟踪的情况下运行applet，然后浏览了xml跟踪日志文件，找出了延迟的来源：它们总是来自JarSigningVerifier ….
有没有人见过这样的东西？
很容易看到和重现这种行为，我想知道是否有我忽略的东西。 在过去几年中广泛使用applet，我完全迷失了可能发生的事情。 我可以validation恢复到以前版本的插件（以及之前的所有其他版本）按预期工作。
我已经向oracle提交了一份错误报告，但我还没有收到回复。 任何信息或想法都会有所帮助，TIA
同样在这里。 我以为我已经疯了。 谢谢你分享这个。
我们正在使用Java Web Start，但是它共享了重新索引所有jar文件的相同问题（在我们的例子中，它是一个带有相当一些jar的应用程序，所以开始需要很长时间）。
除了Oracle突然决定检查部署TLS的证书这一事实之外，这在Linux和Mac上引起了一些困难（我们在那里使用了一个未包含在Java密钥库中的StartSSL证书 – 在Windows上它可以正常使用平台根证书也是如此）。
而且，更糟糕的是，在Windows x86上，如果-XX：+ DoEscapeAnalysis或-XX：+ OptimizeStringConcat存在于JVM参数中，8u31会无声地死亡，尽管这两个参数在Java 8中都是标准的（但不是在7中，这就是为什么他们已经被包括在内了。 64位引擎没有这个问题。
接下来他们改变的是他们现在覆盖了开始图标，如果它们已被更改（我们改变它们以将64位引擎的路径放在那里），所以它每次都固执地将路径改回32位引擎。
Oracle的行为完全没有帮助，因为他们没有在更改日志中宣布任何这些更改，更不用说在未来几天宣布证书更改。
我想听听任何分享问题和可能的解决方法的人的意见。
帕特里克
你能解决这个问题吗？ 你有甲骨文的反应吗？
更新开始
-
我已经尝试了一切我能想到的并且没有设法解决这个问题，所以我在这个问题上发表了自己的问题 。
-
可以在这里找到类似的错误报告，并将其向后移植到我测试的至少Java 8u51。 然而，他们又设法增加了我们申请的启动时间。
结束更新
我们正在将Java Web Start用于基于Eclipse RCP的应用程序，其中包含全部签名的jar。 IDE中的启动时间是8s，Java版本似乎并不重要。 随着网络的开始，故事是不同的。 每次Java更新都会变得更糟糕：
- 7U？ （<60）：+ 2s（10s）
- 7u60：+ 5s（13s）
- 7u75：+ 15s（23s）
- 8u31：+ 12s（20s）
- 8u40：+ 21s（29s）
- 8u51：+ 23s（31s）
你没有版本化试过你的jnlp吗？ 根据我的经验，如果更改jnlp默认值，Java jnlp特别容易出错。 支持禁用版本控制支持，因此在没有版本控制的情况下尝试它，看看它是否仍然很慢？
对我来说，当我使用update =“background”值时，我注意到了一些错误，所以我不再更改默认的更新方法。 我的理论是Oracle在发布新的Java版本之前只测试jnlp与默认值。