java 8u31 插件导致签名小程序加载速度慢得多 [英] java 8u31 plugin causes signed applets to load much slower
问题描述
我注意到使用最新的插件(包含在 java 8u31 和 7u75 中)加载签名小程序的速度要慢得多.我已经调试了很多情况，我发现问题与jnlp文件中引用的jar文件的大小直接相关.问题是每次小程序启动时，都会对缓存的 jar 文件进行一些重新索引"，这需要时间.
i have noticed that signed applets are loaded much slower with the latest plugin (included in java 8u31 and 7u75). I have debugged the situation quite a lot and i found out that the problem is directly related to the size of the jar files that are referenced in the jnlp file. The problem is that each time the applet starts, there is some 're-indexing' of the cached jar files that takes time.
为了重现这个问题，我这样做了:我创建了一个最小的小程序，在我用来部署它的 jnlp 文件中，我添加了几个不相关的 .jar 文件(甚至没有被引用，所以类加载器不会加载它们)相当大(例如 30MB).当然，我在 jnlp 中使用版本控制并捕获所有 http 流量以确保延迟不是因为流量(重新下载或证书吊销检查等).我在启用跟踪的情况下运行小程序，然后查看 xml 跟踪日志文件并找出延迟的来源:它们总是来自 JarSigningVerifier ....
To reproduce the issue i did this: I created a minimal applet and in the jnlp file i used to deploy it, I added several irrelevant .jar files (that are not even referenced, so the classloader does not load them) of considerable size (e.g. 30MB). Of course i am using versioning in the jnlp and capture all http traffic to make sure that the delays are not because of traffic (either re-downloading or certificate revocation checks, etc). I run the applet with the trace enabled and then went through the xml trace log file and found out where the delays come: they are always from the JarSigningVerifier ....
有没有其他人看到过这样的东西?
Has anyone else seen something like that?
很容易看到和重现这种行为，我想知道我是否忽略了一些东西.在过去几年中广泛研究小程序后，我对可能发生的事情完全迷失了方向.我可以验证恢复到插件的先前版本(以及之前的所有其他版本)是否按预期工作.
It is very easy to see and reproduce this behavior and i wonder if there is something i am overlooking. Having worked on applets for the past years extensively, i am totally lost at what can be happening. I can verify that reverting to the previous version of the plugin (and every other version before) works as expected.
我已经用 oracle 提交了一个错误报告，但我还没有收到回复.任何信息或想法都会有所帮助，TIA
I have submitted a bug report with oracle, but i haven't heard back still. Any info or idea will help, TIA
推荐答案
您是否能够解决这个问题?您收到 Oracle 的回应了吗?
Have you been able to solve this issue? Have you had a reaction from Oracle?
更新开始
我已经尝试了所有我能想到的方法，但没有设法解决问题问题，所以我在这个问题上发布了我自己的问题.
可以在此处找到类似的错误报告，并且是反向移植到我测试过的至少是 Java 8u51.他们再次设法增加我们的应用程序的启动时间.
A similar bug report can be found here and is backported to at least Java 8u51 which I tested. Yet again they managed to increase startup time for our application.
结束更新
我们将 Java Web Start 用于基于 Eclipse RCP 的应用程序，其中包含所有已签名的 jar.IDE 内的启动时间是 8 秒，Java 版本在这里似乎无关紧要.有了网络启动，情况就不同了.每次 Java 更新都会变得(更)糟糕:
We are using Java Web Start for an Eclipse RCP-based application with jars that are all signed. Startup time is 8s within the IDE, Java version doesn't seem to matter here. With web start the story is different. It becomes (much) worse with every Java update:
- 7u??(<60): +2s (10s)
- 7u60:+5 秒(13 秒)
- 7u75:+15 秒(23 秒)
- 8u31:+12 秒(20 秒)
- 8u40:+21 秒(29 秒)
- 8u51:+23 秒(31 秒)
这篇关于java 8u31 插件导致签名小程序加载速度慢得多的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
