java.lang.incompatibleclasschangeerror

Incompatible class change error:

If you read the error message Incompatibleclasschangeerror,you may understand that a class had been incompatibly changed. But you may have no idea about what causes this exception to be thrown?.Here i have presented you,some simple situations at which this exception will be thrown.Lets have a look at it.

We may all know about the binary compatibility which must be preserved when we use third party libraries in our application.

Binary Compatibility- what does it mean?

Whenever we change an application(especially a class)we should ensure that the newly modified class is compatible with pre-existing binaries(class) otherwise,you would suffer from a linkage error.

I have explained three simple reason at which this exception may arouse.

Reason 1:

Lets have two classes like class A and class B as follows.

Class A:

public class A

{

int t=10;

}

Class B:

class B

{

public static void main(String args[])

{

A r=new A();

r.t=20;

}

}

output:

Exception in thread "main" java.lang.IncompatibleClassChangeError: Expected non-

static field A.t

        at B.main(B.java:6)

If you compile and execute the class B everything will work fine and you will not get any error.Now let's change the field t (int t=10) in class A into a static field and compile the class A alone. Now if you execute the class B(without recompiling it) then a java.lang. incompatibleclass change error would be thrown.

Thus if you have compiled the classes as a whole then at the compile-time itself you would be able to identify this problem.

"Note that if you change a public or protected variable from static to non-static or vice-versa then this exception will be thrown".

Reason 2:

This limitation is not only confined to variables,it is also applicable to methods as well.Thus if you try to change a public or protected non-static method into a static method or vice-versa,at 

that time also this exception will be thrown.

Class A:

public class A

{

public static void display()

{

int t=10;

}

}

Class B:

class B

{

public static void main(String args[])

{

A r=new A();

r.display();

}

}

Output:

Exception in thread "main" java.lang.IncompatibleClassChangeError: Expecting non

-static method A.display()V

        at B.main(B.java:6)

Reason 3:

Before explaining this reason i would like to remind you all about an important thing that "whenver you add a field to an interface it may hide the field inherited from the super class ".So if you declare same variable of same type in both the interface and in the super class then this incompatible error would be thrown. Look at the following example, I have used the classes A,B,C,D and an interface Incmp as follows.

Incmp:

interface Incmp

{

//C c=new C("10");

}

Class A:

public class A

{

C c=new C("ganesh");

}

Class B:

class B extends A implements Incmp

{

public void cal()

{

Object cobject=c;

c.display();

}

}

Class C:

class C

{

String c;

public C(String s)

{

c=s;

}

public void display()

{

System.out.println(c);

}

}

Class D:

class D

{

public static void main(String args[])

{

B b=new B();

b.cal();

}

}

As you see the interface Incmp  i made those those statements as comment lines and when i execute it the everything works fine.When i remove the comment lines and compile the interface alone then this error is thrown when i execute the class D.

Output:

C:\blog>javac D.java

C:\blog>java D

ganesh

C:\blog>java D

Exception in thread "main" java.lang.IncompatibleClassChangeError: Expected non-

static field B.c

        at B.cal(B.java:5)

        at D.main(D.java:6)

It may also occur at some other situations say for example,

we know that to extend a class we need to include the extends keyword,if you use implements  keyword instead of it or vice-versa then also this exception would be thrown.Though this reason looks silly,if you have accidentally done like that,then you would be facing this error.

Note:

1.Usually this kind of  awkward situation occurs when we use third-party libraries in our application, because the new version may have changed the signature of the variable or method that exists in the older package.So in order to avoid these kind of situations read the documentation of the package fully,before using it.

2.I have also encountered this error and it is not identified at compile-time even if i have compiled the classes as a whole,but it is thrown at run-time.The reason is that,while resolving symbolic references the compiler used the older version of the package and during execution JVM used the different version,since compiler and JVM has different search strategies for searching classes.