• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

IncompatibleClassChangeError

 
Jeremy Thornton
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm encountering a java.lang.IncompatibleClassChangeError when I try to run up some code that I'm working on.
I've got a class which happens to implement an interface in the javax.activation package

If I create an instance of my class like

then call an implemented method
[CODE]
myClass.getName();
[CODE]
no problem.
However, if I cast to the Interface
DataSource stillMyClass = (DataSource)myClass;
stillMyClass.getName();
an Exception is thrown
java.lang.IncompatibleClassChangeError
I'm a bit confused as to exactly what causes this. Presumably the jar files that I'm using at runtime are different to those used to compile the class and the build process is slighly complicated so this seems possible. I've attempted to check this though and I'm *fairly* sure this isn't the case.
Any ideas as to what could be happening or how to further trace which jar files etc are being used at runtime? (any suggestions welcome).
Cheers,
Jeremy
 
Vinod Chandana
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeremy,
I don't think u need to type cast it. Just say
DataSource stillMyClass = myClass;
This should work.
Regards,
Vinod.
Originally posted by Jeremy Thornton:
I'm encountering a java.lang.IncompatibleClassChangeError when I try to run up some code that I'm working on.
I've got a class which happens to implement an interface in the javax.activation package

If I create an instance of my class like

then call an implemented method
[CODE]
myClass.getName();
[CODE]
no problem.
However, if I cast to the Interface
DataSource stillMyClass = (DataSource)myClass;
stillMyClass.getName();
an Exception is thrown
java.lang.IncompatibleClassChangeError
I'm a bit confused as to exactly what causes this. Presumably the jar files that I'm using at runtime are different to those used to compile the class and the build process is slighly complicated so this seems possible. I've attempted to check this though and I'm *fairly* sure this isn't the case.
Any ideas as to what could be happening or how to further trace which jar files etc are being used at runtime? (any suggestions welcome).
Cheers,
Jeremy
 
Jeremy Thornton
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Yup, agree.
It was doing exactly this that caused the problem to raise it's ugly head.
Just to confirm:

blows up.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
IncompatibleClassChangeError means, simply, that the class file the compiler used to represent some class is different enough from the one used at runtime to cause a problem. So what you need to do is look closely at the classpath used by your compiler and by your runtime system (depends on your environment and build system) for multiple versions of (probably) activation.jar. When you're sure everything is consistent, then recompile everything, and the problem should go away.
[ October 06, 2003: Message edited by: Ernest Friedman-Hill ]
 
Vinod Chandana
Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Jeremy,
Try myClass.getClass().getName(); The following code works for me. It could also be a problem with the paths.
Regards,
Vinod.

Originally posted by Jeremy Thornton:
Yup, agree.
It was doing exactly this that caused the problem to raise it's ugly head.
Just to confirm:

blows up.
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
[EFH]: When you're sure everything is consistent, then recompile everything, and the problem should go away.
I would add, delete all old class files, then recompile everything. You may have an out-of-date .class file that's not being recompiled because the compiler doesn't see a need.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I would add, delete all old class files, then recompile everything.

Indeed. This is implicit in my definition of recompile, but not necessarily anyone else's. Anyway, yeah, what Jim said. That's the whole point.
 
Jeremy Thornton
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm using ant to build into a clean directory.
I've got some further experiments to try before asking for further help (custom class loaders etc. involved).
Thanks for the comments so far.
 
Ernest Friedman-Hill
author and iconoclast
Marshal
Pie
Posts: 24211
35
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

I've got some further experiments to try before asking for further help (custom class loaders etc. involved).

Ahhhh. Note that the same class file loaded by two different class loaders will be incompatible classes. Normally this shouldn't happen if you're using the Java 2 class loader mechanism, but it's possible.
 
Jeremy Thornton
Ranch Hand
Posts: 91
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That does indeed seem to be the problem.
There is a class loader involved that knows about encrypted class files and one which deals with all other files. The Interface was being loaded by the encryption class loaded and the implementing class was loaded by the standard class loader leading to some run-time oddities.
Yuck.
Thanks for the help.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic