0

I have a class InvalidClassException with serial version id private static final long serialVersionUID = -5086279873877116405L;.The old value for serialVersionUID for this class is -6871353730928221293L.

Now i am getting the exception

java.io.InvalidClassException: com.navtech.kernel.flat.FlatValidationException; local class incompatible: stream classdesc serialVersionUID = -6871353730928221293, local class serialVersionUID = -5086279873877116405L.

Whats wrong here.

user207421
  • 305,947
  • 44
  • 307
  • 483
Satheesh
  • 163
  • 1
  • 3
  • 11
  • 2
    This is issue is related to serialization. Please check this [SO post](http://stackoverflow.com/questions/285793/what-is-a-serialversionuid-and-why-should-i-use-it) – Maciej Lach Aug 12 '15 at 10:46
  • Check this out too: http://stackoverflow.com/questions/29664624/local-class-incompatible-error-when-only-a-method-has-changed/29664847#29664847 – Sampath Aug 12 '15 at 10:51
  • You are **not** getting a `ClassCastException`, or a `FlatValidationException` either, whatever that might be. Read it. – user207421 Aug 12 '15 at 10:55
  • FlatValidationException is my class name – Satheesh Aug 12 '15 at 12:07

3 Answers3

0

This is to be expected. The serialVersionUID is used to differentiate between different versions of the same Serializable class. Most likely there is a good reason for the change in the version, and it really cannot be deserialized as the new version.

meskobalazs
  • 15,741
  • 2
  • 40
  • 63
  • There was code change and we removed some attribute that is why we changed the serialVersionUID.So what is the solution to resolve this issue.From where it is getting the old serialVersionUID. – Satheesh Aug 12 '15 at 12:14
  • If that is the case, you can no longer deserialize those objects. If you need to know what is in them, you can use tools like `jdeserialize`. – meskobalazs Aug 12 '15 at 12:17
0

When an object is serialized, the serialVersionUID is serialized along with the other contents.

Later when that is deserialized, the serialVersionUID from the deserialized object is extracted and compared with the serialVersionUID of the loaded class.

The numbers are not matching so this exception.

To fix this issue:- Serialize the class with new serialVersionUID before deserailization.

Amit Bhati
  • 5,569
  • 1
  • 24
  • 45
0

Incompatible Changes that are specified in the Doc:

Incompatible changes to classes are those changes for which the guarantee of interoperability cannot be maintained. The incompatible changes that may occur while evolving a class are:

  • Deleting fields - If a field is deleted in a class, the stream written will not contain its value. When the stream is read by an earlier class, the value of the field will be set to the default value because no value is available in the stream. However, this default value may adversely impair the ability of the earlier version to fulfill its contract.

  • Moving classes up or down the hierarchy - This cannot be allowed since the data in the stream appears in the wrong sequence.

  • Changing a nonstatic field to static or a nontransient field to transient When relying on default serialization, this change is equivalent to deleting a field from the class. This version of the class will not write that data to the stream, so it will not be available to be read by earlier versions of the class. As when deleting a field, the field of the earlier version will be initialized to the default value, which can cause the class to fail in unexpected ways.

  • Changing the declared type of a primitive field Each version of the class writes the data with its declared type. Earlier versions of the class attempting to read the field will fail because the type of the data in the stream does not match the type of the field.

  • Changing the writeObject or readObject

    method so that it no longer writes or reads the default field data or changing it so that it attempts to write it or read it when the previous version did not. The default field data must consistently either appear or not appear in the stream.

  • Changing a class from Serializable to Externalizable or vice versa

    is an incompatible change since the stream will contain data that is incompatible with the implementation of the available class.

  • Changing a class from a non-enum type to an enum type or vice versa

    since the stream will contain data that is incompatible with the implementation of the available class.

  • Removing either Serializable or Externalizable is an incompatible change

    since when written it will no longer supply the fields needed by older versions of the class.

  • Adding the writeReplace or readResolve method

    to a class is incompatible if the behavior would produce an object that is incompatible with any older version of the class.

In your case there is a chance of having issue with moving the class hierarchy because when there is inheritance problem the class which has its own specific serialUID will not overrided in the stream that already generated. 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. hope this helps!

Jagadish Sharma U
  • 496
  • 2
  • 11