Java8U77上周（2016年3月23日）发布
嗨，一个月前发布了一个相关问题（关于Java8U74）–我现在发布的是一个新问题，因为我们有更准确的信息，我的问题略有不同。
对于我的web start应用程序，如果客户端安装了更新，则在运行时会出现错误：
java.security.cert.CertificateException:
Could not verify signing in resource: https://www.example.com:443/app/myFile.jar
at com.sun.deploy.security.TrustDecider.ensureAllJarEntriesSigned(Unknown Source)
….深入到代码中，我注意到以下行产生了错误：
ClassLoader classLoader = this.getClass().getClassLoader();
classLoader.getResource("").getPath();第二行返回null。
此代码适用于Java8U73及更早版本。甲骨文证实这是一个错误-https://bugs.openjdk.java.net/browse/jdk-8152827
然而，我不确定我是否可以等待一个错误修复…我们正在试图找到一个解决办法…
这就是我发现的-
我们试图用classloader访问的jar文件不是应用程序类路径的一部分。它们包含不属于java代码的文件。
我们注意到，如果在jar中添加一个类文件，然后将jar设置为项目和类路径的一部分，则不会再现错误。
但是我们的问题是我们有一个很长的jar文件动态列表（我们定期创建新jar）。每次加载应用程序时（使用jnlp文件）–我们都会动态地将必要的jar添加到jnlp文件列表中。我们不可能为创建的每个新jar进行新的应用程序部署(如前所述–这些jar没有java代码。）
当然，所有jar都使用相同的可信证书进行签名。而且–同样–在8u73上工作没有问题。
有人有解决办法的想法吗？
谢谢
7条答案
按热度按时间v64noz0r1#
甲骨文有关于这个错误的信息，https://bugs.openjdk.java.net/browse/jdk-8151624，但普通公众没有对该url的读取权限(我也不知道，但是你链接的bug被标记为隐藏bug的副本。）
所以我们无能为力，甲骨文对此没有任何沟通，解决方法是使用8u73。
您必须手动卸载以前的jre（http://java.com/newerversionexists 将重定向到基于浏览器操作系统的说明），然后在此处下载8u73：http://www.oracle.com/technetwork/java/javase/downloads/java-archive-javase8-2177648.html#jre-8u73其他jpr
但是：你必须注册一个甲骨文帐户，并给他们你的电子邮件地址，电话号码等，以便下载链接的工作。
干得好，甲骨文。
5cg8jx4n2#
我在调用classloader.getresource/getresourceasstream时看到过这个问题，但在调用getresources时没有看到。因此，可能的解决方法是：
thread.currentthread（）.getcontextclassloader（）.getresources（“some/path”）。
路径应该是绝对路径，但不能以“/”开头。返回类型是URL的枚举。
wdebmtf23#
我有一个完全相同的问题（stacktrace的问题）。一切正常
8u73.与
8u74每次使用时误差都是可再现的Java Control Panel-临时文件设置-选中“在我的电脑上保留临时文件”。如果不选中，错误不会再现。同样的行为也适用于
8u77. 到目前为止，我发现的唯一区别是：如果先取消选中“在我的计算机上保留临时文件”，然后再次选中，则错误不会每次都重现。原因不明。请注意，在中取消选中此选项
Java Control Panel可能会降低应用程序的性能。不过，根据您的客户机和应用程序的不同，这可能是一个比仅仅要求不更新更好的解决方法。eh57zj3b4#
我们发现jre8u74-77中的这个异常是由从另一个jar加载资源引起的。所以呢
this.getClass()还不够好。另一个例子，调用ResourceBundle.getBundle()对于资源所在的jar类，应该有第三个参数加载器。还有一个在jar之间洗牌资源文件的选项。像swingx这样的第三方库更麻烦。奇怪的是，抛出的异常是
CertificateException更合适的时候是“找不到资源”。iaqfqrcu5#
我的解决方法是在jnlp归档文件中声明依赖项，而不使用“version”标记。
例如，这种方法很有效：
该溶液具有以下横向效应：
版本下载协议不会生效，因此每次用户执行应用程序时，jws都会向服务器请求应用程序中包含的每个jar。jar不会被更新，但是因为服务器可能会用304来响应，表明它已经被更新了，但是如果应用程序包含很多库，那么启动应用程序会有一些延迟，因为每个库都有一个http请求。
bpzcxfmw6#
刚刚测试了1.8u91和问题还没有得到修复，如在早些时候的评论指出。
z0qdvdin7#
似乎是黑暗的举动。显然，javaseadvanced上的客户可以直接利用bug修复，但非付费客户仍在等待包含bug修复的第一个ga版本。再加上公共jbs问题的全部内容，这些问题被标记为私人问题的副本，而私人问题的状态是看不见的。