Serializing Begets Deep Cloning?

I was reading an article written by an ASF contributor, and he briefly mentioned that an "old Java trick" to deep clone an object is to serialize it and then deserialize it back into another object. When I read this I paused, and thought "hey, that's pretty smart." Unfortunately neither deep cloning, nor serialization, were the subject of the article, and so the author never gave an example of what he was talking about, and online searches haven't pulled back anything along these lines.

I have to assume, we're talking about something that looks like this:

public class Dog implements Serializable
{
    // ...

    public Dog deepClone()
    {
        Dog dogClone = null;
        try
        {
            FileOutputStream fout = new FileOutputStream("mydog.dat");
            ObjectOutputStream oos = new ObjectOutputStream(fout);
            oos.writeObject(this);
            oos.close();

            FileInputStream fin = new FileInputStream("mydog.dat");
            ObjectInputStream ois = new ObjectInputStream(fin);
            dogClone = (Dog)ois.readObject();
            ois.close();

            return dogClone;
        }
        catch(Ex开发者_开发问答ception e)
        { 
            // Blah
        }
    }

Provided that I might be off a little bit (plus or minus a few lines of code), is this a generally-accepted practice for deep cloning an object? Are there any pitfalls or caveats to this method?

Are there synching/concurrency/thread-safety issues not addressed?

Because if this is a best-practices way of deep cloning objects, I'm going to use it religiously.

This is one common practice for deep-clonging. The drawbacks are:

1. It is generally slow to do a serialization/deserialization. Custom cloning is faster.

2. It only clones serializable objects, obviously

3. It is difficult to know what you serialize. If your dog has an upwards pointer to some larger structure (pack of dogs), cloning a dog may clone a hundred other dogs if you don't pay attention. A manual clone of Dog would probably simply ignore the pack reference, creating a new individual dog object with the same properties, perhaps referencing the same pack of dogs, but not cloning the pack.

Thread safety is not different from doing a manual clone. The properties will most likely be read sequentially from the source object by the serializer, and unless you take care of thread safety you may clone a dog that is partially changed while cloning.

So I'd say it is probably not advisable to use this all the time. For a really simple object, making a simple manual clone/copy-constructor is simple and will perform much better. And for a complex object graph you may find that this runs the risk of cloning things you didn't intend to. So while it is useful, it should be used with caution.

By the way, in your example I'd use a memory stream rather than a file stream.