• Post Reply Bookmark Topic Watch Topic
  • New Topic

Different hashcode for an object before and after serialization  RSS feed

 
Sriniketh Kovin
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am studying Serialization from the SCJP 6 Kathy Sierra book. I came across this code snippet.



The output is as follows.
files.Cat@4d43691d
files.Cat@7f39ebdb

1) Why are the two hashcodes different?
2) Serialization is supposed to make and identical copy of any object and all its instance variables. So, if the hashcodes are different, are these objects located in different locations in heap?
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. Because they are different objects. Different objects don't have to have the same hashcode, unless they are equal.

2. "Identical" only means that the states (contents) of the two objects are the same. It doesn't mean that the two objects are at the same place in memory -- that would be impossible if the two objects were both in memory at the same time, and unreasonable to demand if they weren't.

You're trying to make something meaningful out of that default value of toString(). Try to resist doing that, it's just a more or less arbitrary thing.
 
Sriniketh Kovin
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So, both are two different objects and ergo two different memory locations.

So, after



1) Is the reference to the 1st object lost?
2) Is that object garbage collected? Since we have changed the reference of 'c' to a deserialized version?
 
Paul Clapham
Sheriff
Posts: 22819
43
Eclipse IDE Firefox Browser MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
1. You've only got one reference variable. Initially it pointed to the Cat object which you were about to serialize, and then you changed it to point to the new Act object which was created by the deserialization code. So yes, the original Cat object is now not accessible by anything in your code.

2. It isn't possible to look at code and predict when an inaccessible object will be garbage collected. And (except for some advanced applications) you shouldn't bother. Inaccessible objects will be garbage-collected if it's necessary, but that's all that can reasonably be said. It's more useful to be able to predict when an object will be eligible for garbage collection -- as for example the original Cat object will be.
 
fred rosenberger
lowercase baba
Bartender
Posts: 12563
49
Chrome Java Linux
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am not a serialization expert by any means, but I don't see why this would be any different from


On line 3, the original Cat object is lost, as the reference now points to a new instance. Does the first Cat get GC'd? who knows? It is certainly ELLIGIBLE for GC, but that doesn't mean it IS.
 
Campbell Ritchie
Marshal
Posts: 56525
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you want the same hash code from those serialised Cats, you would have to override the hashCode method.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!