What causes “java.lang.IncompatibleClassChangeError: vtable stub”?

Question

What causes "java.lang.IncompatibleClassChangeError: vtable stub"? In our application, we have seen this error pop up randomly and very seldom (just twice so far, and we run it a lot). It is not readily reproducible, even when restarting the app, using the same jvm/jars without rebuilding.

As for our build process, we clean all classes/jars and rebuild them, so it's not the same problem as others have encountered where they made a change in one class and didn't recompile some other dependent classes.

This is unlike some of the other questions related to IncompatibleClassChangeError -- none of them mention "vtable stub". In fact, there are surprisingly few google results when searching for "IncompatibleClassChangeError "vtable stub"".

Edit:

• Using JDK 1.6.0_16.
• We are not using Java serialization.
• We are not doing bytecode manipulation.
• As mentioned earlier, we are doing a "clean build", so there are no classes left over from a previous build.

Answer 1

ABI breakage in the JVM byte-code world. Look up the Javadoc: “Thrown when an incompatible class change has occurred to some class definition. The definition of some class, on which the currently executing method depends, has since changed.”

Culprits to look for would be changes to static final literal values because these get copied around in the byte code as “optimization”. EDIT: This can be as simple as the result of a library upgrade, the only fix I know of is a clean rebuild.

Answer 2

Looks like you have changed the class definition ( ie adding an extra attribute or something more weird ) and when running your previously used objects become incompatible.

Perhaps you're storing object instances somewhere ( a db the filesystem ) and then those old objects definition are unmarshalled, the error occurs.

It happened to me in the past.

For instance:

class Employee implements Serialiable {
   String name;
   String lastName;
   String address;
   ... etc 
}

The application works for a couple of weeks and some objects are stored in the filesystem in its serialized version.

Later due an application change we have to add the address as an object:

class Employee implements Serializable {
   String name;
   String lastName;
   Address address;
 }

Then the previously stored objects are reconstituted and an attempt is made to make them fit in this new description, that error may raise ( in my case it was much more complex than this ) but it may help you to look in that direction.