为了重现我这样做的问题：
我创建了一个最小的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的行为根本没有帮助,因为他们没有在其更新日志中公布任何这些更改,更不用说在未来几天宣布证书更改.
帕特里克
