Over a million developers have joined DZone.

Debugging stories: IncompatibleClassChangeError

· Java Zone

Navigate the Maze of the End-User Experience and pick up this APM Essential guide, brought to you in partnership with CA Technologies

IncompatibleClassChangeError, very much like its cousin NoSuchMethodError, indicates that the class you depend on has changed since you’ve last compiled.

In my case, the jvm tells me that the method I’ve been calling has changed from static to non-static. That’s a decent enough explanation to start with. You could recompile, fix the compilation errors and should be good to go.

Or not.

I compiled my changes against the latest build of the library, libA, added libA to the classpath. No luck, the jvm says class org.foo.Test.getInstance method has changed from static to non-static. Er, it was static when I compiled?

Turns out someone had copied over the class org.foo.Test into libB, and changed the method to non-static. A transitive dependncy I had pulled in libB to my class path and here I have two incompatible definitions of the same class in my classpath. One of them gets pulled when I compile and the other when I run. (Someone has been a lazy bum!)

Tip: to find the jar containing a class,

find . -iname *.jar | while read JAR; do jar tvf $JAR | grep 'org.foo.Test' && echo $JARF ; done

Thrive in the application economy with an APM model that is strategic. Be E.P.I.C. with CA APM.  Brought to you in partnership with CA Technologies.

Topics:

Published at DZone with permission of Alosh Bennett, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

The best of DZone straight to your inbox.

SEE AN EXAMPLE
Please provide a valid email address.

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.
Subscribe

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}