Download [#CDV-703] clone() on subclass of logical returns wrong type

Survey
yes no Was this document useful for you?
   Thank you for your participation!

* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project

Document related concepts
no text concepts found
Transcript
[CDV-703] clone() on subclass of logical returns wrong type Created: 03/Apr/08
Updated:
16/Dec/11
Status:
Project:
Component/s:
Affects
Version/s:
Fix Version/s:
Open
Community Development (Terracotta Server)
Byte Code Transform
2.5.4
Type:
Reporter:
Resolution:
Labels:
Remaining
Estimate:
Time Spent:
Original
Estimate:
Bug
Tim Eck
Unresolved
None
Not Specified
Attachments:
Issue Links:
Severity:
Fix In Branch:
Terracotta
Target:
None
Priority:
Assignee:
Votes:
2 Major
Interfaces Team
0
Not Specified
Not Specified
subclassClone.zip
Test.java
Related
relates to CDV-676 instrumented java.util.Properties clo...
Closed
3 Feature failure (but usable), workaround available
trunk
Pending
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
Comment by Alex Miller [ 03/Apr/08 ]
Linked as a possibly related issue, but not sure.
Comment by Himanshu Gupta [ 15/May/08 ]
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 :
1. We do not add this method while instrumenting the class (this will delegate the call of clone()
to its parent).
2. We add this method in the instrmented class but just call super.clone(), instead of
_tc_get_delegate_tc_java_util_ArrayList().clone().
Comment by orion [ 07/Oct/08 ]
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.
Comment by Chris Dennis [ 16/Jan/09 ]
Unlinked , as they have different causes.
Generated at Wed May 10 11:56:56 PDT 2017 using JIRA 6.2.4#6261sha1:4d2e6f6f26064845673c8e7ffe9b6b84b45a6e79.