I have read that you serialize to save the state of the object then why is it that if i print an object before serializing it in a file and if i print it after serializing it by reading it from a file ..both the object comes out to be different in the out put !!!
Thanks in Advance!!!
Tarun Oohri wrote:
Why the output coming is different ie.
Both the objects are suppose to come out same.
You have not created a toString() method for your class so those values do not represent the state of the object but are in some ways related to the address of the object in memory. Since you now have two different objects they have different addresses so have different values.
Joined: Feb 20, 2013
I am still not able to tell, SCJP book says on page 459 "serialization save the object & all of its instance variables."
If i am saving an object in a file and extracting it , all i want that both the objects should be same....here what i am not getting....overriding toString() will just return same String to all the objects of that class, which certainly do not answers my question.
Tarun Oohri wrote:I am still not able to tell, SCJP book says on page 459 "serialization save the object & all of its instance variables."
Which your code does.
If i am saving an object in a file and extracting it , all i want that both the objects should be same
Both objects have the same content but they are not the same object! The object read from the file is a clone of the object written to the file.
....here what i am not getting....overriding toString() will just return same String to all the objects of that class, which certainly do not answers my question.
When your write the object using
you automatically invoke the toString() method on the object but unless you override the toString() method you will invoke the toString() method of the parent class which in your case is class Object. The toString() method of class Object just creates a String that is in some way related to the address of the object in memory.
Do you understand what printing an object that does not have toString() and hashCode() overridden, does?
It will use the toString() from class java.lang.Object. Look in the API documentation what that method does: it prints the class name, an @, and the hash code of the object in hexadecimal.
If you also didn't override hashCode(), then the hash code will be whatever Object.hashCode() returns. What that number is, isn't specified. But in Oracle's JVM, it will be something that indicates the address of the object.
If you deserialize an object from a file, a new object is created that will be initialized with the values that are in the file. But there is no guarantee that the new object will be at the same location in memory as the original object. So there's no reason to expect that Object.hashCode() will return the same value as for the original object.
That is misleading. Serialisation turns the state of the object and all its non‑transient instance fields into a series of bytes which can be sent over a network, stored in a file, etc. Except forenum constants, there is no guarantee that the original object will be recreated. In fact, a fresh instance is usually created. The Java Serialization Specification (§1.1=“overview”) specifically says new instance.
Joined: Oct 13, 2005
You would have to write your own serialisation mechanism if you need to retrieve the exact same object.
Joined: Feb 20, 2013
Thank you Ritchie & Jesper de Jong for always correcting my doubts ... Respect !!!