Query on Java Serialization

overexchange

I am facing below issue, after adding new member methods in existing class Response implements Serializable{}. There is no explicit serial version id declared. On multiple try, am getting the same serial numbers.

Error communicating with the webserver: com.abc.xyz.app.util.common.Response;
local class incompatible: stream classdesc serialversionUID = 
-3900355805473150430, local class serialversionUID = 
-6706527232726476603

After going through some documentation, i tried modifying the class Response with additional line: private final static long serialVersionUID = 1L; .

With this change, below is the error:

Error communicating with the webserver: com.abc.xyz.app.util.common.Response;
local class incompatible: stream classdesc serialversionUID = 
-3900355805473150430, local class serialversionUID = 1

These are the classes that sit in webapps folder of tomcat and get loaded as xyz.jnlp on client machine. Fresh client machine is taken to load xyz.jnlp from remote webserver. But things does not work!!!

Please help me understand this problem.

JB Nizet

When serializing an object, the serial version UID of the class is written to the stream. If the class doesn't have one, it's automatically generated using a deterministic algorithm.

When deserializing an object of a given class, the serial version UID of the local class (hard-coded or generated) is compared to the one in the stream. And if they don't match, you get an exception: that means the classes are not compatible.

So, to fix your problem, you have 2 choices:

  1. make sure the server and the client always share the same class. That is the best, easiest solution. But it requires that all the clients are updated every time the server is updated.
  2. make sure the classes are always compatible. Since your old class didn't have a hard-coded serialVersionUID, and you want to change the class and keep it compatible, you need to hardcode a serialVersionUID with a value that is identical to the one that was automatically generated for the initial version of the class. And of course, you have to be aware that if you add fields, the receiver won't be able to read them, and that if you remove fields, the receiver's value for these fields will be null, which might break the invariants.

Unless you completely understand the implications of your changes, which is hard and requires reading the serialization specification, my advice would be to go with option 1: keep the client and the server up to dates.

Collected from the Internet

Please contact [email protected] to delete if infringement.

edited at
0

Comments

0 comments
Login to comment

Related