This content has been marked as final. Show 7 replies
Looks OK, the signature is correct, and none of the reasons you've advanced would explain why it isn't being called. I would check your deployment - is this version of the class really there when you execute?
yes it is the code that my deployment is running, if i change the queries object back into an "int", things work fine (readObject still not called), but when i change it to long, i get the exception.
is your PerformanceInfo class Serializable or Externalizable?
also, can you post the full stack trace of the exception you are getting?
Edited by: jtahlborn on May 9, 2008 10:55 AM
It is Serializable and does not extend any other class (except Object of course), here is the full stack trace:
Caused by: java.io.InvalidClassException: PerformanceReportRowInfo; incompatible types for field _queries
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
I can't explain why your readObject() method isn't being called unless it is a deployment issue, but I would suggest you use a technique that's better anyway.
Instead of changing the type, you leave it alone and add another field of type 'long'. Serialization can handle that without any difficulty. Then you just have to adjust the logic in your class to return the long field instead of the int field if it is non-zero. Keep the serialVersionUID the same.
You should follow this strategy for all serializable classes.
For general information about stream compatibility under serialization see the Versioning section in the Serialization Specification.
I know this thread has been dead a while but I have run into the same issue. I changed a field on the object being serialized from int to float. All that were serialized failed to deserialize of course. But, newly serialized objects were fine and they did go into the readObject method that was create with the new version of the object (same serialVersionId). So the old objects did not have a readObject() method when serialized but the new ones did. The old objects would never go in the readObject() method but the new ones did. This was very unexpected. It was not a Class Loader issue. It seems the objects are marked in some way so the JVM knows who has a readObject method when serialized and who does not, perhaps as a performance enhancement. Still researching to see if this is the case or not.
Review your observations. The readObject() method is called if it is defined in the class that is loaded when the deserialization occurs, period. It has nothing to do with what is in the stream, unless maybe the serialized object was originally Externalizable.