Re: Backing Up Objects
Hal Vaughan writes:
String newString = oldString;
that newString is simply a pointer to oldString so if I change the value in
one, I change the value in the other.
Ironically, under most circumstances it is not possible to change the value of
a String, so this made a bad example. Strings are "immutable"; without
resorting to evil reflection trickery their value cannot be changed after
construction. An example using "Foo" instead of "String" would be valid (one
would assume Foo is not immutable). However, the main point of the post is
valid, that assignment copies references, not objects.
how can I create a backup of an Object
Stefan Ram wrote:
This depends on the circumstances. There are ??shallow?? copies
only copying the fields and ??deep?? copies, where the fields
are altered to refer to copies of subobjects (recursively),
and there are mixtures. Only you can know, what is appropriate
for your requirements. By this knowledge, you can implement
the operation as a method.
Means to copy often are a ??copy constructor?? or the method ??clone??.
You might look up these subjects in the technical literature.
Hal Vaughan writes:
This object is essentially a data table and I have several of them, stored
in a Vector. I've read that if I use clone() on a Vector, that a new
Why did you use the senescent Vector class in lieu of, say, ArrayList or any
other List (or more generic Collection) class? Vector is, what, seven or
eight years out of date, and dangerous? If you need synchronized methods,
Collections.synchronizedList( yourList ) is much safer than Vector.
--
Lew