如果你从事android开发。然后给一个尝试重建选项可能是为你修复。

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

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

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

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

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

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

新打包的库与旧版本不向后二进制兼容(BC)。由于这个原因，一些没有重新编译的库客户端可能会抛出异常。

这是一个完整的Java库API更改列表，这些更改可能会导致使用旧版本库构建的客户端在运行新版本库时抛出Java .lang. incompatibleclasschangeerror(即破坏BC):

非终场变为静态， 非常数场变成非静态场， 类变成接口， 接口变成类， 如果你添加了一个新的字段到类/接口(或者添加了一个新的超类/超接口)，那么一个来自客户端类C的超接口的静态字段可能会隐藏一个从C的超类继承的添加的字段(具有相同的名称)(非常罕见的情况)。

注意:还有许多其他由其他不兼容的更改引起的异常:NoSuchFieldError, NoSuchMethodError, IllegalAccessError, InstantiationError, VerifyError, NoClassDefFoundError和AbstractMethodError。

关于BC更好的论文是由Jim des Rivières撰写的“进化基于java的API 2:实现API二进制兼容性”。

还有一些自动工具可以检测这些变化:

japi-compliance-checker clirr japitools sigtest japi-checker

在你的库中使用日语遵从检查器:

japi-compliance-checker OLD.jar NEW.jar

clir工具的使用:

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

好运！

所有以上-无论出于什么原因，我做了一些大的重构，开始得到这个。我重命名了我的接口所在的包，这就清除了它。希望这能有所帮助。