• Post Reply Bookmark Topic Watch Topic
  • New Topic

General qn on object references  RSS feed

 
rakesh sugirtharaj
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What do reference variables actually contain? I thought that they somehow mysteriously map to object address on the heap, but wont that cause problems during deserialization? I mean, the address after Deserialization is not going to be the same when it was serialized isnt it?
 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
They do mysteriously map to object addresses on the heap.

Objects when serialised can be moved off the heap. They live in files or attached to ByteArrayOutputStreams or flying around the network. Whenever you deserialise these objects you have to reassign a variable name to them, otherwise they will disappear into some cyber-limbo until the garbage collector finds them.

And when you have an object on the heap, serialise and deserialise it, you have created a second (almost identical) object, which has a different address. As I said, you have to give it a variable name, and now you have two objects.
 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


should print: "false, true" assuming Foo has the correct serializing methods and overrides equals() and implements java.io.Serializable.
 
rakesh sugirtharaj
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think i wasnt clear with my question. Suppose my object,let me call it object1, contains another object's,say object2, reference as an instance variable. This instance-reference variable contains some mysterious link to the address of the object2 on the heap. When i serialize object1 and desrialize it wont there be problems in locating object2(deserialized version) because the memory locations on the heap might have changed right? Is there some sort of relative addressing involved with reference variables??
 
Campbell Ritchie
Marshal
Posts: 56534
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There is a way of sorting this out, and it is a lot simpler than you think. Any objects inside a Serializable object have to implement Serializable themselves.

I said this
Go here, download and unzip a copy of Thinking In Java (Bruce Eckel, 3rd edition) and look at the second part of the chapter about interfaces and inner classes (I think ch 8). (There is a 4th edition, but you have to pay for that! I've got it and just looking at the chapter for about 30 seconds, I don't think that much has changed.)
in a post two days ago.

Go and find that chapter 8, which I think explains serialization. It also explains what happens to references inside references. As far as I can remember the classes can recurse through all your references and keep them all together in a serialized object. So your references-to-references-to-references are all serialized and deserialized together.
 
Bill Shirley
Ranch Hand
Posts: 457
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by rakesh sugirtharaj:
I think i wasnt clear with my question. Suppose my object,let me call it object1, contains another object's,say object2, reference as an instance variable. This instance-reference variable contains some mysterious link to the address of the object2 on the heap. When i serialize object1 and desrialize it wont there be problems in locating object2(deserialized version) because the memory locations on the heap might have changed right? Is there some sort of relative addressing involved with reference variables??


If object1 has a reference to object2, and both are Serializable, you're fine.

If object1 truely has a "mysterious link" to object2 (because you casted an object to a byte or something equally crazy), then you'll have problems.

When a group of objects are serialized, the serialization mechanism "names" them all (they may be named 1, 2, 3, etc). If object1 references object2, and object2 referencs object1, then it doesn't infinitely recurse, it tells each that it is pointing to the other.

You can think of this as converting the "pointers to location on the heap" to "pointers to location in the serialization".
 
rakesh sugirtharaj
Ranch Hand
Posts: 151
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am really sorry to say this but i still dont understand the point. Let me make it clearer.

My object1 has object2 as an instance veriable. Both are serializable.Let my object2 reference contain a value,say the exact memory location of object2 on the heap, like a pointer as 4000(i suppose we can take it like that because references in some way refer to memory location on the heap)

Now i serialize object1 and the object2 reference gets stored as 4000. After sometime i deserialize it and it produces a new object1 and object2 on the heap but not in the same memory location. So my object2 reference value 4000 should be pointing at a wrong location right?

Please correct me if i am wrong!
 
Paul Clapham
Sheriff
Posts: 22823
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are wrong.

The reality is much simpler than that. Your object2 reference points to a location in memory which contains some data. Let's suppose the data is the string "Ack". You can call that location "4000" if you like but it doesn't matter. When you serialize that reference, the serialized version contains the information that object2 refers to some data in memory, and it also contains the value of that data. ("Ack") Then when you deserialize it, first the value of that data ("Ack") is put into memory somewhere (it doesn't matter where) and then the object2 reference is created and made to point to that data. Just like it did in the original version.

So the end result is that you have the same references pointing to the same data. They will likely be in different places now, but that doesn't matter.
 
Jesper de Jong
Java Cowboy
Sheriff
Posts: 16059
88
Android IntelliJ IDE Java Scala Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The point is that serialization isn't shallow; it's deep. When you serialize the object that 'object1' refers to, then the object that 'object2' refers to is also serialized along with it. And if the object that 'object2' refers to in turn contains references to more objects, then those objects are also serialized, etc. So when you serialize 'object1', you don't just serialize one object, but a whole tree of interconnected objects. It works recursively.

When you deserialize it, the whole tree is rebuilt (and all those objects will probably be at different addresses in memory).

Java works in such a way that you never have to think about memory addresses. There are no C or C++-style pointers in Java that you can directly manipulate (a reference is really a pointer, but there is no way to directly get the memory address of an object that a reference points to).
[ January 03, 2008: Message edited by: Jesper Young ]
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!