是什么原因导致 java.lang.IncompleteClassChangeError？

Question

我将 Java 库打包为 JAR，当我尝试从中调用方法时，它会抛出许多 java.lang.IncompleteClassChangeError 错误。这些错误似乎是随机出现的。哪些类型的问题可能导致此错误？

Answer 1

我相信，我的答案将是 Intellij 具体的。

我已经重建干净，甚至手动删除“out”和“target”目录。 Intellij 有一个“使缓存无效并重新启动”功能，有时可以清除奇怪的错误。这次没有成功。依赖项版本在项目设置->模块菜单中看起来都是正确的。

最终的答案是从本地 Maven 存储库中手动删除我的问题依赖项。旧版本的 bouncycastle 是罪魁祸首（我知道我刚刚更改了版本，这就是问题所在），尽管旧版本在正在构建的内容中没有出现，但它解决了我的问题。我使用的是intellij版本14，然后在此过程中升级到15。

Answer 2

导致此问题的另一个原因是您是否为 Android Studio 启用了Instant Run。

解决方法

如果您发现开始出现此错误，请关闭Instant Run。

1. Android Studio 主要设置
2. 构建、执行、部署
3. 即时运行
4. 取消勾选“启用即时运行...”

为什么

Instant Run 在开发过程中修改大量内容，以便更快地为正在运行的 App 提供更新。因此立即运行。当它起作用时，它确实很有用。但是，当出现此类问题时，最好的办法是关闭 Instant Run，直到下一个版本的 Android Studio 发布为止。

Answer 3

我得到这个错误是因为我有一个抽象基类，它承诺它实现某个接口，但我忘记添加接口方法的实现，然后我创建了一个非抽象（具体）字节码生成的类，它扩展了抽象类，也不提供这些方法的实现。

当我尝试创建字节码生成的类的实例时，JVM 抱怨 java.lang.InknownClassChangeError。

幸运的是，异常有一个“消息”成员，它提供了有关出错原因的更详细信息。就我而言，该消息清楚地表明特定的类应该实现特定的接口，但它实际上并未实现它。

Answer 4

请检查您的代码是否不包含两个具有相同类名称和包定义的模块项目。例如，如果有人使用复制粘贴基于先前的实现创建新的接口实现，则可能会发生这种情况。

Answer 5

如果这是此错误可能发生的记录，那么：

我刚刚在 CXF (2.6.0) 加载 spring (3.1.1_release) 配置期间在 WAS (8.5.0.1) 上收到此错误，其中 BeanInstantiationException 汇总了CXF ExtensionException，汇总了 IncompleteClassChangeError。以下代码片段显示了堆栈跟踪的要点：

Caused by: org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.bus.spring.SpringBus]: Constructor threw exception; nested exception is org.apache.cxf.bus.extension.ExtensionException
            at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:162)
            at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:76)
            at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:990)
            ... 116 more
Caused by: org.apache.cxf.bus.extension.ExtensionException
            at org.apache.cxf.bus.extension.Extension.tryClass(Extension.java:167)
            at org.apache.cxf.bus.extension.Extension.getClassObject(Extension.java:179)
            at org.apache.cxf.bus.extension.ExtensionManagerImpl.activateAllByType(ExtensionManagerImpl.java:138)
            at org.apache.cxf.bus.extension.ExtensionManagerBus.<init>(ExtensionManagerBus.java:131)
            [etc...]
            at org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:147)
            ... 118 more

Caused by: java.lang.IncompatibleClassChangeError: 
org.apache.neethi.AssertionBuilderFactory
            at java.lang.ClassLoader.defineClassImpl(Native Method)
            at java.lang.ClassLoader.defineClass(ClassLoader.java:284)
            [etc...]
            at com.ibm.ws.classloader.CompoundClassLoader.loadClass(CompoundClassLoader.java:586)
            at java.lang.ClassLoader.loadClass(ClassLoader.java:658)
            at org.apache.cxf.bus.extension.Extension.tryClass(Extension.java:163)
            ... 128 more

在本例中，解决方案是更改 war 文件中模块的类路径顺序。也就是说，在 WAS 控制台中打开 war 应用程序并选择客户端模块。在模块配置中，将类加载设置为“parent last”。

这可以在 WAS 控制台中找到：

• Applicatoins ->应用程序类型 -> WebSphere Enterprise Applications
• 单击代表您的应用程序的链接 (war)
• 单击“模块”部分下的“管理模块”
• 单击底层模块的链接
• 将“类加载器顺序”更改为“（父级最后）”。

Answer 6

在花费太多时间后记录另一个场景。

确保您的依赖项 jar 中没有带有 EJB 注释的类。

我们有一个带有 @local 注释的公共 jar 文件。该类后来从该公共项目中移出并移入我们的主 ejb jar 项目中。我们的 ejb jar 和普通 jar 都捆绑在一个耳朵内。我们常用的jar依赖的版本没有更新。因此，两个类试图进行不兼容的更改。

Answer 7

由于某种原因，当使用 JNI 并在调用 Call*Method() 时传递 jclass 参数而不是 jobject 时，也会引发相同的异常。

这与 Ogre Psalm33 的答案类似。

void example(JNIEnv *env, jobject inJavaList) {
    jclass class_List = env->FindClass("java/util/List");

    jmethodID method_size = env->GetMethodID(class_List, "size", "()I");
    long size = env->CallIntMethod(class_List, method_size); // should be passing 'inJavaList' instead of 'class_List'

    std::cout << "LIST SIZE " << size << std::endl;
}

我知道在被问到这个问题 5 年后回答这个问题有点晚了，但这是搜索 java.lang.InknownClassChangeError 时最热门的搜索结果之一，所以我想记录这个特殊情况。

Answer 8

添加我的 2 美分。如果您使用 scala 和 sbt 以及 scala-logging 作为依赖项；那么这种情况可能会发生，因为 scala-logging 的早期版本名为 scala-logging-api。所以；本质上，由于不同的原因，依赖项解析不会发生启动 scala 应用程序时导致运行时错误的名称。

Answer 9

如果你来自android开发。然后尝试一下rebuild选项可能会解决你的问题。

Answer 10

就我而言：

• 我有一个包含几个模块的项目，包括 app、test、integrationTest
• 我创建了 OneElementCache在应用程序模块中。
• 然后，我在测试模块中创建了一个文件 Cache ，该文件包含一些用于在测试中创建 OneElementCache 的帮助程序。
• 到目前为止，一切都运行良好（test 和 integrationTest 均通过）。
• 之后，我在应用程序模块中创建了一个文件Cache。
• 运行integrationTest时得到：

Caused by: java.lang.IncompatibleClassChangeError: 
    class app.cache.CacheImpl can not implement app.cache.Cache, because it is not an interface (app.cache.Cache is in unnamed module of loader 'app')

原因是不同模块（应用程序/测试）中的命名冲突。更改测试中的文件名即可完成工作。

Answer 11

这意味着您对库进行了一些不兼容的二进制更改，而无需重新编译客户端代码。 Java 语言规范 §13 详细介绍了所有此类更改最突出的是，将非静态非私有字段/方法更改为静态，反之亦然。

针对新库重新编译客户端代码，然后就可以开始了。

更新：如果您发布公共库，您应该尽可能避免进行不兼容的二进制更改，以保留所谓的“二进制向后兼容性”。理想情况下，单独更新依赖项 jar 不应破坏应用程序或构建。如果您确实必须破坏二进制向后兼容性，建议增加主版本号（例如从 1.xy 到 2.0 .0) 在发布更改之前。

Answer 12

您新打包的库不向后二进制兼容（BC）旧版本。因此，一些未重新编译的库客户端可能会抛出异常。

这是 Java 库 API 中的更改的完整列表，这些更改可能会导致使用旧版本库构建的客户端在新版本上运行时抛出 java.lang.IncompleteClassChangeError一（即打破BC）：

1. 非最终字段变为静态，
2. 非常量字段变为非静态，
3. 类变为接口，
4. 接口变为类，
5. 如果向类/接口添加新字段（或添加新的超类/超-interface），那么来自客户端类 C 的超接口的静态字段可能会隐藏从 C 的超类继承的添加字段（具有相同的名称）（非常罕见的情况）。

注意：还有许多其他异常是由其他不兼容的更改引起的：NoSuchFieldError、NoSuchMethodError、IllegalAccessError< /em>、InstantiationError、VerifyError、NoClassDefFoundError 和 AbstractMethodError。

关于 BC 的更好的论文是 “发展基于 Java 的 API 2：实现 API 二进制兼容性”，作者：吉姆·德·里维埃。

还有一些自动工具来检测此类更改：

• japi-compliance-checker
• clirr
• japitools
• sigtest
• japi-checker

在您的库中使用 japi-compliance-checker：

japi-compliance-checker OLD.jar NEW.jar

使用 clirr 工具：

java -jar clirr-core-0.6-uber.jar -o OLD.jar -n NEW.jar

祝你好运！

Answer 13

虽然这些答案都是正确的，但解决问题往往更加困难。它通常是类路径上相同依赖项的两个稍微不同的版本的结果，并且几乎总是由与最初针对类路径上编译的超类不同的超类或传递闭包的某些导入引起有所不同，但通常在类实例化和构造函数调用时。 （在成功的类加载和构造函数调用之后，您将得到 NoSuchMethodException 或诸如此类的信息。）

如果行为出现随机，则可能是多线程程序根据首先命中的代码加载不同传递依赖项的结果。

要解决这些问题，请尝试使用 -verbose 作为参数启动 VM，然后查看发生异常时正在加载的类。您应该会看到一些令人惊讶的信息。例如，拥有相同依赖项和版本的多个副本，如果您知道它们被包含在内，您从未预料到或会接受它们。

使用 Maven 解决重复的 jar 问题最好结合 maven-dependency-plugin 和 Maven 下的 maven-enforcer-plugin （或 SBT 的 依赖关系图插件，然后将这些 jar 添加到顶级 POM 的一部分或作为导入的依赖元素 中（删除这些依赖项）。

在SBT

Answer 14

我还发现，当使用 JNI 从 C++ 调用 Java 方法时，如果以错误的顺序将参数传递给调用的 Java 方法，则当您尝试在被调用方法中使用参数时，您将收到此错误（因为它们不会是正确的类型）。最初让我感到惊讶的是，当您调用该方法时，JNI 不会为您执行此检查作为类签名检查的一部分，但我认为它们不会执行此类检查，因为您可能传递多态参数，并且它们必须假设你知道自己在做什么。

C++ JNI 代码示例：

void invokeFooDoSomething() {
    jobject javaFred = FredFactory::getFred(); // Get a Fred jobject
    jobject javaFoo = FooFactory::getFoo(); // Get a Foo jobject
    jobject javaBar = FooFactory::getBar(); // Get a Bar jobject
    jmethodID methodID = getDoSomethingMethodId() // Get the JNI Method ID


    jniEnv->CallVoidMethod(javaFoo,
                           methodID,
                           javaFred, // Woops!  I switched the Fred and Bar parameters!
                           javaBar);

    // << Insert error handling code here to discover the JNI Exception >>
    //  ... This is where the IncompatibleClassChangeError will show up.
}

Java 代码示例：

class Bar { ... }

class Fred {
    public int size() { ... }
} 

class Foo {
    public void doSomething(Fred aFred, Bar anotherObject) {
        if (name.size() > 0) { // Will throw a cryptic java.lang.IncompatibleClassChangeError
            // Do some stuff...
        }
    }
}

Answer 15

我也遇到了同样的问题，后来我发现我在Java版本1.4上运行应用程序，而应用程序是在版本6上编译的。

实际上，原因是有一个重复的库，一个是位于类路径中，另一个包含在位于类路径中的 jar 文件中。

Answer 16

就我而言，我以这种方式遇到了这个错误。我的项目的 pom.xml 定义了两个依赖项 A 和 B。 A 和 B 都定义了对同一工件（称为 C）的依赖，但它的版本不同（C.1和<代码>C.2）。发生这种情况时，对于 C 中的每个类，maven 只能从两个版本中选择该类的一个版本（同时构建 uber-jar）。它将根据其 依赖中介< /a> 规则并将输出警告 “我们有一个重复的类。 .." 如果方法/类签名在版本之间发生更改，并且在运行时使用了不正确的版本，则可能会导致 java.lang.InknownClassChangeError 异常。

高级：如果A必须使用C的v1并且B必须使用C的v2，那么我们必须重新定位 C A 和 B 的 pom 以避免在构建依赖于 A 和 A 的最终项目时发生类冲突（我们有重复的类警告） B。

Answer 17

就我而言，当我在部署在 Websphere 8.5 上的应用程序中添加 com.nimbusds 库时，出现了错误。
发生以下异常：

引起：java.lang.IncompleteClassChangeError: org.objectweb.asm.AnnotationVisitor

解决方案是从库中排除 asm jar：

<dependency>
    <groupId>com.nimbusds</groupId>
    <artifactId>nimbus-jose-jwt</artifactId>
    <version>5.1</version>
    <exclusions>
        <exclusion>
            <artifactId>asm</artifactId>
            <groupId>org.ow2.asm</groupId>
        </exclusion>
    </exclusions>
</dependency>

Answer 18

可能出现此错误的另一种情况是 Emma 代码覆盖率。

当将对象分配给接口时会发生这种情况。我想这与正在检测的对象有关，并且不再与二进制兼容。

http://sourceforge.net/tracker/?func =detail&aid=3178921&group_id=177969&atid=883351

幸运的是，Cobertura 不会出现这个问题，所以我在 pom.xml 的报告插件中添加了 cobertura-maven-plugin

Answer 19

我在取消部署和重新部署与 glassfish 的战争时遇到了这个问题。我的类结构是这样的，

public interface A{
}

public class AImpl implements A{
}

并将其更改为

public abstract class A{
}

public class AImpl extends A{
}

停止并重新启动域后，效果很好。
我使用的是 glassfish 3.1.43

Answer 20

以上所有内容 - 无论出于何种原因，我都进行了一些大型重构并开始了解这一点。我重命名了我的界面所在的包并清除了它。希望有帮助。

Answer 21

我有一个 Web 应用程序，可以在本地计算机的 tomcat(8.0.20) 上完美部署。然而，当我将它放入 qa 环境（tomcat - 8.0.20）时，它不断地给我 IncompleteClassChangeError 并抱怨我正在接口上扩展。该接口已更改为抽象类。我编译了家长和孩子的课程，但我仍然遇到同样的问题。最后，我想调试，所以，我将父级上的版本更改为 x.0.1-SNAPSHOT，然后编译所有内容，现在它可以工作了。如果有人在遵循此处给出的答案后仍然遇到问题，请确保 pom.xml 中的版本也正确。更改版本以查看是否有效。如果是，则修复版本问题。