Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

what is the use of the private static long serialVersionUID variable ?

 
mohan rajv
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
While implementing Serializable interface,we are using a private static long serialVersionUID variable.what is the use of this variable?
 
Sridhar Santhanakrishnan
Ranch Hand
Posts: 317
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
From javadocs

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:
 
Campbell Ritchie
Sheriff
Posts: 48404
56
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Too difficult a question for us beginners. Moving.

You can do several things with a SUID:
  • Ignore it. Then an object can be deserialised with all versions of its .class file.
  • Insert an arbitrary value. Then objects can be deserialised if they have the same SUID.
  • Use a generated SUID, which is rather like a hash code for the .class file. Then objects can be deserialised is they have the same SUID.
  • Copy a generated SUID from an old version of the .class file. Then objects can be deserialised if they have the same SUID.


  • If you have two classes with the same name, and different SUIDs, the JVM will assume they are different and incompatible versions of the class, and only deserialise objects when they have the same SUID as the .class file. You can usually only get different SUIDs if you have different versions of the class, which usually means using different JVMs.
     
    Mike Simmons
    Ranch Hand
    Posts: 3028
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Campbell Ritchie wrote:Ignore it. Then an object can be deserialised with all versions of its .class file.

    If you ignore it - that is, if you don't provide an SVUID in the class - then one will be generated for you, based on the non-private attributes of your class. You will continue to get the same generated SVUID only as long as you don't change those parts of the class that are used to generate the SVUID. You can change code inside any method, for example, without changing the SVUID. But if you change the name of any non-private method, or add or remove a non-private method, you will get a new SVUID. Which means the new class file will be incompatible with the old one. This happens even if you never specified anything about the SVUID in the class.

    Campbell Ritchie wrote:You can usually only get different SUIDs if you have different versions of the class, which usually means using different JVMs.

    A common example where this can occur is if you've got an application that writes serialized data in order to look it up again the next time the application is run. If you update the code base and then restart the application, you can discover that you're no longer able to read the old serialized files.
     
    Campbell Ritchie
    Sheriff
    Posts: 48404
    56
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thank you for the clarification, Mike
     
    Rob Spoor
    Sheriff
    Pie
    Posts: 20495
    54
    Chrome Eclipse IDE Java Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Mike Simmons wrote:
    Campbell Ritchie wrote:Ignore it. Then an object can be deserialised with all versions of its .class file.

    If you ignore it - that is, if you don't provide an SVUID in the class - then one will be generated for you, based on the non-private attributes of your class.

    Not just the non-private attributes. All instance fields are used in the generated SVUIDs, also the private ones. You could be right about the methods though, I haven't noticed that. Method contents don't have any influence on the SVUID though.
     
    Mike Simmons
    Ranch Hand
    Posts: 3028
    10
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Good catch, Rob. I used the intentionally vague term "attributes" rather than "fields", because I wanted to also include method signatures and constructor signatures, which are only included if they're non-private. But yes, for fields, private fields are included too. I phrased it badly.

    For anyone who wants more rigorous info on how the SVUID is generated, look here.
     
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic