Survey
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
[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.