• Post Reply Bookmark Topic Watch Topic
  • New Topic

Question about == and restored Object after InputStream  RSS feed

 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi everyone, thanks for reading my question. I am currently having this problem with my project but I think if any of you expert can clearfy for me than I should be able to solve my problem. I will try not post my entire source code because that might take up too much time to read. so here it goes



A and B starts out referencing the same date object which is the default 1970/1/1 date. Than I write A to a file using OutputStream and read A
back with an InputStream. Now I am having problem.

The problem I am having is that the following code in my project after read/write

keep turn out to be //DO THAT. After some debugging last night using Eclipse led me to believe that althought I tested that A and B still have the same value, it's not the same object in the heap. Therefore (A == B) keep returning false for me. Does this mean that when you have ==, JVM is checking to see if both A and B is referencing the same object, not the value of the Object. Plus, would I use equalTo() or what other method to find out if the value is the same instead of ==

Thanks for all your suggestions
 
Rob Spoor
Sheriff
Posts: 21135
87
Chrome Eclipse IDE Java Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You're right: == uses reference equality. Object defines a method called equals that is meant for basically 99.99999% of all equality checks.
 
Campbell Ritchie
Marshal
Posts: 56592
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Two references might point to the same object before serialisation; after serialisation there will be a different object, so the == test may work beforehand and fail afterwards.
 
Davie Lin
Ranch Hand
Posts: 294
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
That's great, thanks for confirming my suspicions. I suppose my problem would be solved if I serialize both A and B that way they point to the same object, would the equals() method work for me as well?
 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I suppose my problem would be solved if I serialize both A and B that way they point to the same object...


The way to guarantee that both A and B still refer to the same object after deserialization, is to serialize and deserialize them at the same time.

Meaning... if you have an object (say C) with two instance variables A and B, which points to the same object, serializing C should work. Later when you deserialize C, this new object will have two instance variables which point to the same object.

would the equals() method work for me as well?


It would depend if the equal() method has been overridden properly. You need an equals() method that determines equality by the values it represents, not whether they are the same object.

Henry
 
Campbell Ritchie
Marshal
Posts: 56592
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
No, and yes.

If you serialise and deserialise twice (unless you can organise a readResolve() method) you will produce two different new objects.
Of course an overridden equals() method will return true if they are identical.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!