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

根据新的库重新编译客户端代码，应该就可以开始了。

更新:如果你发布了一个公共库，你应该尽可能避免做出不兼容的二进制更改，以保持所谓的“二进制向后兼容性”。单独更新依赖jar在理想情况下不会破坏应用程序或构建。如果你不得不打破二进制向后兼容性，建议增加主版本号(例如从1.x。Y到2.0.0)，然后发布更改。

新打包的库与旧版本不向后二进制兼容(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

好运！

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

While these answers are all correct, resolving the problem is often more difficult. It's generally the result of two mildly different versions of the same dependency on the classpath, and is almost always caused by either a different superclass than was originally compiled against being on the classpath or some import of the transitive closure being different, but generally at class instantiation and constructor invocation. (After successful class loading and ctor invocation, you'll get NoSuchMethodException or whatnot.)

如果这种行为看起来是随机的，那么它很可能是多线程程序类根据最先遇到的代码加载不同的传递依赖项的结果。

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

用Maven解决重复的jar最好是结合Maven下的Maven - Dependency - Plugin和Maven -enforcer- Plugin(或SBT的Dependency Graph Plugin)，然后将这些jar添加到顶级POM的一部分或作为SBT中的导入依赖元素(以删除这些依赖)。

好运！

另一种可能出现此错误的情况是Emma Code Coverage。

这发生在将Object分配给接口时。我猜这与对象被检测和不再二进制兼容有关。

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

幸运的是，这个问题在Cobertura中没有发生，所以我在pom.xml的报告插件中添加了Cobertura -maven-plugin

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

public interface A{
}

public class AImpl implements A{
}

它被改成了

public abstract class A{
}

public class AImpl extends A{
}

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

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

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

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

如果这是此错误可能发生的记录，则:

我刚刚在WAS(8.5.0.1)上得到了这个错误，在CXF(2.6.0)加载spring (3.1.1_release)配置期间，BeanInstantiationException卷起一个CXF ExtensionException，卷起一个IncompatibleClassChangeError。下面的代码片段显示了堆栈跟踪的要点:

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控制台中打开战争应用程序，并选择客户端模块。在模块配置中，将类加载设置为“parent last”。

在WAS控制台中可以找到:

应用程序->应用程序类型-> WebSphere企业应用程序 单击代表应用程序的链接(war) 点击“模块”区域下的“模块管理” 单击底层模块的链接 将“类装入器顺序”更改为“(父类最后)”。

在浪费了太多时间后记录下另一个场景。

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

我们有一个普通的jar文件，它有一个@local注释。这个类后来从这个公共项目移到我们的主ejb jar项目中。ejb jar和公共jar都捆绑在ear中。我们的公共jar依赖项的版本没有更新。因此，两个类试图成为具有不兼容的更改的东西。

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

I have a web application that deploys perfectly fine on my local machine's tomcat(8.0.20). However, when I put it into the qa environment (tomcat - 8.0.20), it kept on giving me the IncompatibleClassChangeError and it was complaining that I was extending on an interface. This interface was changed to an abstract class. And I compiled the parent and child classes and still I kept on getting the same issue. Finally, I wanted to debug, so, I changed the version on the parent to x.0.1-SNAPSHOT and then compiled everything and now it is working. If someone is still hitting the problem after following the answers given here, please make sure the versions in your pom.xml are also correct. Change the versions to see if that works. If so, then fix the version problem.

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

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

最后的答案是从本地maven repo中手动删除我的问题依赖项。旧版本的bouncycastle是罪魁祸首(我知道我只是改变了版本，这就是问题所在)，尽管旧版本没有出现在正在建造的东西中，但它解决了我的问题。我使用的是intellij版本14，然后在此过程中升级到15。

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的最终项目时。

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

这与《食人魔诗篇》第33篇中的回答相似。

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.IncompatibleClassChangeError时最热门的问题之一，所以我想记录这个特殊情况。

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

这个问题的另一个原因是，如果你为Android Studio启用了即时运行。

修复

如果发现开始出现此错误，请关闭“立即运行”。

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

Why

即时运行在开发过程中修改了大量的东西，以使它更快地提供更新到您的运行应用程序。因此，即时运行。当它起作用时，它真的很有用。然而，当出现这样的问题时，最好的办法是关闭即时运行，直到Android Studio发布下一个版本。

在我的例子中，当我添加com时出现了错误。nimbusds库在我部署在Websphere 8.5的应用程序中。 发生了以下异常:

原因:java.lang.IncompatibleClassChangeError: 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>

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

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

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

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

在我的例子中:

我有一个项目包含几个模块，包括应用程序，测试，integrationTest 我在app模块中创建了OneElementCache。 然后，我在测试模块中创建了一个文件Cache，该文件包含了一些用于在测试中创建OneElementCache的帮助。 到目前为止，一切都很完美(测试和集成测试都通过了)。 之后，我在app模块中创建了一个文件缓存。 在运行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')

原因是不同模块(app/test)的命名冲突。在测试中更改文件名就可以了。