CDV ❯ clone() on subclass of logical returns wrong type
-
Bug
-
Status: Open
-
2 Major
-
Resolution:
-
Byte Code Transform
-
-
interfaces
-
Reporter: teck
-
April 03, 2008
-
0
-
Watchers: 1
-
December 16, 2011
-
Attachments
Description
Attached is a sample showing the problem. Without DSO, the type of the clone is Test$MyList. When DSO instruments this class, clone() ends up getting called on the delegate which is of type ArrayList
Comments
Alex Miller 2008-04-03
Abhishek Singh 2008-04-03
Need to uncomment the call call to testSubClass() in HashtableCloneTestApp.runTest() after fixing this.
Himanshu Gupta 2008-05-15
Hi,
I have attached the instrumented version of this class. In this class i can see clone method as follows
public Object clone() \{
return \_\_tc\_get\_\_delegate\_tc\_java\_util\_ArrayList().clone();
\}
A call to clone on MyList turns into a call to ArrayList.clone() and hence the Assertion error.
Possible solution :
- We do not add this method while instrumenting the class (this will delegate the call of clone() to its parent).
- We add this method in the instrmented class but just call super.clone(), instead of __tc_get__delegate_tc_java_util_ArrayList().clone().
orion 2008-10-07
Alex thinks this might be a workaround:
I believe if you avoid calling super.clone() and just build the object
yourself, that would work:
public Object clone() { SegmentInfos a = new SegmentInfos(); // set fields of a return a; }
Also, it looks like SegmentInfos.clone() probably makes a deep clone
of the SegmentInfo objects it holds, so you’d need to do that as
well. I don’t think you’d have any problems there calling
SegmentInfo.clone().
The problem arises in this case due to a combination of the logical
instrumentation of Vector and the call to native clone(), which makes
instrumentation more challenging.
Chris Dennis 2009-01-16
Unlinked CDV-391, as they have different causes.
Linked CDV-391 as a possibly related issue, but not sure.