In some cases you might want to copy an object because you do not want the original object to be manipulated or just because you need more copies of that object.
After cloning an object those two object do not refer to the same space in memory (so object1 != object2 but object1.equals(object2)). They might represent the same data but when one is altered the other one does not follow.
When implementing the clone method, you must take the following into acount (from the Object class API):
By convention, the returned object should be obtained by calling super.clone. If a class and all of its superclasses (except Object) obey this convention, it will be the case that x.clone().getClass() == x.getClass().
Layne's code uses the new operator instead, thus any subclasses of the Animal class might not work correctly.
>> Why clone an object when you can just use the same object to achieve your purpose.
In that case you would not clone the object. However, what if your purpose is to create a copy that is independent of the original? Consider an object that serves as a default command. You want to keep that as-is and hand out copies.
Clone might be a good solution, but only conceptually. In fact you should not use clone because it serves no useful purpose. The idea is that you copy your object's state and its super class, and its super class and so on. There's no guarantee that will be implemented correctly or that CloneNotSupported will be thrown when necessary. Joshua Bloch, author of Effective Java, addresses all of the problems. He left out that it breaks entirely with Generics because that wasn't available at the time.
C++ had the notion of a copy constructor and you can do the same thing in Java to a degree: