java 8u31插件导致签名的小程序加载慢得多

发布时间：2020-12-14 17:47:03 所属栏目：Java 来源：网络整理

导读：我注意到,使用最新的插件(包括在 java 8u31和7u75中),签名的小程序加载速度要慢得多.我已经调试了很多情况,我发现问题与jnlp文件中引用的jar文件的大小直接相关.问题是每次applet启动时,缓存的jar文件都会有一些“重新索引”,需要时间. 为了重现我这样做的问

我注意到,使用最新的插件(包括在 java 8u31和7u75中),签名的小程序加载速度要慢得多.我已经调试了很多情况,我发现问题与jnlp文件中引用的jar文件的大小直接相关.问题是每次applet启动时,缓存的jar文件都会有一些“重新索引”,需要时间.

为了重现我这样做的问题：
我创建了一个最小的applet,并且在我用于部署它的jnlp文件中,我添加了相当大的(例如30MB)的几个不相关的.jar文件(甚至不被引用,所以类加载器不加载它们).当然,我正在使用jnlp中的版本控制,并捕获所有http流量,以确保延迟不是因为流量(重新下载或证书吊销检查等).我运行小程序启用跟踪,然后通过xml跟踪日志文件,并找出延迟到达的地方：他们总是来自JarSigningVerifier ….

有没有人看到这样的东西？

这是非常容易看到和重现这种行为,我想知道是否有一些我俯瞰.在过去几年中,在广泛工作过applet之后,我完全失去了可能发生的事情.我可以验证,恢复到以前版本的插件(和之前的每个其他版本)按预期工作.

我已经提交了oracle的错误报告,但是我还没有听到.任何信息或想法都会有所帮助,
TIA

解决方法

同样在这里.我以为我已经疯了感谢您分享此内容.

我们正在使用Java Web Start,但是它共享同样的问题,重新索引所有的jar文件(在我们的例子中它是一个有相当一些jar的应用程序,所以开始需要年龄).

除了Oracle突然决定检查部署TLS的证书,这导致了Linux和Mac上的一些错误(我们在Windows上使用了不包括在Java密钥库中的StartSSL证书),因为它使用平台根本也是)

而且,为了使它更糟糕,在Windows x86上,如果-XX：DoEscapeAnalysis或-XX：OptimizeStringConcat存在于JVM参数中,则8u31会静默地死机,尽管这两个参数在Java 8中都是标准的(但不是在7中,已被列入,仍然). 64位引擎没有这个问题.

接下来他们改??变的是现在,如果他们已经改变了,它们会覆盖开始的图标(我们改变了它们以将64位引擎的路径放在那里),所以它每次都固定地将路径改回32位引擎.

Oracle的行为根本没有帮助,因为他们没有在其更新日志中公布任何这些更改,更不用说在未来几天宣布证书更改.

我想听到任何分享问题和可能的解决方法的人.

帕特里克

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!