What Causes Java.Lang.Incompatibleclasschangeerror

What causes java.lang.IncompatibleClassChangeError?

This means that you have made some incompatible binary changes to the library without recompiling the client code. Java Language Specification §13 details all such changes, most prominently, changing non-static non-private fields/methods to be static or vice versa.

Recompile the client code against the new library, and you should be good to go.

UPDATE: If you publish a public library, you should avoid making incompatible binary changes as much as possible to preserve what's known as "binary backward compatibility". Updating dependency jars alone ideally shouldn't break the application or the build. If you do have to break binary backward compatibility, it's recommended to increase the major version number (e.g. from 1.x.y to 2.0.0) before releasing the change.

What is a IncompatibleClassChangeError exception in Java?

It means that at some point, an interface was changed to a class, but an implementer of the original interface was not modified and recompiled to accommodate this (incompatible) change.

For example, consider the following types:

interface Fooable {
void foo();
}

class FooImpl implements Fooable {
public void foo() {
/* Do something... */
}
}

Now suppose Fooable is modified and recompiled, but FooImpl is not:

abstract class Fooable {
public abstract void foo();
}

java.lang.IncompatibleClassChangeError: Implementing class

Include the suitable version of cglib in your class path.For eg

<dependency>
<groupId>cglib</groupId>
<artifactId>cglib</artifactId>
<version>2.2.2</version>
</dependency>

How to fix java.lang.IncompatibleClassChangeError: Implementing class with cxf

An IncompatibleClassChangeError happens because some code was compiled against one version of an API, but at runtime an incompatible version of the API is being loaded.

(In this case, the "Implementing class" incompatibility means that a class has been declared as implements Something, but at runtime the Something turns out to be a class rather than an interface. This API change is not allowed.)

The problem is that the stacktrace you have included doesn't tell us what class the incompatibility occurs in, and what it is incompatible with. The only real clue is that CXF appears to be loading an "provider"

So what is the solution?

There is no silver bullet. You will need to do some digging to find out what the actual problem is:

  1. Check the logs where you got the stacktrace from for other log messages that may tell you what was being loaded.
  2. Check the versions of the various CXF JAR files on the runtime platform.
  3. Check that you don't have different versions of the JARs in the webapp itself and in Tomcat's shared library directories.
  4. Modify Tomcat logging configs to set up logging level for the org.apache.catalina.loader package to DEBUG. This will log the JAR file that each class is loaded from.


Related Topics



Leave a reply



Submit