これは、一部のクラス定義に互換性のないクラス変更が発生した場合にスローされます。現在実行中のメソッドが依存する一部のクラスの定義が変更されました。通常、基底クラスの非最終フィールドが静的になるとき、または基底クラスがインターフェースに変わるとき (およびその逆) などでスローされます。 IncompatibleClassChangeError は、基底クラスから発生する問題に関連する LinkageError を拡張します。子クラスのコンパイル後に変更されます。
ここでもっと読んでください
http://examples.javacodegeeks.com/java-basics/exceptions/java-lang-incompatibleclasschangeerror-how-to-resolve-incompatible-class-change-error/
http://howtodoinjava.com/2013/05/25/solved-java-lang-incompatibleclasschangeerror-implementing-class/
新しくパッケージ化されたライブラリは、古いバージョンと後方バイナリ互換性 (BC) がありません。このため、再コンパイルされていない一部のライブラリ クライアントは例外をスローする場合があります。
これは、古いバージョンのライブラリで構築されたクライアントが新しいバージョンで実行された場合に java.lang.IncompatibleClassChangeError をスローする可能性がある Java ライブラリ API の変更の完全なリストです (つまり、BC を壊します)。
非最終フィールドは静的になり、非定数フィールドは非静的になり、クラスはインターフェースになり、インターフェースはクラスになり、クラス/インターフェースに新しいフィールドを追加する(または新しいスーパークラス/スーパーインターフェースを追加する)と、静的フィールドになりますクライアントクラスのスーパーインターフェースから C は、C のスーパークラスから継承された (同じ名前の) 追加されたフィールドを非表示にする場合があります (非常にまれなケース)。注: 他の互換性のない変更によって発生する例外は他にも多数あります: NoSuchFieldError、NoSuchMethodError、IllegalAccessError、InstantiationError、VerifyError、NoClassDefFoundError、AbstractMethodError。
BC に関するより良い論文は、Jim des Rivières によって書かれた「Evolving Java-based APIs 2: Achifying API Binary Compatibility」です。
このような変更を検出するための自動ツールも多数あります。
japi-compliance-checker clirr japitools sigtest japi-checker ライブラリ (*.jar) での 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