use*_*992 10 java plugins applet java-web-start
我注意到使用最新的插件(包含在java 8u31和7u75中)加载签名的applet要慢得多.我已经调试了很多情况,我发现问题与jnlp文件中引用的jar文件的大小直接相关.问题是,每次applet启动时,都会对缓存的jar文件进行一些"重新索引",这需要花费时间.
为了重现这个问题,我做了这个:我创建了一个最小的applet,在我用来部署它的jnlp文件中,我添加了几个不相关的.jar文件(甚至没有引用,所以类加载器不加载它们)相当大(例如30MB).当然我在jnlp中使用版本控制并捕获所有http流量以确保延迟不是因为流量(重新下载或证书撤销检查等).我在启用了跟踪的情况下运行applet,然后浏览了xml跟踪日志文件,找出了延迟的来源:它们总是来自JarSigningVerifier ....
有没有人见过这样的东西？
很容易看到并重现这种行为,我想知道是否有我忽视的东西.在过去几年中广泛使用applet,我完全迷失了可能发生的事情.我可以验证恢复到以前版本的插件(以及之前的所有其他版本)是否按预期工作.
我已经提交了oracle的错误报告,但我还没有收到回复.任何信息或想法都会有所帮助,TIA
小智 4
同样在这里。我想我已经疯了。感谢您分享这个。
我们正在使用 Java Web Start，但它也面临着重新索引所有 jar 文件的相同问题（在我们的例子中，它是一个包含相当多 jar 的应用程序，因此启动需要很长时间）。
除了 Oracle 突然决定检查部署 TLS 的证书这一事实之外，这在 Linux 和 Mac 上造成了一些问题（我们在那里使用了 StartSSL 证书，该证书不包含在 Java 密钥库中 - 在 Windows 上它的工作方式与使用平台根证书也是如此）。
而且，更糟糕的是，在 Windows x86 上，如果 JVM 参数中存在 -XX:+DoEscapeAnalysis 或 -XX:+OptimizeStringConcat，则 8u31 会默默地死亡，尽管这两个参数在 Java 8 中都是标准参数（但在 7 中不是，这就是为什么他们仍然被包括在内）。64位引擎不存在这个问题。
他们更改的下一件事是，如果启动图标已更改（我们将其更改为将 64 位引擎的路径放在那里），他们现在会覆盖启动图标，因此每次都会顽固地将路径更改回 32 位引擎。
Oracle 的行为根本没有帮助，因为他们没有在变更日志中宣布任何这些更改，更不用说提前几天宣布证书更改了。
我想听听任何分享问题和可能的解决方法的人的意见。
帕特里克
| 归档时间： |
|
| 查看次数： |
3284 次 |
| 最近记录： |