CDV ❯ getCanonicalName cause java.lang.IncompatibleClassChangeError
-
Bug
-
Status: Closed
-
2 Major
-
Resolution: Fixed
-
DSO:L1
-
-
cdennis
-
Reporter: ind
-
November 24, 2010
-
0
-
Watchers: 1
-
March 24, 2011
-
December 15, 2010
Description
Caused by: java.lang.IncompatibleClassChangeError: java.util.concurrent.locks.ReentrantReadWriteLock and java.util.concurrent.locks.ReentrantReadWriteLock$DsoLock disagree on InnerClasses attribute at java.lang.Class.getDeclaringClass(Native Method) [na:1.6.0_07] at java.lang.Class.getEnclosingClass(Class.java:1085) [na:1.6.0_07] at java.lang.Class.getCanonicalName(Class.java:1169) [na:1.6.0_07]
Comments
Fiona OShea 2010-12-07
Chris Dennis 2010-12-09
You’re quite correct, the InnerClasses attributes were not being updated correctly during TC class instrumentation. I’ve just checked in a fix for this in the trunk of tim-api (http://svn.terracotta.org/fisheye/changelog/Terracotta/tim-api/trunk?cs=16801). I’m also going to code a separate fix that will go out with the next release of the TC core (3.5.0) - tim-api is not being released with this, so this has to be done independently. I’ll close this JIRA when that is complete.
Chris Dennis 2010-12-15
I have now applied a temporary fix for this in trunk (this will go out with TC core 3.5.0). The test for this asserts that it is still running against the broken tim-api version, so that we remember to remove the temporary fix when a new version of tim-api is released.
Is this something we can fix easily? i.e. don’t spend more than an hour on it