Clearly in Java it wouldn't make any sense to
save the actual value of a reference variable, because the value of a Java reference has
meaning only within the context of a single instance of a JVM. In other words, if you
tried to restore the object in another instance of the JVM, even running on the same
computer on which the object was originally serialized, the reference would be useless.
The text is from K&B (object graphs in Serialization),
However, its true, but when I try out the following code it sounds contradicting. I know I am missing something somewhere and can't understand it properly so please correct me.
The above program is serializing the ClassToSerialize object.
This class tries to read the ClassToSerialize object which was serialized previously.
According to the previously mentioned statement the "if you tried to restore the object in another instance of the JVM, even running on the same
computer on which the object was originally serialized, the reference would be useless." But the above class compiles successfully and gives output "doing some stuff". Correct me where I am going wrong.
And another thing, how to create another JVM instance ? Will it simply get created when i use the "java" command (which will execute the java.exe) or I have to open another command prompt and run the ReadSerialized class on that command prompt.
For a second JVM you probably do have to open a new command line. On a *nix box, you can probably make the java tool run in the background with the & operator. But it keeps the terminal occupied, so you cannot feed a new instruction.
What do they mean about object reference? I think that means the memory address where the object resides, not the state of the object you are deserialising.
Anyway, the idea of serialisation is to store the fields of an object. Your object hasn't got any fields, so it doesn't have any state to store. Try again with an object with fields, e.g. some numbers (primitives) and a String. Strings are always serialisable.
Your did the assignment of the reference yourself. Serialization had nothing to do with it.
The book talks about reference type fields of a serializable type. If you serialize and deserialize the object, the value of the fields will make no sense. So instead of serializing references, the serialization framework will try to serialize the object the reference points to. On deserialization, the framework will create new objects from this data, and assign a new reference to the field of the deserialized object.
So when you serialize an object, you may actually be serializing MANY, because the framework builds an object tree of all referenced serializable objects.
@Campbell Ritchie, thanks for confirming about another instance of the JVM. The class already has a method doStuff() which is its member but I still tried by creating a instance variable and the result is same, sorry for confusion about object reference, it's the memory address, you got it right.
@Stephan looked into your explanation and understanding it, actually the state of the object is being saved and when deserializing it the state is used to create a new object of same type with the help of the state saved during serialization. It helped . Thanks