• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

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

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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?
 
Ranch Hand
Posts: 317
  • Likes 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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:

 
Marshal
Posts: 79177
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
     
    Master Rancher
    Posts: 4806
    72
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    Marshal
    Posts: 79177
    377
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thank you for the clarification, Mike
     
    Sheriff
    Posts: 22783
    131
    Eclipse IDE Spring VI Editor Chrome Java Windows
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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
    Master Rancher
    Posts: 4806
    72
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • 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.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic