Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33951 > unrolled thread

java.lang.IncompatibleClassChangeError: Implementing class

Back to article view | Back to comp.lang.java.programmer

Contents

  java.lang.IncompatibleClassChangeError: Implementing class mike <mikaelpetterson@hotmail.com> - 2016-03-13 12:24 -0700
    Re: java.lang.IncompatibleClassChangeError: Implementing class Eric Sosman <esosman@comcast-dot-net.invalid> - 2016-03-13 15:54 -0400
      Re: java.lang.IncompatibleClassChangeError: Implementing class mike <mikaelpetterson@hotmail.com> - 2016-03-14 07:50 -0700

#33951 — java.lang.IncompatibleClassChangeError: Implementing class

Hi,

I posted this in the group mockito. 

https://groups.google.com/forum/#!topic/mockito/iJHYQEh9Z3I

I ran the same test cases with maven and the old version of the mocked object.
That did not give "java.lang.IncompatibleClassChangeError: Implementing class" message.

What I suspect is that I have done something in my mocked class that does not make it thread-safe anymore. Does it have to be in my mocked class or in the class it extends. To me the error message does not give me any pointers.

Does it to anyone else of you ?

br,

//mike

[toc] | [next] | [standalone]

#33953

On 3/13/2016 3:24 PM, mike wrote:
> Hi,
>
> I posted this in the group mockito.
>
> https://groups.google.com/forum/#!topic/mockito/iJHYQEh9Z3I
>
> I ran the same test cases with maven and the old version of the mocked object.
> That did not give "java.lang.IncompatibleClassChangeError: Implementing class" message.
>
> What I suspect is that I have done something in my mocked class that does not make it thread-safe anymore. Does it have to be in my mocked class or in the class it extends. To me the error message does not give me any pointers.

     Just guessing, because I've never encountered this particular
error (nor do I use Maven), BUT it doesn't appear to me that lack
of thread safety is a cause of the problem.  The JVM Specification
<http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html>
describes various causes of IncompatibleClassChangeError, and they
all seem to be involved with troubles that arise while loading,
linking, or initializing a class (or interface) that the JVM hasn't
yet seen.  If the error occurs so early in the class' life cycle,
then none of the class' code has yet had a chance to execute -- so
whatever bugs might lie in that code have not yet come into play.

     Still guessing (maybe "speculating" would be better): You mention
an "old version" of your object, suggesting that there's more than
one version floating around.  And maybe there are multiple versions
of some other classes in play, too.  Could it be that Maven has an
old version of class X in a cache somewhere, and that the old X is
incompatible with the new Y you're trying to load?

     As I said: Just guessing.

-- 
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM

[toc] | [prev] | [next] | [standalone]

#33956

Den söndag 13 mars 2016 kl. 20:54:48 UTC+1 skrev Eric Sosman:
> On 3/13/2016 3:24 PM, mike wrote:
> > Hi,
> >
> > I posted this in the group mockito.
> >
> > https://groups.google.com/forum/#!topic/mockito/iJHYQEh9Z3I
> >
> > I ran the same test cases with maven and the old version of the mocked object.
> > That did not give "java.lang.IncompatibleClassChangeError: Implementing class" message.
> >
> > What I suspect is that I have done something in my mocked class that does not make it thread-safe anymore. Does it have to be in my mocked class or in the class it extends. To me the error message does not give me any pointers.
> 
>      Just guessing, because I've never encountered this particular
> error (nor do I use Maven), BUT it doesn't appear to me that lack
> of thread safety is a cause of the problem.  The JVM Specification
> <http://docs.oracle.com/javase/specs/jvms/se8/html/jvms-5.html>
> describes various causes of IncompatibleClassChangeError, and they
> all seem to be involved with troubles that arise while loading,
> linking, or initializing a class (or interface) that the JVM hasn't
> yet seen.  If the error occurs so early in the class' life cycle,
> then none of the class' code has yet had a chance to execute -- so
> whatever bugs might lie in that code have not yet come into play.
> 
>      Still guessing (maybe "speculating" would be better): You mention
> an "old version" of your object, suggesting that there's more than
> one version floating around.  And maybe there are multiple versions
> of some other classes in play, too.  Could it be that Maven has an
> old version of class X in a cache somewhere, and that the old X is
> incompatible with the new Y you're trying to load?
> 
>      As I said: Just guessing.
> 
> -- 
> esosman@comcast-dot-net.invalid
> "Don't be afraid of work. Make work afraid of you." -- TLM

Hi

Thanks for input!

I used the command line maven:

 mvn dependency:tree

That gave me an old version of my jars.

Interesting thing was that this was not visible in eclipse at all.

Thx for pointing me in right direction.

br,

//mike

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web