I have also discovered that, when using JNI, invoking a Java method from C++, if you pass parameters to the invoked Java method in the wrong order, you will get this error when you attempt to use the parameters inside the called method (because they won't be the right type). I was initially taken aback that JNI does not do this checking for you as part of the class signature checking when you invoke the method, but I assume they don't do this kind of checking because you may be passing polymorphic parameters and they have to assume you know what you are doing.

示例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...
        }
    }
}

In my case, I ran into this error this way. pom.xml of my project defined two dependencies A and B. And both A and B defined dependency on same artifact (call it C) but different versions of it (C.1 and C.2). When this happens, for each class in C maven can only select one version of the class from the two versions (while building an uber-jar). It will select the "nearest" version based on its dependency mediation rules and will output a warning "We have a duplicate class..." If a method/class signature changes between the versions, it can cause a java.lang.IncompatibleClassChangeError exception if the incorrect version is used at runtime.

高级:如果A必须使用C的v1, B必须使用C的v2，那么我们必须在A和B的poms中重新定位C，以避免类冲突(我们有一个重复类警告)，当构建依赖于A和B的最终项目时。

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

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

幸运的是，该异常有一个“message”成员，它提供了关于出错原因的更详细信息。在我的例子中，消息清楚地说，特定的类应该实现特定的接口，但它实际上并没有实现它。

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

我在与玻璃鱼的战争中反复部署时遇到过这个问题。我的班级结构是这样的，

public interface A{
}

public class AImpl implements A{
}

它被改成了

public abstract class A{
}

public class AImpl extends A{
}

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

如果你使用scala和sbt和scala-logging作为依赖项，那么这可能会发生，因为scala-logging的早期版本的名称是scala-logging-api.因此，本质上依赖项解析不会发生，因为不同的名称会导致启动scala应用程序时的运行时错误。