Friday, June 13, 2008

Deep Copy Implementation in Java - Source Code


Find below two images having two Java Classes used for implementing Deep Copy in Java using clone() method overriding approach. Click the images to enlarge them.








Share/Save/Bookmark


Posted by Geek at 10:14 PM

Related Articles...



Labels:

3 comments:

Pret said...

Hello,
Though clone() provides efficient deep copy of objects, it poses a problem of maintainability. You have to write clone() for each new class you create.

Instead, it would be much easier to maintain and relatively faster to write a utility Class which uses the ByteArray streams to serialize, copy and then de-serialize the objects.

Below is the code. I'm not sure if it maintains the formatting when displaying the comments part of this blog. It compiles.

public class Copy
{
public static <T> T deepCopy(final T sourceObject) throws IOException, ClassNotFoundException

{
T result = null;

// serialize
ByteArrayOutputStream bos = new ByteArrayOutputStream(1000);
ObjectOutputStream out = new ObjectOutputStream(bos);
out.writeObject(sourceObject);

out.flush();
out.close();

// de-serialize
ByteArrayInputStream bin = new ByteArrayInputStream(bos.toByteArray());
ObjectInputStream in = new ObjectInputStream(bin);

try {
result = (T) in.readObject();
}
catch (ClassNotFoundException cnfe) {
throw new IOException(cnfe);
}
finally {
in.close();
}
return result;
}
}

September 23, 2009 at 11:02 PM
Geek said...

Serialization/De-Serialization can certainly be used as an alternative to cloning for deep-copy of objects, but cloning has its own advantages which makes it a better choice in many cases.

One of them is performance, which you have already mentioned. Just to add, the difference in performance between the two is too much to be ignored, especially for a performance critical application. Creating a socket, serializing an object, passing it through the socket, and then de-serializing it would often be quite slow as compared to calling methods in existing objects... right?

Other obvious problems which might make one to prefer cloning over serialization in certain cases are: transient variables can only have Java language defaults in case of serialization, change of class definition (add/del of instance variables) would pose problems in serialization if two different class versions are being used in two different JVMs. More details can be found in this article - InvalidClassException in Java

The gotchas explained above are only the obvious ones and there might be few more.

But, this does not take away the fact that serialization is a great feature of Java having its own usage (like in RMI) and so is cloning.

I personally don't see them competing with each other instead they look like complementing each other - providing programmers two ways to choose from depending on what suits the underlying situation better.

Sounds fine? Thanks for your feedback. Keep posting!

October 4, 2009 at 4:18 PM
Pret said...

True. Cloning and Serialization complement each other.

I am forced to use Serialization in my present project as clone() would simply be too much work because of the inheritances and many members being Lists of Objects.

I'm facing a huge problem with performance, especially during socket read(), which I am trying to overcome.

If you do have tips to improve performance with serialization, do post. I wil too, if I solve it.

Thank you.

November 11, 2009 at 7:02 PM

Post a Comment

Subscribe to: Post Comments (Atom)