Transient addition breaks backward compatibility

Question

Hi folks. I have the following problem. I made some changes to a class and I have serialised objects created before the changes. I hoped that the changes I made would still be backwards compatable and that I would still be able to deserialise legacy objects.
I made the following changes...
added
private transient int _hashcode = 0;and
private void readObject(ObjectInputStream ois) throws ClassNotFoundException, IOException {
         ois.defaultReadObject();
         _hashcode = calcHashCode();
}The changes were motivated by some profiling using JIP which indicated that the hashCode method of my class was being called very repetitively outside of my control, and instead I decided to cache the hashcode instead of recalculating it.
Unfortunately however, now I get a java.io.StreamCorruptedException when I try to deserialise a Hashtable containing old objects of this class. Now, I know I can hack a fix into the code; however, I would love if someone could point out my stupidity and tell me why the class is no longer backwards compatable. Is the transient element an issue, or am I doing something stupid with the readObject method? The calcHashCode() method simply reinitialises the _hashcode field by calculating it's values from other fields.
Thanks.
B.T.W. I use
public static final long serialVersionUID = 1l;

Answer 1

I don't suppose anyone is waiting with baited breath on this one, but I finally got back to the problem today and realised that my equals method which I also changed was the problem.
I wanted to speed up the equals method by ONLY checking that the hashcodes (which I cached) were equal and was being naive assuming the hashcodes would be unique for the input string. However, had a look at the birthday problem and figured that after hashing ~77,163 entries over the 2^32 Integer range that you are 50% likely to get a hash collision. Didn't realise the number was so small.
Now I initially check the hashcodes in the equals methods and if they are the same, then I check the data. This should at least speed up common non-equals comparisons. Apparently there was a collision in the hashtable I had previously serialised, so the integrity of the serialised hashtable must've been screwed with; hence the exception. When there is a collision in the hashtable, it reverts to the equals method.
Things I learnt:
#1 - Hash collisions are more likely than I thought
#2 - Keep to the equals, hashCode and compareTo regulations
#3 - Changing such methods can screw with backwards compatability of serilialised objects, not only adding removing fields
New equals:
public boolean equals(Object o) {
         if (o==this)
              return true;
         else if (o instanceof Blah){
              Blah b = (Blah)o;
          return b._hashcode==_hashcode
               && (b._data==_data || b._data.equals(_data));
         else return false;
}