Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Backing Up Objects

Reply
Thread Tools

Backing Up Objects

 
 
Hal Vaughan
Guest
Posts: n/a
 
      07-09-2007
This seems to me to be an issue in dealing with pointers and cloning
objects. I understand that if I have two Objects, whether they're
something like a String or an object I define myself, then when I do:

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.

What I'd like to do is copy an object I've created that has a few HashMaps
in it to an entirely new object and make sure they are both separate.
Whenever the data in this program is saved, a backup copy of this object
would be created. That way, while I'm editing data in the program, if I
make a mistake, I can easily restore things to the last time I saved by
copying the back up object to the new object.

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
Vector is created, but the new one will still point to all the same objects
in the first Vector. If I iterate through the Vector and clone each Object
in it and store each cloned object in a new Vector, will that new Vector
have a copy of equivalent values without them being the same objects?

If that doesn't work, how can I create a backup of an Object so I can change
the values in one while the values in the other stay the same?

Thanks!

Hal
 
Reply With Quote
 
 
 
 
Stefan Ram
Guest
Posts: n/a
 
      07-09-2007
Hal Vaughan <(E-Mail Removed)> writes:
>String newString = oldString;


If this is compilable, then »oldString« is the a name of a
variable that contains a reference value. When this is
executed, the other variable (named »newString«) will contain
a copy of this reference value. But no object will be
altered in the course of this action.

>how can I create a backup of an Object


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.

 
Reply With Quote
 
 
 
 
Lew
Guest
Posts: n/a
 
      07-09-2007
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
 
Reply With Quote
 
Roedy Green
Guest
Posts: n/a
 
      07-09-2007
On Mon, 09 Jul 2007 01:38:13 -0400, Hal Vaughan
<(E-Mail Removed)> wrote, quoted or indirectly quoted someone
who said :

>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.


No. All you can do is make newString point to a different string.
OldString and all the references pointing to it are the same.

What you are describing is a char[].

If you change it, it changes for all references pointing to it.
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
 
Reply With Quote
 
Piotr Kobzda
Guest
Posts: n/a
 
      07-09-2007
Lew wrote:
> 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).


One would assume "String" is immutable:

public class String {
public java.lang.String value;
public String toString() { return value; }
}


piotr
 
Reply With Quote
 
Piotr Kobzda
Guest
Posts: n/a
 
      07-09-2007
Lew wrote:
> 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).


One would assume "String" is mutable:

public class String {
public java.lang.String value;
public java.lang.String toString() { return value; }
}


piotr
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      07-09-2007
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.


Lew wrote:
>> 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).


Piotr Kobzda wrote:
> One would assume "String" is mutable:
>
> public class String {
> public java.lang.String value;
> public java.lang.String toString() { return value; }
> }


You're just being argumentative.

Absent any specific disclaimer to the contrary, as the original post was, why
in the world would one figure that "String" meant anything other than
"java.lang.String"? If you wish to assume the OP is an idiot who reuses the
most fundamental class names, thus damaging maintenance, then perhaps, and
only perhaps, your point would have a micro-skootch of merit, but I refuse to
believe the OP was that stupid.

Be real.

--
Lew
 
Reply With Quote
 
Hal Vaughan
Guest
Posts: n/a
 
      07-10-2007
Lew wrote:

> 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.

>
> Lew wrote:
>>> 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).

>
> Piotr Kobzda wrote:
>> One would assume "String" is mutable:
>>
>> public class String {
>> public java.lang.String value;
>> public java.lang.String toString() { return value; }
>> }

>
> You're just being argumentative.
>
> Absent any specific disclaimer to the contrary, as the original post was,
> why in the world would one figure that "String" meant anything other than
> "java.lang.String"? If you wish to assume the OP is an idiot who reuses
> the most fundamental class names, thus damaging maintenance, then perhaps,
> and only perhaps, your point would have a micro-skootch of merit, but I
> refuse to believe the OP was that stupid.
>
> Be real.


I may be self taught and, because of that, have missed quite a few of the
basics (like the issue about others lists being better than vectors), but I
can assure you the OP is NOT that stupid.

Dense and stubborn, maybe, but not that stupid.

Hal
(The O.P.)
 
Reply With Quote
 
Twisted
Guest
Posts: n/a
 
      07-10-2007
OK, it's high time *someone* answered the OP's question here.

If you want to do a full deep copy of a data structure, just serialize
and deserialize it. If you want to, to a RAM buffer rather than a
(possibly temporary) disk file. (The TCP/IP loopback interface is
another intriguing possibility.) As an added bonus feature, if you
serialize to a .bak file on disk you get a disk backup that can be
restored later by deserializing it, e.g. after a program abend.

You need to make the stuff you use in this data structure
serializable. The standard collection classes already are
serializable. The Java Tutorial on Sun's Web site has further
information about serialization for beginners.

 
Reply With Quote
 
Hal Vaughan
Guest
Posts: n/a
 
      07-10-2007
Twisted wrote:

> OK, it's high time *someone* answered the OP's question here.
>
> If you want to do a full deep copy of a data structure, just serialize
> and deserialize it. If you want to, to a RAM buffer rather than a
> (possibly temporary) disk file. (The TCP/IP loopback interface is
> another intriguing possibility.) As an added bonus feature, if you
> serialize to a .bak file on disk you get a disk backup that can be
> restored later by deserializing it, e.g. after a program abend.
>
> You need to make the stuff you use in this data structure
> serializable. The standard collection classes already are
> serializable. The Java Tutorial on Sun's Web site has further
> information about serialization for beginners.


Thank you!

Now I have some good terms to use for searching. I can work it out from
there.

Hal
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
class objects, method objects, function objects 7stud Python 11 03-20-2007 06:05 PM
Backing up objects in db file Chris Stiles Python 8 03-05-2004 01:08 AM
backing up FB and TB Axl Firefox 23 12-19-2003 01:21 AM
Backing up mail in Mozilla James Messick Firefox 11 11-11-2003 07:27 PM
Re: Backing up and restoring Mozilla mail and news Leonidas Jones Firefox 1 08-07-2003 02:06 PM



Advertisments