java.io.InvalidClassException: local class incompatible:

Question

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 it to the server correponding location, both classname.class and classname.java respectively.

It worked well in my own laptop but when I wanted to continue my work on other system , when I opened the projects folders and after client tries to connect to the server, the following error appears:

Exception in thread "main" java.io.InvalidClassException: projectname.clasname; local class incompatible: stream classdesc serialVersionUID = -6009442170907349114, local class serialVersionUID = 6529685098267757690
    at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:562)
    at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1582)
    at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1495)
    at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1731)
    at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1328)
    at java.io.ObjectInputStream.readObject(ObjectInputStream.java:350)

What is going on? Is it because I ran the program with an older version of the IDE?

EDIT

import java.io.Serializable;
import java.net.URL;

public class KeyAdr implements Serializable {
  private static final long serialVersionUID = 6529685098267757690L;

  public URL adr;
  public String key;
}

trutheality · Accepted Answer · 2012-04-30T05:41:09.907

94

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 serialVersionUIDs 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 default serialVersionUID 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 declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private 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 explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID 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;
    ...

edited Apr 30 '12 at 05:41

answered Apr 30 '12 at 05:29

trutheality

23,114
6
54
68

how to adjust the serialVersionUID in the definition? – lonesome Apr 30 '12 at 05:36
1

That's strange. I would double-check that both sides are using the newest version of the class. – trutheality Apr 30 '12 at 06:19
i even made two new projects with same name and created the classes from the beginning but still it happens – lonesome Apr 30 '12 at 06:39
have a look at my class in the edit, in case of i doind anything wrong – lonesome Apr 30 '12 at 06:41
5

try cleaning the project outputs (`.class` files generated at compilation time) and rebuild (recompile) the projects. – yair Apr 30 '12 at 06:47
@yair woow it worked out! and if you mentioned me in your comment, i would see your comment way before instead of wasting my time haha but thank you anyway :) – lonesome Apr 30 '12 at 07:37
@yair it's a little bit strange that why the hell the IDE not doing it automatically. i mea, it should recognize such changes ... to me it looks like a bug – lonesome Apr 30 '12 at 07:42
That's the wrong SUID, that's the one the local class already has. He needs `-6009442170907349114L`, the one from the stream. – user207421 Apr 30 '12 at 08:22
1

@EJP trying to match the SUID to a different version of the class isn't advisable. Updating the class at both ends was the right thing to do here. – trutheality Apr 30 '12 at 18:48
@trutheality It is fully 'advisable' as long as the rules in the Object Versioning section of the Object Serialziation Specification apply, in which case it would solve the OP's problem. – user207421 May 01 '12 at 00:22
Thx for sharing the information. Remember all of the key word here are required -- private static final long serialVersionUID = -476368215744086631L; – littletiger Aug 02 '16 at 21:41
Your answer and [jtahlborn's](http://stackoverflow.com/a/8336144/712526) combined contain all of the relevant details. Maybe the questions could be merged? – jpaugh Sep 20 '16 at 14:00
thank you your solution worked for me. I was sending objectMessage using JMS and had the same error, once i added the serialVersionUID everything worked fine. – user1512999 Mar 22 '17 at 05:59
Thank you for your answer. it helped me – Naveen Feb 26 '20 at 21:55

score 13 · Answer 2 · answered Mar 14 '18 at 09:52

One thing that could have happened:

1: you create your serialized data with a given library A (version X)
2: you then try to read this data with the same library A (but version Y)

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.

score 1 · Answer 3 · answered Feb 03 '20 at 08:12

1

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.

answered Feb 03 '20 at 08:12

Pekmezli Dürüm

81
4

score 1 · Answer 4 · answered May 16 '22 at 13:13

1

Try deleting/renaming the output file and recreate a new one if you had stored an object during testing, I had this error because I had serialized data to the same file in two different jFrame Classes.

answered May 16 '22 at 13:13

Tankiso Thebe

170
2
12

score 0 · Answer 5 · answered Apr 30 '12 at 05:29

0

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

answered Apr 30 '12 at 05:29

Mark Bramnik

39,963
4
57
97

score 0 · Answer 6 · edited Sep 20 '16 at 14:10

0

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)

edited Sep 20 '16 at 14:10

jpaugh

6,634
4
38
90

answered Apr 30 '12 at 06:05

Konstantin Pribluda

12,329
1
30
35

2

I can agree to a degree for persistence but there is nothing wrong with using Java Serialization as a transport format. It's too fragile if one doesn't know the concepts of Java serialization like `serialVersionUID`'s. – Sanjay T. Sharma Apr 30 '12 at 06:43
It isn't, really. Maybe we just see the 'Java serialization' world with different colored glasses. Plus it's pretty much the only option when using RMI. Also, I see that you had made some comment about 'project manager skinning something' which was edited out later... – Sanjay T. Sharma Apr 30 '12 at 08:47
"Slightest difference in class bytecode and JVM and your data is not readable anymore". This is simply untrue. See the Object Versioning section of the Object Serialziation Specification. – user207421 Apr 30 '12 at 10:06
@EJP Here's a link: [Versioning of Serializable Objects](https://docs.oracle.com/javase/8/docs/platform/serialization/spec/version.html) – jpaugh Sep 20 '16 at 14:12

score 0 · Answer 7 · answered Mar 08 '15 at 15:39

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".

Mr Big · Answer 8 · 2019-07-24T08:10:28.337

0

If you are using oc4j to deploy the ear.

Make sure you set in the project the correct path for deploy.home=

You can fiind deploy.home in common.properties file

The oc4j needs to reload the new created class in the ear so that the server class and the client class have the same serialVersionUID

edited Jul 24 '19 at 08:10

answered Jul 24 '19 at 07:31

Mr Big

1
2

score 0 · Answer 9 · answered Jul 06 '21 at 13:49

0

If you are using IntelliJ IDEA, go to File->Invalidate Caches. This will clear any cached classes which might cause this issue.

answered Jul 06 '21 at 13:49

Sneha Damle

604
1
5
6

score 0 · Answer 10 · answered May 11 '22 at 03:28

0

The autogenerated serialVersionUID would be same in different OS or JDK version. But if you add a function or a field, the autogenerated serialVersionUID will change.

answered May 11 '22 at 03:28

Roc King

431
6
18

java.io.InvalidClassException: local class incompatible:

EDIT

10 Answers10

Linked

Related