Re: [aspectj-users] java.lang.IncompatibleClassChangeError

[Adrian Colyer <adrian.colyer@xxxxxxxxx>]

This exception is thrown when the version of a class that the VM loads
at runtime is incompatible with the version of that same class some
client was compiled with when it was built.

Typically because the client does one of the following:

* accesses a member that was visible (e.g. public) in the version it
was compiled against, but is not visible in the version of the class
now loaded
* tries to instantiate a class that was concrete at compile time but
is abstract in the loaded version of the class
* tries to invoke a method that was concrete at compile time but is
abstract in the loaded version of the class
* tries to access a member that was present at compile time but is not
present in the loaded version of the class

If for example you have an aspect making a public ITD on a type and
you compile with that aspect present, and then at runtime you load an
unwoven version of the target type then a client calling the ITD'd
member will raise an IncompatibleClassChangeError.

If you are sure that the runtime classpath contains the correctly
woven versions of your classes then the AspectJ compiler generating
code that gives an ICCError is a bug - but check the classpath first!

On 25/07/05, Charles Zhang <zhangcharles@xxxxxxxxx> wrote:
> Maybe it is too late into the night, but I can't
> figure out what this error means. This is a runtime
> error I got after compiling and weaving with no
> complains. I  I just want to ask in general what might
> have caused this from a compiler point of view. Thanks
> a lot.
> 
> Charles
> 
> 
> Yawn !!
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/aspectj-users
> 


-- 
-- Adrian
adrian.colyer@xxxxxxxxx