Effective Java Tuesday! Override `clone` judiciously

Effective Java Review (90 Part Series)

Today we are talking about the Cloneable interface and it related clone function. Honestly I haven’t interacted any with this method in the past and after learning about it I’m not sure I really want to, it seems quite error prone. So let’s dive in and understand this method so that we can make intelligent decisions about whether to use this method or not.

So what is the Cloneable interface. It is a mixin interface that signals to users of the class that a certain action can be performed on the class. The extremely weird thing about this particular mixin is that, rather than requiring the implementation of a particular function, it merely acts as a flag that allows the implementing class to call a method on the parent class. What this means is that a user of the class that implements Cloneable can’t necessarily always call the clone method on that class without resorting to reflection and even then that might not work. All this being said, this is a part of the Object class so it pays to understand it and know how to implement the method as well as what the alternatives are. This chapter of Effective Java goes through that.

So what is the contract of Cloneable? As we learned above it doesn’t include any methods but instead acts as a flag to the protected clone method in the Object class. If a class calls the clone on Object and that class implements Cloneable, Object‘s implementation of clone will return a field-by-field copy of the object. If the class does not implement Cloneable, a CloneNotSupportedException is thrown. If this use of a interface feels weird that is good, this is not a behavior you should try to mimic in your own classes. The general (although weak) contract is as follows:

The implementing class should create a public clone class that calls into the super.clone() method.
(x.clone() != x) == true simply, clone should return a new object and not just return the current object.
(x.clone().getClass() == x.getClass() == true this is not an absolute requirement but is expected.
x.clone.equals(x) == true Again this is not an absolute requirement but does decrease the surprise of how it would work.

One could think that you could just skip calling the super.clone() method in your own clone method and simply call into a constructor to create the new object but this could cause problems for a class that extends your class and calls into super.clone() as it will return an object of the wrong class. As mentioned above, this doesn’t actually break the contract but goes against convention.

So let’s dive a little deeper into how this works and how you should implement it. The first step of implementing the clone method is to call super.clone() which will return a fully functioning replica of the calling class. If your class contains only primitives or references to immutable objects this may be all you need to do. Let’s see an example:

@Override
public Address clone() {
  try {
    return (Address) super.clone();
  } catch (CloneNotSupportedException impossible) {
    // This will never happen.
    throw new AssertionException();
  }
}