java.lang.SecurityException：类“XYZ”的签名者信息与同一包中其他类的签名者信息不匹配
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/1339787/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
java.lang.SecurityException: class "XYZ"'s signer information does not match signer information of other classes in the same package
提问by paul
I have an applet which runs in a browser and is called from Javascript. There are 2 classes: PortalLauncherand ParamSplitterand these are in the default package. Javascript calls a method in PortalLauncherwhich in turn calls a function in ParamSplitter. The applet is in a signed jar.
我有一个在浏览器中运行并从 Javascript 调用的小程序。有 2 个类：PortalLauncher和ParamSplitter，它们在默认包中。JavaScript调用的方法PortalLauncher这反过来又调用一个函数ParamSplitter。小程序在一个签名的罐子里。
This works most of the time. However, a few users have problems from time to time. At some time in the day (i.e. not on first access) the following exception is thrown:
这在大多数情况下都有效。但是，一些用户不时会遇到问题。在一天中的某个时间（即不是第一次访问）抛出以下异常：
java.lang.SecurityException: class "ParamSplitter"'s signer information does not
match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access##代码##0(Unknown Source)
at java.net.URLClassLoader.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at sun.applet.AppletClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.applet.AppletClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)
at PortalLauncher.openFile(PortalLauncher.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSInvoke.invoke(Unknown Source)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at sun.plugin.javascript.JSClassLoader.invoke(Unknown Source)
at sun.plugin.com.MethodDispatcher.invoke(Unknown Source)
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
java.lang.Exception: java.lang.SecurityException: class "ParamSplitter"'s signer
information does not match signer information of other classes in the same package
at sun.plugin.com.DispatchImpl.invokeImpl(Unknown Source)
at sun.plugin.com.DispatchImpl.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at sun.plugin.com.DispatchImpl.invoke(Unknown Source)
Can anyone throw any light on what this exception means and what might be causing it? There are about 800 users who have this applet but only a handfull are affected and even those have the problem only occaisionally.
任何人都可以阐明此异常的含义以及可能导致它的原因吗？大约有 800 名用户拥有这个小程序，但只有少数用户受到影响，即使是那些也只是偶尔出现问题的用户。
采纳答案by Wouter Coekaerts
It means that inside the same JVM, there are other classes loaded from other jars that have been signed differently (or not signed maybe), also in the default package.
这意味着在同一个 JVM 中，还有从其他 jars 加载的其他类，这些类的签名不同（或者可能没有签名），也在默认包中。
If I interpret your question correctly your applet itself only has one jar, so it must be a jar coming from somewhere else; that only some users have. My first thought it's maybe the jar of an applet running in another tab (that can be using the same jvm instance). But other applets should be using a separate classloader, so they shouldn't collide like that. More likely, they have a jar in the boot classpath of their jvm that also has a class in the root package.
如果我正确解释了你的问题，你的小程序本身只有一个罐子，所以它一定是一个来自其他地方的罐子；只有部分用户拥有。我的第一个想法可能是在另一个选项卡中运行的小程序的 jar（可以使用相同的 jvm 实例）。但是其他小程序应该使用单独的类加载器，所以它们不应该像那样冲突。更有可能的是，他们的 jvm 的引导类路径中有一个 jar，在根包中也有一个类。
Either way, the solution/workaround is simply not to use the default package, but your own package. That way you avoid colliding with the other jar.
无论哪种方式，解决方案/解决方法都不是使用默认包，而是使用您自己的包。这样你就可以避免与另一个罐子相撞。
