The error java.lang.IncompatibleClassChangeError: Implementing class means that a class was compiled to implement an interface, but at runtime the JVM found a class with that name instead of an interface, so it refuses to load the implementing class. The type changed from an interface to a class between compile time and run time, nearly always because two versions of the same library are on the classpath.
We meet it most often with old libraries that generate code at runtime, such as cglib on top of the ASM bytecode library, and in apps where a jar was upgraded without recompiling the code that depends on it. The following example is a class compiled against version 1.0 of a pricing library, where PriceRule is an interface.
public interface PriceRule {
int apply(int cents);
}public class HalfPrice implements PriceRule {
public int apply(int cents) {
return cents / 2;
}
}PriceRule rule = new HalfPrice();
int price = rule.apply(900); // 450 with version 1.0 on the classpathNotice that nothing in HalfPrice is wrong. When version 2.0 of the library turns PriceRule into an abstract class and replaces the 1.0 jar, the same HalfPrice.class fails at runtime. We reproduce the error on Java 8 and Java 25, explain the classic cglib and ASM case, find the conflicting jar with Maven and JVM logging, and replace cglib on modern Java.
1. What the Error Means
The compiler checks our code against the library versions on the build classpath and records the result in the class file. The JVM checks the same facts again when it loads the class, against whatever versions are on the runtime classpath. When a type changed its kind in between, the JVM throws IncompatibleClassChangeError while linking the class, before any of our code in it runs.
The rule for interfaces is part of class loading in section 5.3.5 of the JVM specification. Every type that a class lists after implements must be an interface, and every type after extends must be a class. Java 8 reports a broken implements with the short text Implementing class, whereas current JDKs, such as Java 25, name both types in the message.
| Change between compile time and run time | Message on Java 8 | Message on Java 25 |
|---|---|---|
| Interface became a class, and our class implements it | Implementing class | class HalfPrice can not implement PriceRule, because it is not an interface |
| Class became an interface, and our class extends it | class Sub has interface Base as super class | Same message |
| A method or field was removed | NoSuchMethodError or NoSuchFieldError | Same, both are subclasses of IncompatibleClassChangeError |
The fix is never in the class named in the message; it is in the classpath, which has to contain one single version of the library that the code was compiled against.
2. Reproducing the Error
Version 2.0 of the pricing library changes PriceRule into an abstract class, for example to add shared code. Code compiled against 2.0 uses extends, but our HalfPrice.class was compiled against 1.0.
// pricing-rules 2.0: does not compile in the same project as version 1.0 above
public abstract class PriceRule {
public abstract int apply(int cents);
}We compiled HalfPrice and a small Main class against 1.0 and ran them with the 2.0 class first on the classpath. Java 8 (8u504) prints the short message.
Exception in thread "main" java.lang.IncompatibleClassChangeError: Implementing class
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:756)Java 25 prints the same error with the two type names, which makes the search for the conflicting jar much shorter.
Error: Unable to initialize main class Main
Caused by: java.lang.IncompatibleClassChangeError: class HalfPrice can not implement PriceRule, because it is not an interface (PriceRule is in unnamed module of loader 'app')Recompiling HalfPrice against 2.0 turns the runtime error into a compile error, which is the better place to find it. The real fix is to decide on one version, and update the code if we pick 2.0.
3. The cglib and ASM Version Conflict
Most reports of this error come from cglib, a code generation library used by older versions of Hibernate, Spring, Mockito and many other frameworks to create proxy classes at runtime. Old cglib releases, up to 2.2, were compiled against ASM 3, where org.objectweb.asm.ClassVisitor is an interface. ASM 4 changed ClassVisitor into an abstract class, as javap shows for both jars.
javap -cp asm-3.3.1.jar org.objectweb.asm.ClassVisitor
javap -cp asm-4.0.jar org.objectweb.asm.ClassVisitorpublic interface org.objectweb.asm.ClassVisitor {
public abstract class org.objectweb.asm.ClassVisitor {A billing service from 2012 uses Hibernate 3 (which pulls in cglib 2.2 and ASM 3) and later adds a newer library that depends on ASM 9. Both ASM jars contain the package org.objectweb.asm, and whichever jar comes first on the classpath wins. If the newer ASM wins, cglib’s classes no longer match it, and the app fails during startup with Implementing class on Java 8, or with a related IncompatibleClassChangeError such as the following one on Java 25.
Exception in thread "main" java.lang.IncompatibleClassChangeError: class net.sf.cglib.core.DebuggingClassWriter overrides final method org.objectweb.asm.ClassWriter.visit(IILjava/lang/String;Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;)V
at java.base/java.lang.ClassLoader.defineClass1(Native Method)Maven cannot settle the conflict for us, because the two ASM generations use different group IDs, asm and org.ow2.asm. For Maven, they are two unrelated artifacts, so it keeps both.
mvn dependency:tree -Dincludes=asm,org.ow2.asm[INFO] com.example:billing:jar:1.0
[INFO] +- cglib:cglib:jar:2.2:compile
[INFO] | \- asm:asm:jar:3.1:compile
[INFO] \- org.ow2.asm:asm:jar:9.10.1:compileFor an app that has to stay on old cglib, there are two ways to make the classpath consistent.
- Replace cglib with cglib-nodep, which contains its own renamed copy of ASM and does not clash with other ASM versions.
- Exclude asm:asm from the cglib dependency and upgrade cglib to a release built for the ASM version the rest of the app uses.
4. Replacing cglib on Modern Java
Upgrading cglib does not help much today. The cglib project describes itself as unmaintained and as not working well on JDK 17 and later. We ran cglib 2.2 and 3.3.0 on JDK 25, and both failed before creating the first proxy.
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make protected final java.lang.Class java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int,java.security.ProtectionDomain) throws java.lang.ClassFormatError accessible: module java.base does not "opens java.lang" to unnamed moduleThe JVM option –add-opens java.base/java.lang=ALL-UNNAMED makes cglib 3.3.0 work again, but it switches off a module protection for the whole app. The long-term fix is to move away from cglib.
- In Spring applications, let Spring create the proxies. Spring Framework ships its own repackaged copy of cglib in spring-core under org.springframework.cglib, which works on Java 25 and never clashes with another cglib or ASM jar. Spring AOP uses it for class-based proxies.
- Hibernate 5.3 and later and Mockito 2 and later use Byte Buddy instead of cglib, so upgrading those frameworks removes cglib from the classpath.
- Our own proxy code can move to Byte Buddy, which is maintained and supports the current Java versions.
The following example creates a subclass proxy of a Greeter class with Byte Buddy 1.18.14 on JDK 25, the same kind of proxy that cglib’s Enhancer creates.
public class Greeter {
public String hi() {
return "hi";
}
}Greeter proxy = new ByteBuddy()
.subclass(Greeter.class)
.method(named("hi")).intercept(FixedValue.value("hello from a proxy"))
.make()
.load(Greeter.class.getClassLoader())
.getLoaded()
.getDeclaredConstructor()
.newInstance();
String reply = proxy.hi(); // "hello from a proxy"The idea of a proxy class that overrides methods of the original is covered in the proxy design pattern article.
5. Finding the Jar That Causes the Conflict
The message names the two types, so the next question is which jar each one came from. Three tools answer it, and they work for every IncompatibleClassChangeError and its subclasses, not only for cglib.
The first tool is the class loading log of the JVM. The option -Xlog:class+load=info prints the source of every loaded class, and filtering it for the type in the message shows the jar that won.
java -Xlog:class+load=info -cp rules-2.0.jar:app Main | grep PriceRule[0.066s][info][class,load] PriceRule source: file:/opt/app/lib/rules-2.0.jarThe second tool is the dependency report of the build. In Maven, mvn dependency:tree -Dincludes=groupId filters the tree as shown in section 3; in Gradle, ./gradlew dependencyInsight –dependency asm does the same. Inside a running app, a class can report its own jar.
URL source = ByteBuddy.class.getProtectionDomain().getCodeSource().getLocation();
String jar = Path.of(source.toURI()).getFileName().toString(); // "byte-buddy-1.18.14.jar"The third tool is javap, which shows whether a type in a given jar is a class or an interface, as we did for ClassVisitor. With the jar found, we remove the duplicate, align the versions through a BOM or dependencyManagement, and add the Maven Enforcer rule dependencyConvergence so the build fails the next time two versions meet.
A stale build can cause the same error without any duplicate jar. If a library module changed an interface into a class and only that module was rebuilt, old class files in target/classes or in an IDE output folder still refer to the interface, and mvn clean install fixes it.
6. IncompatibleClassChangeError FAQs
A classpath with two library versions is behind almost every one of these questions, so most answers point back to finding that jar.
6.1. Is IncompatibleClassChangeError an exception I can catch?
Technically yes, but catching it does not help. It extends LinkageError, which extends Error, and the class that failed to load stays unusable for the rest of the run. Where errors sit in the hierarchy is explained in checked vs unchecked exceptions.
6.2. How is it different from NoSuchMethodError?
A NoSuchMethodError is a subclass of IncompatibleClassChangeError for one specific change, a method that existed at compile time and is missing at run time. The parent class covers the remaining changes, such as an interface that became a class or a static field that became an instance field.
6.3. Why does the error appear only on the server and not on my laptop?
Because the server has a different classpath. Application servers add their own libraries, and a shared lib folder or a fat jar built differently can put a second version of a library first. Compare the -Xlog:class+load output of both machines.
6.4. Can –add-opens fix IncompatibleClassChangeError?
No. The –add-opens option fixes InaccessibleObjectException from old cglib on Java 17 and later, which is a different problem. An IncompatibleClassChangeError needs a consistent classpath.
7. Conclusion
The message IncompatibleClassChangeError: Implementing class, and its longer form can not implement X, because it is not an interface, means the runtime classpath has a different version of a type than the one our code was compiled against. The class named in the message is fine; the classpath is not.
We find the winning jar with -Xlog:class+load, the dependency tree or the class’s code source, keep a single version, and rebuild cleanly. For the classic cglib and ASM case, cglib-nodep is the short-term fix, and Spring’s built-in proxies or Byte Buddy are the long-term one on Java 17 and later.
8. References
- IncompatibleClassChangeError Javadoc (Java 25)
- JVM Specification, Deriving a Class from a class File Representation
- cglib project on GitHub
- Byte Buddy
- Maven Enforcer, Dependency Convergence
Happy Learning !!
Hi, I need help to solve the problem.
Even am also facing the issue while starting of Tomcat 8.5.24 server and received the below error. Can you suggest exact solution for this?
Thanks, it’s working
I am facing the issue while starting of Tomcat 7 server and received the below error. I have tried the suggestion provided by you but it is not working.
Can you please help on priority basis? Thanks
Thanks Lokesh! I was struggling for the jars version mismatch.
Exception in thread "Thread-29" java.lang.IncompatibleClassChangeError: Implemen ting class at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(ClassLoader.java:631) at java.lang.ClassLoader.defineClass(ClassLoader.java:615) at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:14 1) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(Webapp ClassLoader.java:2818) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoa der.java:1159) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa der.java:1647) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoa der.java:1526) at au.com.ezidebit.px.PCIServiceStub.getPolicy(PCIServiceStub.java:2419) at au.com.ezidebit.px.PCIServiceStub.populateAxisService(PCIServiceStub. java:57) at au.com.ezidebit.px.PCIServiceStub.(PCIServiceStub.java:204) at au.com.ezidebit.px.PCIServiceStub.(PCIServiceStub.java:193) at au.com.ezidebit.px.PCIServiceStub.(PCIServiceStub.java:241) at au.com.ezidebit.px.PCIServiceStub.(PCIServiceStub.java:233) at com.sapienter.jbilling.server.payment.tasks.EzidebitPaymentTask.proce ss(EzidebitPaymentTask.java:91) at com.sapienter.jbilling.server.process.BillingProcessSessionBean.email AndPayment(BillingProcessSessionBean.java:523) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflecti on(AopUtils.java:309) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJo inpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:150) at org.springframework.transaction.interceptor.TransactionInterceptor.in voke(TransactionInterceptor.java:110) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynami cAopProxy.java:202) at $Proxy98.emailAndPayment(Unknown Source) at com.sapienter.jbilling.server.process.BillingProcessSessionBean.proce ssEntity(BillingProcessSessionBean.java:265) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflecti on(AopUtils.java:309) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJo inpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:150) at org.springframework.transaction.interceptor.TransactionInterceptor.in voke(TransactionInterceptor.java:110) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynami cAopProxy.java:202) at $Proxy98.processEntity(Unknown Source) at com.sapienter.jbilling.server.process.BillingProcessSessionBean.proce ssEntity(BillingProcessSessionBean.java:777) at com.sapienter.jbilling.server.process.BillingProcessSessionBean.trigg er(BillingProcessSessionBean.java:695) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflecti on(AopUtils.java:309) at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJo inpoint(ReflectiveMethodInvocation.java:183) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:150) at org.springframework.transaction.interceptor.TransactionInterceptor.in voke(TransactionInterceptor.java:110) at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed( ReflectiveMethodInvocation.java:172) at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynami cAopProxy.java:202) at $Proxy98.trigger(Unknown Source) at com.sapienter.jbilling.server.util.WebServicesSessionSpringBean$1.run (WebServicesSessionSpringBean.java:2581) at java.lang.Thread.run(Thread.java:662)Have you tried the solution suggested in post?
hi
i chaged a class file which is a part of jar file.
It was compiled and running succesfully in my local but when we deployed from server end it was throwing the below exception.
Exception in thread "main" java.lang.IncompatibleClassChangeError at mapfre.trn.saptron.SapCon.getConexion(SapCon.java:745) at mapfre.trn.saptron.SapCon.getConexion(SapCon.java:714) at mapfre.com.c.GUI.TTextField.lanzaValidacionOracleInterno(TTextField.j ava:3784) at mapfre.com.c.GUI.TTextField.validacionMetodo(TTextField.java:3931) at mapfre.com.c.GUI.TTextField.lanzaValidacion(TTextField.java:3140) at mapfre.trn.utilidades.JMenuTron.preJmenuTron(JMenuTron.java:87) at mapfre.trn.utilidades.JMenuTron.main(JMenuTron.java:73)Can you be specific what change you made? It can be triggered for many reasons such as changing static variable to non-static or vice-versa; declaring a new field which hides any super class field and things like that. Please note that it may trigger even when JVM versions at your local and prod are different.
I am getting this
INFO: Starting service Catalina Apr 30, 2014 4:25:05 AM org.apache.catalina.core.StandardEngine startInternal INFO: Starting Servlet Engine: Apache Tomcat/7.0.12 java.lang.IncompatibleClassChangeError: Implementing class at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1148) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1643) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at java.lang.ClassLoader.defineClass1(Native Method) at java.lang.ClassLoader.defineClassCond(Unknown Source) at java.lang.ClassLoader.defineClass(Unknown Source) at java.security.SecureClassLoader.defineClass(Unknown Source) at org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassLoader.java:2818) at org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.java:1148) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1643) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1521) at org.apache.catalina.startup.ContextConfig.checkHandlesTypes(ContextConfig.java:1956) at org.apache.catalina.startup.ContextConfig.processAnnotationsStream(ContextConfig.java:1919) at org.apache.catalina.startup.ContextConfig.processAnnotationsJar(ContextConfig.java:1806) at org.apache.catalina.startup.ContextConfig.processAnnotationsUrl(ContextConfig.java:1765) at org.apache.catalina.startup.ContextConfig.processAnnotations(ContextConfig.java:1751) at org.apache.catalina.startup.ContextConfig.webConfig(ContextConfig.java:1255) at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:882) at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:317) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:119) at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:89) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5081) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033) at org.apache.catalina.core.StandardHost.startInternal(StandardHost.java:774) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1033) at org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:291) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.StandardService.startInternal(StandardService.java:443) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:727) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:145) at org.apache.catalina.startup.Catalina.start(Catalina.java:620) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source) at java.lang.reflect.Method.invoke(Unknown Source) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:303) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:431)Problem solved or still facing issue after trying the fix provided in post??
Hi I need help!!!!!! My problem is
I see this for the first time in my life!! Can you help me please?
Check if you configured something like this: https://stackoverflow.com/questions/5714053/how-can-we-redirect-a-java-program-console-output-to-multiple-files