The error java.lang.IncompatibleClassChangeError is seen after upgrading the APM Agent from 9.7.1 to 10.7
search cancel

The error java.lang.IncompatibleClassChangeError is seen after upgrading the APM Agent from 9.7.1 to 10.7


Article ID: 187330


Updated On:


CA Application Performance Management Agent (APM / Wily / Introscope) CA Application Performance Management (APM / Wily / Introscope) INTROSCOPE DX Application Performance Management


Getting java.lang.IncompatibleClassChangeError error on the startup of an application in WebSphere Application Server v8.5.5. This occurred after upgrading the agent version from 9.7.1 to 10.7:

10/21/19 05:19:02 PM AEDT [ERROR] [IntroscopeAgent.Agent] An error occurred while initializing service class com.wily.introscope.agent.intelligent.detection.AutomaticBoundaryDetectionService in "Introscope Automatic Boundary Detection Service".
10/21/19 05:19:02 PM AEDT [ERROR] [IntroscopeAgent.Agent] java.lang.IncompatibleClassChangeError
 at com.wily.introscope.agent.intelligent.detection.Logger.isWarningEnabled(
 at com.wily.introscope.agent.intelligent.detection.AutomaticBoundaryDetectionService.shouldStartService(
 at com.wily.introscope.agent.intelligent.detection.AutomaticBoundaryDetectionService.doStartService(
 at com.wily.introscope.agent.service.ASimpleService.IAgentService_startService(
 at com.wily.introscope.agent.service.ServiceAdministrator$ServiceInitializer.startService(
 at com.wily.introscope.agent.service.ServiceAdministrator$ServiceInitializer.startServiceSafe(
 at com.wily.introscope.agent.service.ServiceAdministrator$ServiceInitializer.IExecutableItem_execute(
 at com.wily.util.task.AsynchExecutionQueue$WrapperItem.IExecutableItem_execute(
 at com.wily.util.task.AsynchExecutionQueue.doTask(
 at com.wily.util.task.ATask$


APM Java Agent 10.x 
WebSphere Application Server


The reason that this error shows up is due to a super/parent class being modified and recompiled while the sub/child class is not. This could happen when the super class linked to 9.7.1 was left in the shared classes cache while the sub class from 10.7 refers to it instead of fresh one from 10.7.


Use one of the following command line parameters when starting the JVM:

-Xshareclasses:none starts the application without using the cache and shared classes. This can be a useful short-term solution to confirm that it is a cache related problem.

-Xshareclasses:reset starts the application, with shared classes, then clears the cache and rebuilds it. This is the recommended solution to fix a problem with the cache.

Additional Information

There could be performance impact using these parameters. These flags are not supposed to be kept for long-term use in Production. They are mainly used to test/fix certain known problems when reported. So performance impact of long-term use of these flags is not relevant. Once testing has been completed, remove the parameter from the JVM startup.

See the following link for details on the -Xshareclasses command line option.