View source for Clone (Java method)

{{lowercase}}
'''<code>clone()</code>''' is a method in the [[Java (programming language)|Java programming language]] for object duplication. In Java, objects are manipulated through reference variables, and there is no operator for ''copying'' an object—the assignment operator duplicates the reference, not the object. The clone() method provides this missing functionality.

== Overview ==
Classes that want copying functionality must implement some method to do so. To a certain extent that function is provided by "<code>Object.clone()</code>".

<code>clone()</code> acts like a copy constructor. Typically it calls the <code>clone()</code> method of its superclass to obtain the copy, etc. until it eventually reaches <code>Object</code>'s <code>clone()</code> method. The special <code>clone()</code> method in the base class <code>Object</code> provides a standard mechanism for duplicating objects.

The class <code>Object</code>'s <code>clone()</code> method creates and returns a copy of the object, with the same class and with all the fields having the same values. However, <code>Object.clone()</code> throws a <code>CloneNotSupportedException</code> unless the object is an instance of a class that implements the [[Marker interface pattern|marker interface]] <code>Cloneable</code>.

The default implementation of <code>Object.clone()</code> performs a shallow copy. When a class desires a deep copy or some other custom behavior, they must implement that in their own <code>clone()</code> method after they obtain the copy from the superclass.

The syntax for calling <code>clone</code> in Java is (assuming <code>obj</code> is a variable of a class type that has a public <code>clone()</code> method):
<source lang="java">
Object copy = obj.clone();
</source>
or commonly
<source lang="java">
MyClass copy = (MyClass) obj.clone();
</source>
which provides the [[Type conversion|typecast]]ing needed to assign the general <code>Object</code> reference returned from <code>clone</code> to a reference to a <code>MyClass</code> object.

One disadvantage with the design of the <code>clone()</code> method is that the return type of <code>clone()</code> is <code>Object</code>, and needs to be explicitly cast back into the appropriate type. However, overriding <code>clone()</code> to return the appropriate type is preferable and eliminates the need for casting in the client (using covariant return types, since J2SE 5.0).

Another disadvantage is that one often cannot access the <code>clone()</code> method on an abstract type. Most interfaces and abstract classes in Java do not specify a public <code>clone()</code> method. As a result, often the <code>clone()</code> method can only be used if the actual class of an object is known, which is contrary to the abstraction principle of using the most generic type possible. For example, if one has a <code>List</code> reference in Java, one cannot invoke <code>clone()</code> on that reference because <code>List</code> specifies no public <code>clone()</code> method. Actual implementations of <code>List</code> like <code>ArrayList</code> and <code>LinkedList</code> all generally have <code>clone()</code> methods themselves, but it is inconvenient and bad abstraction to carry around the actual class type of an object.

==Alternatives==
There are alternatives to <code>clone()</code>, notably the use of a [[Copy constructor|copy constructor]] - a constructor that accepts as a parameter another instance of the same class - or a [[Factory method pattern|factory method]]. These methods are not always adequate when the concrete type of the cloned object is not known in advance. (However, <code>clone()</code> is often not adequate either for the same reason, as most abstract classes do not implement a public <code>clone()</code> method.)

Also the use of serialization and deserialization is an alternative to using clone.

==Singleton pattern==
When writing a class using the [[Singleton pattern]], only one instance of that class can exist at a time. As a result, the class must not be allowed to make a clone. To prevent this, one can override the <code>clone()</code> method using the following code:
<source lang="java">
public Object clone() throws CloneNotSupportedException {
    throw new CloneNotSupportedException();
}
</source>
This is only necessary if a superclass implements a public <code>clone()</code> method, or to prevent a subclass from using this class's <code>clone()</code> method to obtain a copy. Classes don't usually inherit a public <code>clone()</code> method because <code>Object</code> doesn't have a public <code>clone()</code> method, so it is usually unnecessary to explicitly implement a non-functional <code>clone()</code> method.

==Class hierarchy==
To provide a properly cloneable object of any type, the clone() method must be both declared correctly and implemented correctly according to the convention described in Object.clone().

1) Every type that needs to be cloned must have a public clone() method in its own class or a publicly accessible clone() method in one of its parent classes.

Example:

To invoke clone() on varY1, which is of type Y, then Y or a parent of Y must declare a publicly accessible clone() method. Here, it is the parent class X that provides the public clone() method.

<source lang="java">
public class X implements Cloneable {
    public X clone() throws CloneNotSupportedException {
        return (X) super.clone();
    }
}

public class Y extends X { }

public class Z extends Y { }

public class test1 {
    public void function() throws CloneNotSupportedException {
        Y varY1 = new Z();
        Y varY2 = (Y) varY1.clone();
    }
}
</source>

2) Every class that implements clone() should call super.clone() to obtain the cloned object reference. If the class has any object references that must be cloned as well (when deep copying, for example), then the clone() method should perform any required modifications on the object before returning it. (Since Object.clone() returns an exact copy of the original object, any mutable fields such as collections and arrays would be shared between the original and the copy - which in most cases would neither be expected nor desired.)

Example:

Since class Z contains an object reference, its clone() method also clones that object reference in order to return a deep copy of the original.

<source lang="java">
public class X implements Cloneable {
    public X clone() throws CloneNotSupportedException {
        return (X) super.clone();
    }
}

public class Y extends X { }

public class ObjectABC implements Cloneable {
    public ObjectABC clone() throws CloneNotSupportedException {
        return (ObjectABC) super.clone();
    }
}

public class Z extends Y {
    private ObjectABC someABC;

    public Z clone() throws CloneNotSupportedException {
        Z newZ = (Z) super.clone();
        newZ.someABC = someABC.clone();

        return newZ;
    }
}

public class test1 {
    public void function() throws CloneNotSupportedException {
        Y varY1 = new Z();
        Y varY2 = (Y) varY1.clone();
    }
}
</source>

== Pitfalls ==
If every class in a hierarchy implements a <code>clone()</code> method, all of these functions will be called upon cloning, adding some overhead. Over many iterations, this overhead could become significant.

With complex object graphs, deep copying can also become problematic when recursive references exist.

It is not always appropriate to have multiple copies of the same object floating around. If the purpose of a specific <code>clone()</code> implementation is not fully understood by consumers, it may unintentionally break the "single object, multiple references" paradigm.

==Final fields==
Generally, <code>clone()</code> is incompatible with <code>final</code> fields. Because <code>clone()</code> is essentially a default constructor (one that has no arguments) it is impossible to assign a <code>final</code> field within a <code>clone()</code> method; a compiler error is the result. Where the value of the field is an [[Immutable object|immutable object]] this is okay; just let the 'constructor' copy the reference and both the original and its clone will share the same object.

But where the value is a mutable object it must be deep copied. One solution is to remove the <code>final</code> modifier from the field, giving up the benefits the modifier conferred.

For this reason, some programmers suggest to make the objects in the hierarchy [[Serialization#Java|Serializable]], and create copies by serializing the old object and then creating a new object from the resulting [[Bitstream|bitstream]], which handles final data members correctly, but is significantly slower.<ref>{{cite web |last1=Miller |first1=Dave |date=1999-08-06 |df=mdy |url=https://www.infoworld.com/article/2077578/java-tip-76--an-alternative-to-the-deep-copy-technique.html |title=Java Tip 76: An alternative to the deep copy technique |work=JavaWorld |accessdate=2020-07-14}}</ref>

Alternatively, one can return a completely new object from the current objects fields, which can be done first calling the constructor, and later assigning non final fields. Another alternative method is actually making the idea formal : creating a copy constructor that takes an instance. In fact that is what is recommended over clone by some people.
<ref>[https://stackoverflow.com/questions/2427883/clone-vs-copy-constructor-which-is-recommended-in-java Clone() vs Copy constructor- which is recommended in java], StackOverflow</ref>

== References ==
<references/>

==External links==
* {{cite web|url=http://weblogs.java.net/blog/2007/04/04/cloning-java-objects-using-serialization|title=Cloning Java objects using serialization|last=McManus|first=Eamonn|date=April 4, 2007|work=Eamonn McManus's Blog|publisher=java.net|accessdate=2010-11-16|archive-url=https://web.archive.org/web/20100813191054/http://weblogs.java.net/blog/2007/04/04/cloning-java-objects-using-serialization|archive-date=August 13, 2010|url-status=dead}}
* {{cite book|last=Bloch|first=Joshua|title=Effective Java: A Programming Language Guide|publisher=Addison-Wesley|year=2008|edition=2nd|series=The Java Series|isbn=978-0-321-35668-0|url-access=registration|url=https://archive.org/details/effectivejava00bloc_0}}
* {{cite web|url=http://www.javapractices.com/topic/TopicAction.do?Id=71|title=Avoid clone|year=2009|work=Collected Java Practices|publisher=Hirondelle Systems|accessdate=2009-07-31}}
* {{cite web|url=http://java.sun.com/javase/6/docs/api/java/lang/Object.html#clone()|title=Object (Java Platform SE 6)|year=2008|work=Java Platform Standard Ed. 6|publisher=Sun Microsystems, Inc.|accessdate=2009-07-31}}
* {{cite web |last1=Roulo |first1=Mark |date=1999-01-01 |df=mdy |url=https://www.infoworld.com/article/2076332/how-to-avoid-traps-and-correctly-override-methods-from-java-lang-object.html |title=How to avoid traps and correctly override methods from java.lang.Object |work=JavaWorld |accessdate=2020-07-14}} - Covers the basics of implementing the clone method.
* [https://web.archive.org/web/20130101012249/http://www.javaexperience.com/java-cloning-tutorial/ Java Cloning Tutorial].

{{DEFAULTSORT:Clone (Java Method)}}
[[Category:Java (programming language)]]

{{Sourceattribution|Clone (Java method)}}