Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

serializing an object: references?  RSS feed

 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If I serialize an object(myHats) that has both a reference to a vector(hatsIOwn) and a direct reference to an object inside that vector(hatIWearMost), when I deserialize my main object will the "hatIWearMost" still be the same object that is inside the vector or does it deserialize as a different object that is not part of "hatsIOwn"?
Thanks,
Chris
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
When you serialize myHats, you will also end up serializing the Vector and all objects referenced by the Vector. When you deserialize, you will get copies of each of these objects, not the original. This is actually a simple way to code a deep copy, if that's what you want, rather than a shallow copy.
 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
what happens to "hatIWearMost"? When deserialized as a field inside "myHats" does it still reference an element that is also inside of (the now deserialized) "hatsIOwn"?
I guess what I really need to know is whether deserialized fields/vectors that reference the same objects before they are serialized will continue to reference that same "shared" object after deserialization. I just want to be sure that I don't end up with 2 copies of a hat when I only had one before I serialized.
Thanks,
Chris
 
Mike Pontillo
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
An interesting question. I about fainted when I read your message because I hadn't thought of that when I wrote some code to serialize a tree out to disk, where each tree node has an ArrayList child and a reference that points back to the parent. I took the toString() method out of my nodes and wrote some test code that prints out the objects as Strings (showing the reference addresses) and determined that the Serialized objects are indeed smart enough not to store multiple copies of the same obeject.
Cheers,
Mike
 
Chris Shepherd
Ranch Hand
Posts: 286
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks, Mike. I ended up doing some similar tests just to be sure and came up with the same results as you. Big sigh of relief. Crisis averted. Thanks for your help.
Chris
 
Jim Yingst
Wanderer
Sheriff
Posts: 18671
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sorry I overlooked your reply back on the 18th. To clarify - you get copies relative to the original data structure you were serializing from, but only one copied object per original object, regardless of how many references there were to that object. So let's say you start with a Vector v which contains 100 elements, and each element is a reference to the same Integer object. You have one Vector and one Integer with 100 references. Then you serialize the Vector and deserialize it, storing the result in v2. This is a new Vector object, which contains 100 references to a new Integer object. You don't get 100 new Integers from this operation, but you do get one new Integer (as well as one new Vector). Thus, serialization and deserialization is actually a simple way to perform a deep clone operation on a structure. If this cloning is undesreable, you can avoid it by defining a readResolve() method for the class being inadvertantly cloned - I can't locate good documentation for how this works at the moment (gotta get to work), but I imagine you can find something by poking around Sun's site if you need this. Good luck...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!