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

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

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

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

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

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

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

在我的例子中，当我添加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>

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

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

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

由于某种原因，当使用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时最热门的问题之一，所以我想记录这个特殊情况。

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