I created client and server and then added a class in client side for serializing purposes, then simply just went to the folder of the client in my hard drive and copy paste
If a class does not explicitly define a private static final long serialVersionUID
in the code it will be autogenerated, and there is no guarantee that different machines will generate the same id; it looks like that is exactly what happened.
Also if the classes are different in any way (using different versions of the class) the autogenerated serialVersionUID
s will also be different.
From the Serializable
interface's docs:
If a serializable class does not explicitly declare a
serialVersionUID
, then the serialization runtime will calculate a defaultserialVersionUID
value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declareserialVersionUID
values, since the defaultserialVersionUID
computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpectedInvalidClassExceptions
during deserialization. Therefore, to guarantee a consistentserialVersionUID
value across different java compiler implementations, a serializable class must declare an explicitserialVersionUID
value. It is also strongly advised that explicitserialVersionUID
declarations use theprivate
modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID
fields are not useful as inherited members. Array classes cannot declare an explicitserialVersionUID
, so they always have the default computed value, but the requirement for matchingserialVersionUID
values is waived for array classes.
You should define a serialVersionUID
in the class definition, e.g.:
class MyClass implements Serializable {
private static final long serialVersionUID = 6529685098267757690L;
...
If you are using the Eclipse IDE, check your Debug/Run configuration. At Classpath tab, select the runner project and click Edit button. Only include exported entries must be checked.
One thing that could have happened:
Hence, at compile time for the version X, the JVM will generate a first Serial ID (for version X) and it will do the same with the other version Y (another Serial ID).
When your program tries to de-serialize the data, it can't because the two classes do not have the same Serial ID and your program have no guarantee that the two Serialized objects correspond to the same class format.
Assuming you changed your constructor in the mean time and this should make sense to you.
I believe this happens because you use the different versions of the same class on client and server. It can be different data fields or methods
Serialisation in java is not meant as long term persistence or transport format - it is too fragile for this. With the slightest difference in class bytecode and JVM, your data is not readable anymore. Use XML or JSON data-binding for your task (XStream is fast and easy to use, and there are a ton of alternatives)
The exception message clearly speaks that the class versions, which would include the class meta data as well, has changed over time. In other words, the class structure during serialization is not the same during de-serialization. This is what is most probably "going on".