I need to deep clone a object which has some non-serialization objects as members in Java.
Can you provide some reference what can i use for this ?
Note:
Please provide reference to some standard library of java. I don't want to use any unapproved/private package or library.
Or some code pointers how can i clone the object ?
In the absence of standardisation of values in Java, I strongly suggest avoiding any dodgy reflection/code generation scheme.
If you can, changing to immutable types removes the need to copy.
Other than that, just write the code neatly. If there are a lot of collections, writing map methods will help to avoid the palaver of Streams (and be faster).
Related
I saw several tutorials online where serialization and subsequent deserialization is used to implement deep cloning in Java.
My feeling is, that this is a solution that is fast to implement and therefore widespread but might have caveats that I currently don't see.
Is that way of implementing clone() good style? Isn't it slow? Should deep cloning really be done that way? What better ways exist?
Is it good practice in Java to implement the clone method using
serialization?
If you use serialization to clone an object you have to necessarily unserialize the serialized object to create the cloned object. It makes two operations where the second seems be an overhead as it should not be performed if you implement the cloning operation at the hand or with a mapper API (ex: SpringBean, Common apache, ModelMapper, Dozzer...).
So it has without no doubt an impact on the performance. If you do this processing very occasionally, I don't think that it should be a problem (even if it seems to be a useless overhead and you have alternative ways) but if you use it often I think that it may have a cost.
Besides, why implementing Clonable to clone an object by using serialization instead of forgetting Cloneable that is a clumsy API and using directly the deserialization mechanism ?
I am trying spark with java and I get stuck by the immutable collections in java.
As I understand in Scala when two immutable lists are combined, no deep copy happens. However the available immutable list in java, like guava, does the defensive copy. (correct me if I am wrong)
So simply my questions are:
Is there some Java immutable list which has the same behavior as
scala immutable list ?
If the answer of the first question is NO, what's the
general(standard) way to use scala immutable collection in java code
?
Thanks very much.
Scala Lists is a so-called persistent collection with the persistent referring to the fact, that no defensive copying happens. If you google for Java persistent collection you should find several links to get you started. In addition to that, there are a number of libraries that aim to bring the essence of functional programming to Java. As persistent collections are inherently functional, those frameworks often include their own collections implementation. The two libraries I've worked with and can recommend are Javaslang and Functional Java but there are more out there than these two (e.g. pccollections, jOOλ, …).
As for using Scala collections from Java, I've always found this to be somewhat awkward. I would suggest to write a Scala class/object, that gives you easy (as from-Java-easy) access to the scala.collection.JavaConverters, so that you can expose your scala.collection.immutable.List as a java.util.List and work with that interface.
I am just trying to find out the best solution how to make a deep copy of HashMap. There are no objects in this map which implement Cloneable. I would like to find better solution than serialization and deserialization.
Take a look at Deep Cloning, on Google Code you can find a library. You can read it on https://github.com/kostaskougios/cloning.
How it works is easy. This can clone any object, and the object doesnt have to implement any interfaces, like serializable.
Cloner cloner = new Cloner();
MyClass clone = cloner.deepClone(o);
// clone is a deep-clone of o
Be aware though: this may clone thousands of objects (if the cloned object has that many references). Also, copying Files or Streams may crash the JVM.
You can, however, ignore certain instances of classes, like streams et cetera. It's worth checking this library and its source out.
I don't think it can be implemented in a generic way.
If you have the chance to simply implement clone, I'd go that way.
A bit more complex is creating a type map, where you look up some kind of clone implmentation class based on the class of each object
When the objects might form a Directed Acyclic Graph, I'd in general keep a Map from the original to the clone of every object I've ever seen, and check if I've already made it
When you have a general graph, the problem gets really nasty. You might have strange constraints of the object creation order, it might even be impossible when you have final fields.
For now, I'd propose to re-write your question in a less general way
This is not easy, we are using some sort of workaround:
1) convert the map to json string. (for example, using Google Gson)
2) convert the json string back to map.
Do note that there is performance issue, but this is kind of easiest way.
What is the best tool for java's clone() method generation in Eclipse Galileo available from repositories?
What is the reason, that prevents Eclipse developers from including this tool in standard release?
It's very hard to implement clone() right. It is considered not a good practice to do so. Bloch (Effective Java) suggest that using clone() should be avoided. Use other means of shallow cloning, like copy-constructors or utilities like commons-beanutils.
I absolutely agree with Bozho. However, if there is a need for it and you have large number of member fields to copy over and you need to quick way to list them out then you could make use of the "toString" generator to get a code template.
In the generate toString option use the Code style : "StringBuilder/StringBuffer" which would list all member fields and append to the StringBuilder. Then you could change the appends to appropriate setters of the cloned object.
I've recently moved to Java, but I've had some problems with variable aliasing. I've searched everywhere, but I can't seem to find the proper way to copy the contents of one object to another object without just referencing to the same object. Does anyone have any suggestions?
Edit: What if it is an int that I am having aliasing problems with? Should I be avoiding situations like this in the first place? If so, how?
If your class implements the Clonable interface, then you can use the Object.clone() method to create a hard copy. The Wikipedia entry has some good details.
An alternative is to use copy constructors, which according to this page are safer.
It depends on the "content". For example, you cannot just copy a FileInputStream and then assume that both will continue loading from the same file.
Basically, there are two ways: If the class supports "Cloneable" interface, you can clone it by calling clone(). If not, it often has a copy constructor, that copies in data from another object.
Usually, you will end up with a shallow copy (i. e. all fields of the class are copied, but they point to the same object).
On the other hand, a lot of objects are designed to be immutable (like the String class), and there is no need to copy such an object as it cannot be changed anyway.
Another option is to design your class to create immutable objects:
http://docs.oracle.com/javase/tutorial/essential/concurrency/immutable.html
This avoids the need for cloning or a copy-constructor because the object cannot be changed once it is created. So multiple variables can point to the same object, but none of them can change the state of the object.
java.lang.Cloneable is what you are looking for.
You cannot have an implicit reference to a reference in Java so you cannot alias a variable.
Perhaps if you explain what you are trying to achieve, we can help do that without "aliases"
Edit: You really need to explain what you mean by aliasing an int value. An int value is anonymous at runtime so aliasing it doesn't make any sense.