This dive into cloning (both shallow and deep) considers when and how to use cloning, when to use another means, and how the JVM reads cloned objects.<\/b>
\nIn my previous article, 5 Different ways to create objects in Java, I discussed five different ways (new, Class.newInstance () , Constructor.newInstance () , clone () , and deserialization) a developer can create objects. If you haven’t read it, please go ahead.
Cloning is also a way of creating an object, but in general, cloning is not just about creating a new object. Cloning means creating a new object from an already present object and copying all data of the given object to that new object.
In order to create a clone of an object, we generally design our class in such way that:
To demonstrate cloning, we will create two classes \u2014 Person and Cit. Both classes have:
And as we can see, toString () , equals () , and hashCode () have the @Override annotation, while the clone () method doesn\u2019 t have it because we are not overriding it from clone \u2014 we are creating a new method by the name of clone () , and we can name it anything else.
The Person class has a reference to the City class, which looks like below:
And let’s test it:
person1.clone () calls super.clone () , which means the Object.clone () method.
So (person1 == person2) will evaluate false because person1 and person2 are copies of each other, but both are different objects and hold different spots in heap memory. Meanwhile, person1.equals (person2) evaluates true because both have the same content.
.
The behavior of the Object.clone () method classifies cloning into two sections.
This is the default cloning strategy provided by Object.clone () , which we have seen. The clone () method of the Object class creates a new instance and copies all fields of the Cloneable object to that new instance (either it is primitive or a reference) . So in the case of reference types, only reference bits gets copied to the new instance. Therefore, the reference variable of both objects will point to the same object. The example we have seen above is an example of Shallow Cloning.
As the name suggests, deep cloning means cloning everything from one object to another object. To achieve this, we will need to trick our clone () method provide our own cloning strategy. We can do it by implementing a Cloneable interface and overriding the clone () method in every reference type we have in our object hierarchy. Then, we call super.clone () and these clone () methods in our object\u2019s clone method.
So we can change the clone method of the Person class in the following way:
Now (person1.getCity () == person2.getCity () ) will evaluate false because, in the clone () method of the Person class, we are cloning the city object and assigning it to the new cloned person object.
In the example below, we have deep-copied the city object by implementing clone () in the City class and calling that clone () method of a person class, That’s why person1.getCity () == person2.getCity () evaluates false \u2014 because both are separate objects. But we have not done the same with the Country class, person1.getCountry () == person2.getCountry () evaluates true.
Despite everything you’ve learned here, Java cloning is not considered a good way to copy an object, and there are lots of other ways to do the same. For instance, you can read Java Cloning \u2014 Copy Constructor versus Cloning
to get more knowledge on why Java cloning is not preferred and what you can do instead.<\/p>\n

\n

Sentiment rank: 0.6<\/div>\n

<\/div>\n<\/div>\n