Develop Reference

Why we use cloneable interface in java while making clones of the object?

I'm new to java and was studying object cloning. My question is that since Object class is the top most class in java and all other classes inherits this class and clone() method is defined in the Object class, then what is purpose of using cloneable interface? Why can't we just override the clone() method of Object class in our class and return super.clone() from it(or modify it for deep copy according to our needs)?
Also which is the recommended way (java standard way) of creating clones of the object? Using clone() method or creating copy constructor just like C++ which is mentioned in Andreas dolk's answer to this question?

The clone situation is unique and is rather anti-java-like - there's a reason its not recommended to use it in the first place. The way Cloneable is used in the JDK is not something you should be taking notes on - this isn't how to design APIs, nothing else in the java ecosystem works this way.
Weirdly, this is a common thing: The core parts of java often aren't java-like. For example, nobody in their right mind would make an API that defines an application by 'it has a method with the signature public static void main(String[] args). The obvious design principle would be to make an abstract class or interface with an abstract start() method, and to make a java app you write a class that has a no-args constructor and implements/extends that interface/class. Same story for arrays: They are weird - their toString, equals, and hashCode implementations are surprising, to say the least. They aren't entirely type-safe either.
The reasons for all of this are historic: To explain them, you need to know about all sorts of things that were relevant at the time, but aren't important anymore and haven't been for decades.
Cloneable is no different. Let me explain why it works that way:
The 'system' of cloning is offered by the JDK itself, it's a built-in thing that an ordinary library could not easily make. Kinda how "java SomeClass invokes its main method" is part of java itself.
The system, however, needs an opt-in mechanism: The act of cloning may not make sense (what does it mean to 'clone' an InputStream representing a TCP network connection's incoming bytes? What does it mean to 'clone' the value of an enum which tries to guarantee that only one instance ever exists? What does it mean to 'clone' a singleton?)
Thus, 'just make all objects cloneable' is dangerous, so java didn't want to do that: They want you to opt in to it. Java wants the author of a class to explicitly say: Yup. I am clonable, using the standard mechanism (which deep-copies all fields, if memory serves).
That is what Cloneable is for! - that's how you say: Yup. I'm good with it. By implementing that. It's a flag.
Java could also have decided to do something like:
/** #cloneable */
public class Something {}
instead, but they didn't. If it had been designed in this more modern age, perhaps it would have looked like:
#Cloneable
public class Something {}
But annotations were introduced in java 1.5 as a demo feature in 1.6 properly. The cloneable interface is as old as java 1.0 - over a decade earlier. "add an interface that defines nothing" was the standard way to flag class properties back then, even if it isn't now.
NB: You don't just implements Cloneable, you also make a public clone method. The implements Cloneable part tells the cloning system: You may clone this class, for example even if it is part of the deep structure of an encompassing object that is being cloned. Making a clone method that invokes the protected JVM-provided clone() method that j.l.Object has is how you expose the API. Maybe you want to name it copy instead, or maybe you want cloning but not as part of your public API. Your question isn't about how to use clone, but why it works like it is - my advice if you want to use it is simple. Don't, write clone code yourself, or better yet, design your API with more immutables so that cloning is no longer neccessary.

clone() method has no implementation in Object and does nothing. To make it work, your class has to implement Cloneable. This is a marker interface and adds some methods to any class inheriting it so that you can clone an object of that class.

Why doesn't CopyOnWriteArraySet implement the Cloneable interface, while CopyOnWriteArrayList does?

In this bug report, Doug Lea writes (referring to a pre-release version of JDK 5.0):
While CopyOnWriteArraySet is declared Cloneable, it fails to define public clone method.
But it eventually ends up that CopyOnWriteArraySet doesn't implement the Cloneable interface at all! (This is true in Java SE 6, 7, and 8.)
How is CopyOnWriteArraySet different from CopyOnWriteArrayList with respect to cloning? There is a sound reason nobody ever wants to clone it?
P.S. I understand that clone() is not recommended and that CopyOnWriteArraySet is based on CopyOnWriteArrayList internally.

There was some important information about this bug (JDK-5055732) in a confidential database. I've posted this information in a public comment on that bug, and I'll copy it here to answer this question.
Problem
As explained in Josh Bloch's Effective Java, the Cloneable mechanism is not terribly well designed. In particular, it is impossible for a non-final class with a final reference field that needs to be unique for each object to satisfy the requirement that
x.clone().getClass() == x.getClass()
(when the class is subclassed)
CopyOnWriteArraySet, ConcurrentHashMap currently are specified to implement Cloneable. CopyOnWriteArraySet erroneously did not implement a public clone() method, while ConcurrentHashMap implemented a clone() method using a constructor, thereby not fulfilling the above requirement.
Doug Lea writes:
"Martin and Josh convinced me that we can't just add the one-line public Object clone() { return new CopyOnWriteArraySet(al); } because, as noted by Josh in Effective Java book, clone methods should not invoke constructors:
In practice, programmers assume that if they extend a class and call super.clone from within the subclass, the returned object will be an instance of the subclass. The only way that a superclass can provide this functionality is to return an object obtained by calling super.clone. If a clone method returns an object created by a normal constructor, it will not have the correct class. Therefore, if you override the clone method in a non-final class, you should always return an object obtained by invoking super.clone().
In general this means that any class with a blank final field will encounter problems because it needs to set the field inside clone. This is now possible inside JDK classes using the setAccessible loophole (see JMM list) but is ugly and slow. It seems like a better idea just to remove "implements Cloneable".
The ConcurrentHashMap class has exactly the same problem, and the same solution."
Solution
Remove "implements Cloneable" from the specification for CopyOnWriteArraySet, ConcurrentHashMap. Delete ConcurrentHashMap.clone()
The text above explains everything, but it might be a bit confusing since it explains things relative to the state of the code that's no longer visible, and it also assumes a fair amount of contextual knowledge. Here's an explanation that I think might be a bit easier to understand.
The issues with cloning are fully explained in Joshua Bloch's Effective Java, Item 11. Much of the issues are also covered elsewhere on Stack Overflow. Briefly, to allow successful cloning, a class must
implement the Cloneable interface
implement a public clone() method
in the clone() method, it must
call super.clone() to do the actual cloning
modify the cloned object, possibly by deep-copying internal structures
return the cloned object
Historically, all collections implementations have supported cloning. Prior to the release of JDK 5.0, CopyOnWriteArraySet and ConcurrentHashMap both implemented the Cloneable interface. But CopyOnWriteArraySet didn't implement a public clone() method, and while ConcurrentHashMap did implement a public clone() method, it did so incorrectly, by returning a freshly constructed instance of ConcurrentHashMap. Both of these are bugs and are the subject of this bug report.
It turns out that neither CopyOnWriteArraySet nor ConcurrentHashMap can fulfill all the obligations of supporting cloning. The "fix" for the bug, then, was to have them withdraw from the Cloneable contract.
The reason CopyOnWriteArraySet can't be cloned is that it has a final field al that points to the CopyOnWriteArrayList that stores the actual elements. The clone mustn't share this state with the original, so the clone() method would be required to copy (or clone) the backing list and store it into the field. But final fields can only be stored within constructors, and clone() isn't a constructor. The implementors considered and rejected heroic efforts such as using reflection to write final fields.
What about a one-liner constructor such as this?
public clone() { return new CopyOnWriteArraySet(al); }
The problem here is that it breaks the cloning contract. If a subclass of CopyOnWriteArraySet were to support cloning, calling clone() on that subclass should return an instance of that subclass. The clone() method of the subclass would properly call super.clone() to create the clone. If it were implemented as above, that would return an instance of CopyOnWriteArraySet instead of an instance of the subclass. This would therefore prevent subclasses from being able to clone themselves.
What about ConcurrentHashMap? It doesn't have any final fields. Well, it did at the time, so it suffered from exactly the problem of updating final fields from within the clone() method.
Recent versions of ConcurrentHashMap no longer have final fields. The copy constructor simply calls putAll on the map argument, which initializes all the fields lazily. Couldn't the clone() method be implemented simply by cloning, nulling out all the fields, and then calling putAll()?
This seems like it might work, but I suspect it runs afoul of the memory model. Not all of the fields are volatile. Even if all fields were nulled out before being reinitialized to point to copies, other threads might see stale values that still pointed to the original map. There might be ways to avoid this problem, but I suspect the implementors felt that providing cloneability wasn't worth the extra effort.

java:Does it make any difference if using a Copy Constructor instead of clone? [duplicate]

This question already has answers here:
clone() vs copy constructor vs factory method?
(10 answers)
Closed 8 years ago.
clone method vs copy constructor in java. which one is correct solution. where to use each case?

Clone is broken, so dont use it.
THE CLONE METHOD of the Object class
is a somewhat magical method that does
what no pure Java method could ever
do: It produces an identical copy of
its object. It has been present in the
primordial Object superclass since the
Beta-release days of the Java
compiler*; and it, like all ancient
magic, requires the appropriate
incantation to prevent the spell from
unexpectedly backfiring
Prefer a method that copies the object
Foo copyFoo (Foo foo){
Foo f = new Foo();
//for all properties in FOo
f.set(foo.get());
return f;
}
Read more
http://adtmag.com/articles/2000/01/18/effective-javaeffective-cloning.aspx

Have in mind that clone() doesn't work out of the box. You will have to implement Cloneable and override the clone() method making in public.
There are a few alternatives, which are preferable (since the clone() method has lots of design issues, as stated in other answers), and the copy-constructor would require manual work:
BeanUtils.cloneBean(original) creates a shallow clone, like the one created by Object.clone(). (this class is from commons-beanutils)
SerializationUtils.clone(original) creates a deep clone. (i.e. the whole properties graph is cloned, not only the first level) (from commons-lang), but all classes must implement Serializable
Java Deep Cloning Library offers deep cloning without the need to implement Serializable

clone() was designed with several mistakes (see this question), so it's best to avoid it.
From Effective Java 2nd Edition, Item 11: Override clone judiciously
Given all of the problems associated with Cloneable, it’s safe to say
that other interfaces should not extend it, and that classes
designed for inheritance (Item 17) should not implement it. Because of
its many shortcomings, some expert programmers simply choose never to
override the clone method and never to invoke it except, perhaps, to
copy arrays. If you design a class for inheritance, be aware that if
you choose not to provide a well-behaved protected clone method, it
will be impossible for subclasses to implement Cloneable.
This book also describes the many advantages copy constructors have over Cloneable/clone.
They don't rely on a risk-prone extralinguistic object creation mechanism
They don't demand unenforceable adherence to thinly documented conventions
They don't conflict with the proper use of final fields
They don't throw unnecessary checked exceptions
They don't require casts.
All standard collections have copy constructors. Use them.
List<Double> original = // some list
List<Double> copy = new ArrayList<Double>(original);

Keep in mind that the copy constructor limits the class type to that of the copy constructor. Consider the example:
// Need to clone person, which is type Person
Person clone = new Person(person);
This doesn't work if person could be a subclass of Person (or if Person is an interface). This is the whole point of clone, is that it can can clone the proper type dynamically at runtime (assuming clone is properly implemented).
Person clone = (Person)person.clone();
or
Person clone = (Person)SomeCloneUtil.clone(person); // See Bozho's answer
Now person can be any type of Person assuming that clone is properly implemented.

See also: How to properly override clone method?. Cloning is broken in Java, it's so hard to get it right, and even when it does it doesn't really offer much, so it's not really worth the hassle.

Great sadness: neither Cloneable/clone nor a constructor are great solutions: I DON'T WANT TO KNOW THE IMPLEMENTING CLASS!!! (e.g. - I have a Map, which I want copied, using the same hidden MumbleMap implementation) I just want to make a copy, if doing so is supported. But, alas, Cloneable doesn't have the clone method on it, so there is nothing to which you can safely type-cast on which to invoke clone().
Whatever the best "copy object" library out there is, Oracle should make it a standard component of the next Java release (unless it already is, hidden somewhere).
Of course, if more of the library (e.g. - Collections) were immutable, this "copy" task would just go away. But then we would start designing Java programs with things like "class invariants" rather than the verdammt "bean" pattern (make a broken object and mutate until good [enough]).

Deep clone utility recommendation [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a book, tool, software library, tutorial or other off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 8 years ago.
Improve this question
Is there any utility for deep cloning for java collections:
Arrays
Lists
Maps
NOTE: prefer some solution without usage of serialization, but with use of Object.clone() method. I can be sure that my custom object will implement clone() method and will use only java-standard classes that are cloneable...

I think the previous green answer was bad , why you might ask?
It adds a lot of code
It requires you to list all fields to be copied and do this
This will not work for Lists when using clone()
(This is what clone() for HashMap says: Returns a shallow copy of this HashMap instance: the keys and valuesthemselves are not cloned.) so you end up doing it manually (this makes me cry)
Oh and by the way serialization is also bad, you might have to add Serializable all over the place (this also makes me cry).
So what is the solution:
Java Deep-Cloning library
The cloning library is a small, open source (apache licence) java library which deep-clones objects. The objects don't have to implement the Cloneable interface. Effectivelly, this library can clone ANY java objects. It can be used i.e. in cache implementations if you don't want the cached object to be modified or whenever you want to create a deep copy of objects.
Cloner cloner=new Cloner();
XX clone = cloner.deepClone(someObjectOfTypeXX);
Check it out at https://github.com/kostaskougios/cloning

All approaches to copy objects in Java have serious flaws:
Clone
The clone() method is protected, so you can't call it directly unless the class in question overrides it with a public method.
clone() doesn't call the constructor. Any constructor. It will allocate memory, assign the internal class field (which you can read via getClass()) and copy the fields of the original.
For more issues with clone(), see item 11 of Joshua Bloch's book "Effective Java, Second Edition"
Serialize
Serialize is even worse; it has many of the flaws of clone() and then some. Joshua has a whole chapter with four items for this topic alone.
My Solution
My solution is add a new interface to my projects:
public interface Copyable<T> {
T copy ();
T createForCopy ();
void copyTo (T dest);
}
The code looks like this:
class Demo implements Copyable<Demo> {
public Demo copy () {
Demo copy = createForCopy ();
copyTo (copy);
return copy;
}
public Demo createForCopy () {
return new Demo ();
}
public void copyTo (Demo dest)
super.copyTo (dest);
...copy fields of Demo here...
}
}
Unfortunately, I have to copy this code to all my objects but it's always the same code, so I can use an Eclipse editor template. Advantages:
I can decide which constructor to call and how to initialize which field.
Initialization happens in a deterministic order (root class to instance class)
I can reuse existing objects and overwrite them
Type safe
Singletons stay singletons
For standard Java types (like collections, etc), I use a utility class which can copy those. The methods have flags and callbacks, so I can control how deep a copy should be.

Shallow cloning a collection is easy, but if you want to deep clone, a library will probably do you better than hand coding it (since you want to clone the elements inside the collection as well).
Just like this answer, I've used the Cloner library and specifically performance tested it against XStream (which can 'clone' by serializing then deserializing) and binary serialization. Though XStream is very fast at serializing to/from xml, Cloner is much faster at cloning:
0.0851 ms : xstream (clone by serializing/deserializing)
0.0223 ms : binary serialization (clone by serializing/deserializing)
0.0017 ms : cloner
* average time to clone a simple object (two fields) and no default, public constructor. Run 10,000 times.
In addition to being fast, here are more reasons to choose cloner:
performs a deep clone of any object (even those you don't write yourself)
you don't have to keep your clone() method up-to-date each time you add a field
you can clone objects that don't have a default public constructor
works with Spring
(optimization) doesn't clone known immutable objects (like Integer, String, etc.)
easy to use. Example:
cloner.deepClone(anyObject);

I am the creator of the cloner lib, the one that Brad presented. This is a solution for cloning objects without having to write any extra code (no need for serializable objects or impl clone() method)
It's quite fast as Brad said, and recently I uploaded a version which is even faster. Note that manually implementing a clone() method will be faster than clone lib, but then again you'll need to write a lot of code.
Cloner lib has worked quite well for me since I am using it in a cache implementation for a site with very heavy traffic (~1 million requests/day). The cache should clone approximately 10 objects per request. It is quite reliable and stable. But please be aware that cloning is not without risk. The lib can be configured to println every class instance that it clones during dev. This way you can check if it clones what you think it should clone - object graphs can be very deep and can contain references to a surprisingly large amount of objects. With clone lib, you can instruct it to not clone the objects that you don't want, i.e. singletons.

One general way to deep-clone an arbitrary collection is to serialize it to a stream, then read it back into a new collection. You'll be rehydrating completely new objects that don't have any relationship to the old ones, other than being identical copies.
Check out Bruno's answer for a link to the Apache Commons serialization utility classes, which will be very helpful if this is the route you decide to take.

One possibility is to use serialization:
Apache Commons provides SerializationUtils

I've used this cloning library and found it quite useful.
Since it had a few limitations (I needed finer grained control
over the cloning process: which field, in what context and how deeply
should be cloned etc.), I've created an extended version of it.
You control the cloning of the fields by annotating them in
the entity class.
Just to get a flavour of it, here is an example class:
public class CloneMePlease {
#Clone(Skip.class)
String id3 = UUID.randomUUID().toString();
#Clone(Null.class)
String id4 = UUID.randomUUID().toString();
#Clone(value = RandomUUID.class, groups=CustomActivationGroup1.class)
String id5 = UUID.randomUUID().toString();
#Clone.List({
#Clone(groups=CustomActivationGroup2.class, value=Skip.class),
#Clone(groups=CustomActivationGroup3.class, value=Copy.class)})
Object activationGroupOrderTest = new Object();
#Clone(LongIncrement.class)
long version = 1l;
#PostClone
private void postClone(CloneMePlease original, #CloneInject CloneInjectedService service){
//do stuff with the original source object in the context of the cloned object
//you can inject whatewer service you want, from spring/guice to perform custom logic here
}
}
More details here:
https://github.com/mnorbi/fluidity-cloning
There is also a hibernate specific extension in case one needs it.

Use serialization and then deserialization, but be aware that this approach works only with Serializable classes without transient fields. Also, your singletons will not be singletons anymore.

What have you used Object.clone() for?

A colleague recently asked me how to deep-clone a Map and I realized that I probably have never used the clone() method- which worries me.
What are the most common scenarios you have found where you need to clone an object?

I assume you are referring to Object.clone() in Java. If yes, be advised that Object.clone() has some major problems, and its use is discouraged in most cases. Please see Item 11, from "Effective Java" by Joshua Bloch for a complete answer. I believe you can safely use Object.clone() on primitive type arrays, but apart from that you need to be judicious about properly using and overriding clone. You are probably better off defining a copy constructor or a static factory method that explicitly clones the object according to your semantics.

Most commonly, when I have to return a mutable object to a caller that I'm worried the caller might muck with, often in a thread-unfriendly way. Lists and Date are the ones that I do this to most. If the caller is likely to want to iterate over a List and I've got threads possibly updating it, it's safer to return a clone or copy of it.
Actually, that brings up something I'm going to have to open up another question for: copy constructors or clone? When I did C++, we ALWAYS did a copy constructor and implemented clone with it, but FindBugs does not like it if you implement your clone using a copy constructor.

When I need to make a duplicate of something to modify the duplicate without impacting the original, and of course in this scenario deep cloning (only) will suffice. I've had to do this on a system where I would clone a domain class instance, apply the user's changes, and then perform a comparison of the two for the user to verify their changes.

The Object.clone() method doesn't specify whether the copy of a subclass is a deep or shallow copy, it's completely dependent of the specific class. The Object.clone() method itself does a shallow copy (copies internal state of the Object class), but subclasses must override it, call super.clone(), and copy their internal state as needed (shallow or deep).
It does specify some conventions, which you may or not follow. For (a.getClass() == a.clone().getClass()) to return true, super.clone() should be called instead of simply 'new Subclass()', since super.clone() presumably would correctly instantiate the class of this object (even in subclasses), and copy all internal state, including private fields, which couldn't be copied by subclasses using a copy constructor, due visibility rules. Or you would be forced to expose a constructor that shouldn't be exposed, for better encapsulation.
Example:
//simple clone
class A implements Cloneable {
private int value;
public A clone() {
try {
A copy = (A) super.clone();
copy.value = this.value;
return copy;
} catch (CloneNotSupportedException ex) {}
}
}
//clone with deep and shallow copying
class B extends A {
Calendar date;
Date date;
public B clone() {
B copy = (B) super.clone();
copy.date = (Calendar) this.date.clone(); // clones the object
copy.date = this.date; // copies the reference
return copy;
}
}
Deep copy is usually used when dependent objects are mutable (like Calendar), and the copy must be completely independent of the original.
When dependent objects are immutable (like Date), sharing the same instance usually isn't an issue, and a shallow copy may be sufficient.
When using Object.clone() you must follow some rules, but they are simple enough to be understandable. Probably the most difficult part is correctly defining how deep you should copy into your object graph. A logical issue, not a language issue, that is.

I have used Object.clone() in a Spring webflow application to check what has changed when a user edits / enters data on a form for auditing purposes.
At the beginning of the flow, I call the clone method which was implemented on the form backing object used in the spring webflow and save the instance of the clone to the user session. Once the user has completed editing data on the html form and pressed the save button I compare the new values bound to the backing object to the cloned value to determine what data the user has changed.
This worked well and was really easy to implement, I haven't really experienced any issues with cloning in Java.