Como substituir corretamente o método de clone?

Preciso implementar um clone profundo em um dos meus objetos que não tem superclasse.

Qual é a melhor maneira de lidar com o check CloneNotSupportedExceptionlançado pela superclasse (que é Object)?

Um colega de trabalho me aconselhou a lidar com isso da seguinte maneira:

@Override
public MyObject clone()
{
    MyObject foo;
    try
    {
        foo = (MyObject) super.clone();
    }
    catch (CloneNotSupportedException e)
    {
        throw new Error();
    }

    // Deep clone member fields here

    return foo;
}

Esta parece ser uma boa solução para mim, mas eu gostaria de jogá-la na comunidade StackOverflow para ver se há outras informações que posso incluir. Obrigado!

Você absolutamente tem que usar clone? A maioria das pessoas concorda que o Java cloneestá quebrado.

Josh Bloch no projeto - Construtor de cópia versus clonagem

Se você leu o item sobre clonagem em meu livro, especialmente se você leu nas entrelinhas, você saberá que acho que cloneestá profundamente quebrado. [...] é uma pena que Cloneableestá quebrado, mas acontece.

Você pode ler mais discussões sobre o tópico em seu livro Effective Java 2nd Edition, Item 11: Override clonejudiciosamente . Ele recomenda, em vez disso, usar um construtor de cópias ou uma fábrica de cópias.

Ele escreveu páginas de páginas sobre como, se você sentir que deve, você deve implementar clone. Mas ele fechou com isso:

Todas essas complexidades são realmente necessárias? Raramente. Se você estender uma classe que implementa Cloneable, terá pouca escolha a não ser implementar um clonemétodo bem comportado . Caso contrário, é melhor fornecer meios alternativos de cópia de objetos ou simplesmente não fornecer esse recurso .

A ênfase era dele, não minha.

Como você deixou claro que não tem escolha a não ser implementar clone, aqui está o que você pode fazer neste caso: certifique-se disso MyObject extends java.lang.Object implements java.lang.Cloneable. Se for esse o caso, você pode garantir que NUNCA pegará a CloneNotSupportedException. Lançar AssertionErrorcomo alguns sugeriram parece razoável, mas você também pode adicionar um comentário que explica por que o bloco catch nunca será inserido neste caso específico .

Como alternativa, como outros também sugeriram, talvez você possa implementar clonesem chamar super.clone.

Às vezes, é mais simples implementar um construtor de cópia:

public MyObject (MyObject toClone) {
}

Economiza o trabalho de manuseio CloneNotSupportedException, trabalha com finalcampos e você não precisa se preocupar com o tipo a retornar.

A maneira como seu código funciona é muito parecida com a maneira "canônica" de escrevê-lo. Eu jogaria um AssertionErrordentro da captura, no entanto. Sinaliza que essa linha nunca deve ser alcançada.

catch (CloneNotSupportedException e) {
    throw new AssertionError(e);
}

Existem dois casos em que o CloneNotSupportedExceptionserá lançado:

1. A classe que está sendo clonada não é implementada Cloneable(assumindo que a clonagem real eventualmente adie para Objecto método de clone de). Se a classe que você está escrevendo este método em implementa Cloneable, isso nunca acontecerá (já que qualquer subclasse irá herdá-lo apropriadamente).
2. A exceção é lançada explicitamente por uma implementação - esta é a maneira recomendada de prevenir a clonagem em uma subclasse quando a superclasse é Cloneable.

O último caso não pode ocorrer em sua classe (já que você está chamando diretamente o método da superclasse no trybloco, mesmo se invocado a partir de uma chamada de subclasse super.clone()) e o primeiro não deve, já que sua classe claramente deve implementar Cloneable.

Basicamente, você deve registrar o erro com certeza, mas neste caso em particular isso só acontecerá se você bagunçar a definição da sua classe. Portanto, trate-o como uma versão verificada de NullPointerException(ou semelhante) - ele nunca será lançado se seu código for funcional.

Em outras situações, você precisa estar preparado para esta eventualidade - não há garantia de que um determinado objeto seja clonável, portanto, ao capturar a exceção, você deve tomar as medidas adequadas dependendo desta condição (continue com o objeto existente, execute uma estratégia de clonagem alternativa por exemplo, serializar-desserializar, lançar um IllegalParameterExceptionse seu método requer o parâmetro por clonável, etc. etc.).

Edit : Embora no geral eu deva apontar que sim, clone()realmente é difícil implementar corretamente e para os chamadores saber se o valor de retorno será o que eles desejam, duplamente quando você considera clones profundos versus clones rasos. Muitas vezes, é melhor apenas evitar a coisa toda e usar outro mecanismo.

Use a serialização para fazer cópias profundas. Esta não é a solução mais rápida, mas não depende do tipo.

Você pode implementar construtores de cópia protegida como:

/* This is a protected copy constructor for exclusive use by .clone() */
protected MyObject(MyObject that) {
    this.myFirstMember = that.getMyFirstMember(); //To clone primitive data
    this.mySecondMember = that.getMySecondMember().clone(); //To clone complex objects
    // etc
}

public MyObject clone() {
    return new MyObject(this);
}

Por mais que a maioria das respostas aqui sejam válidas, preciso dizer que sua solução também é como os desenvolvedores de API Java reais fazem. (Josh Bloch ou Neal Gafter)

Aqui está um extrato de openJDK, classe ArrayList:

public Object clone() {
    try {
        ArrayList<?> v = (ArrayList<?>) super.clone();
        v.elementData = Arrays.copyOf(elementData, size);
        v.modCount = 0;
        return v;
    } catch (CloneNotSupportedException e) {
        // this shouldn't happen, since we are Cloneable
        throw new InternalError(e);
    }
}

Como você notou e outros mencionaram, CloneNotSupportedExceptionquase não tem chance de cair se você declarar que implementou a Cloneableinterface.

Além disso, não há necessidade de substituir o método se você não fizer nada de novo no método substituído. Você só precisa substituí-lo quando precisar fazer operações extras no objeto ou torná-lo público.

Em última análise, ainda é melhor evitá-lo e fazê-lo de outra forma.

public class MyObject implements Cloneable, Serializable{   

    @Override
    @SuppressWarnings(value = "unchecked")
    protected MyObject clone(){
        ObjectOutputStream oos = null;
        ObjectInputStream ois = null;
        try {
            ByteArrayOutputStream bOs = new ByteArrayOutputStream();
            oos = new ObjectOutputStream(bOs);
            oos.writeObject(this);
            ois = new ObjectInputStream(new ByteArrayInputStream(bOs.toByteArray()));
            return  (MyObject)ois.readObject();

        } catch (Exception e) {
            //Some seriouse error :< //
            return null;
        }finally {
            if (oos != null)
                try {
                    oos.close();
                } catch (IOException e) {

                }
            if (ois != null)
                try {
                    ois.close();
                } catch (IOException e) {

                }
        }
    }
}

Só porque a implementação do Java de Cloneable está quebrada, não significa que você não pode criar um por conta própria.

Se o propósito real do OP era criar um clone profundo, acho que é possível criar uma interface como esta:

public interface Cloneable<T> {
    public T getClone();
}

em seguida, use o construtor de protótipo mencionado antes para implementá-lo:

public class AClass implements Cloneable<AClass> {
    private int value;
    public AClass(int value) {
        this.vaue = value;
    }

    protected AClass(AClass p) {
        this(p.getValue());
    }

    public int getValue() {
        return value;
    }

    public AClass getClone() {
         return new AClass(this);
    }
}

e outra classe com um campo de objeto AClass:

public class BClass implements Cloneable<BClass> {
    private int value;
    private AClass a;

    public BClass(int value, AClass a) {
         this.value = value;
         this.a = a;
    }

    protected BClass(BClass p) {
        this(p.getValue(), p.getA().getClone());
    }

    public int getValue() {
        return value;
    }

    public AClass getA() {
        return a;
    }

    public BClass getClone() {
         return new BClass(this);
    }
}

Desta forma, você pode facilmente clonar profundamente um objeto da classe BClass sem a necessidade de @SuppressWarnings ou outro código enganoso.