1

Hello I am working on a project in java and i need to do this : Heres the problem(using psuedo class names)

MyClass class1;
class1.addString("test");

then i would like to create a backup copy of that variable so when i call

class1.removeString();

I can access the copy and do class1 = copyVar; and have class1.getString() still equal to "test" Sorry I know this is a noob question never really learned how to do this

Luiggi Mendoza
  • 85,076
  • 16
  • 154
  • 332
Carlos Cannon
  • 41
  • 1
  • 4
  • 1
    Possibly related: http://stackoverflow.com/q/2156120/1065197 – Luiggi Mendoza Sep 09 '13 at 00:42
  • @HovercraftFullOfEels looks like OP wants to have a copy of the state of this `MyClass class1` instance, then modify the state of `class1` accordingly and later recover the state of `class1` from the copy. – Luiggi Mendoza Sep 09 '13 at 00:43

2 Answers2

1

There is no generic built-in way in Java to copy objects.

The closest you can get is Cloneable, but you have to implement that yourself.

Thilo
  • 257,207
  • 101
  • 511
  • 656
  • This is an inaccurate description. All implementing `Cloneable` means is that if you end up calling (using `super`) the `Object.clone()` method, you will get a field-by-field shallow copy of the current object, instead of an exception in your face. You can very well expose a `clone()` method without implementing `Cloneable` if you copy all the fields yourself. And, of course, since you frequently do need to deep-copy everything mutable in your class, using `Object.clone()` doesn't really help that much. – millimoose Sep 09 '13 at 01:07
  • @millimoose: That's what I meant. You have to think about how clone should work for you class and implement it as such. "Implement" as "write some code", not just add `implements Cloneable`. And I agree with your comments on the other answer that Cloneable is broken legacy stuff. Bottomline: "There is no generic built-in way in Java to copy objects." – Thilo Sep 09 '13 at 02:26
1

You would need to override the clone method of object, so that when you call

MyClass class2 = class1.clone();

you copy out all the data in the class. This is usually accomplished by recursively calling clone on each of the other objects in the class and assigning it to a new instance.

Zack Newsham
  • 2,810
  • 1
  • 23
  • 43
  • Using `clone()` isn't really recommended. , mostly because the design is broken. At least Josh Bloch recommends using copy constructors instead - it's not like you can use `clone()` on an object that's not explicitly cloneable, and most will provide appropriate copy constructors anyway in that case. (Arrays might be an exception here.) – millimoose Sep 09 '13 at 01:00
  • An interesting point - I hadn't realised that the clone() method of object was protected, though my suggestion did not require the use of the `Cloneable` interface. In fact in all but name it was a copy constructor, just overriding the clone name by convention. I guess if someone really wanted to, they could create their own `Cloneable` interface (with another name if preferred) and that gets around the big issue that Josh Bloch seems to be referring to, in that you can't have an array of `Cloneable` objects and call `clone()` on each one. – Zack Newsham Sep 09 '13 at 01:07
  • Essentially it's important to distinguish between the protected `Object.clone()`, and the public `clone()` methods exposed by "cloneable" objects. The latter method may use the former to do the initial shallow-copy, but it doesn't need to. You might as well call your method `deepCopy()` and call `this.clone()`, or call it `clone()` but call copy constructors for all your fields. They *are* related methods, but only very weakly, and it's a misleading pattern. – millimoose Sep 09 '13 at 01:10
  • Another major disadvantage Josh Bloch mentions [in an interview](http://www.artima.com/intv/bloch13.html) is that implementing a public `clone()` forces all your inheriting classes to bother with implementing appropriate deep-copy semantics. They might, or they might not and you get a frankenobject that's partially deep copied but has a bunch of other mutable field shared between the clones. This is where a copy constructor is better, since it at least lets you safely get a partial deep copy. (Assuming that you don't absolutely need all objects in your hierarchy to be cloneable.) – millimoose Sep 09 '13 at 01:13