java serialization serialversionuid

What is a serialVersionUID and why should I use it?


Eclipse issues warnings when a serialVersionUID is missing.

The serializable class Foo does not declare a static final
serialVersionUID field of type long

What is serialVersionUID and why is it important? Please show an example where missing serialVersionUID will cause a problem.



The docs for are probably about as good an explanation as you’ll get:

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:

ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

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.


  • 373

    So, what you are saying essentially is that if a user did not understand all the above material, said user aught not bother worrying about serialization? I believe you answered the “how?” rather than explaining the “why?”. I, for one, do not understand why I aught bother with SerializableVersionUID.

    – Ziggy

    Jan 1, 2009 at 7:27

  • 396

    The why is in the second paragraph: if you don’t explicitly specify serialVersionUID, a value is generated automatically – but that’s brittle because it’s compiler implementation dependent.

    – Jon Skeet

    Jan 1, 2009 at 20:26

  • 19

    And why does Eclipse say I need “private static final long serialVersionUID = 1L;” when I extend the Exception class?

    Jun 15, 2014 at 17:12

  • 24

    @JohnMerlino: Well I wouldn’t expect it to say you need one – but it may be suggesting one in order to help you serialize exceptions correctly. If you’re not going to serialize them, you really don’t need the constant.

    – Jon Skeet

    Jun 15, 2014 at 18:43

  • 18

    @JohnMerlino, to answer the why part of you question: Exception implements Serializable and eclipse warns that you have not set an serialVersionUID, which would be a good idea (if you wan’t to serialize the class) to avoid the problems that JonSkeet’s post outlines.

    – zpon

    Oct 8, 2014 at 11:48


If you’re serializing just because you have to serialize for the implementation’s sake (who cares if you serialize for an HTTPSession, for instance…if it’s stored or not, you probably don’t care about de-serializing a form object), then you can ignore this.

If you’re actually using serialization, it only matters if you plan on storing and retrieving objects using serialization directly. The serialVersionUID represents your class version, and you should increment it if the current version of your class is not backwards compatible with its previous version.

Most of the time, you will probably not use serialization directly. If this is the case, generate a default SerialVersionUID by clicking the quick fix option and don’t worry about it.


  • 87

    I’d say that if you’re not using serialization for permanent storage, you should use @SuppressWarnings rather than adding a value. It clutters the class less, and it preserves the abiity of the serialVersionUID mechanism to protect you from incompatible changes.

    Apr 24, 2011 at 10:43

  • 28

    I don’t see how adding one line (@SuppressWarnings annotation) as opposed to another line (serializable id) “clutters the class less”. And if you’re not using serialization for permanent storage, why wouldn’t you just use “1”? You would not care about the autogenerated ID in that case anyways.

    Apr 25, 2011 at 17:09

  • 75

    @MetroidFan2002: I think @TomAnderson’s point of serialVersionUID protecting you from incompatible changes is valid. Using @SuppressWarnings documents the intent better if you don’t wish to use the class for permanent storage.

    – AbdullahC

    Dec 30, 2011 at 14:32

  • 11

    “You should increment it if the current version of your class is not backwards compatible with its previous version:” You should first explore the extensive object versioning support of Serialization, (a) to ensure that the class really is now serialization-incompatible way, which per the specification is quite difficult to achieve; (b) to try a scheme such as custom read/writeObject() methods, readResolve/writeReplace() methods, serializableFields declarations, etc, to make sure that the stream remains compatible. Changing the actual serialVersionUID is a last resort, a counsel of despair.

    Dec 12, 2012 at 0:59

  • 4

    @EJP increment of serialVersionUID comes into picture when initial author of the class has introduced explicitly.I would say, jvm generated serial id, should be fine. this is the best answer that i saw on serialisation.

    Dec 24, 2014 at 15:39


I can’t pass up this opportunity to plug Josh Bloch’s book Effective Java (2nd Edition). Chapter 10 is an indispensible resource on Java serialization.

Per Josh, the automatically-generated UID is generated based on a class name, implemented interfaces, and all public and protected members. Changing any of these in any way will change the serialVersionUID. So you don’t need to mess with them only if you are certain that no more than one version of the class will ever be serialized (either across processes or retrieved from storage at a later time).

If you ignore them for now, and find later that you need to change the class in some way but maintain compatibility w/ old version of the class, you can use the JDK tool serialver to generate the serialVersionUID on the old class, and explicitly set that on the new class. (Depending on your changes you may need to also implement custom serialization by adding writeObject and readObject methods – see Serializable javadoc or aforementioned chapter 10.)


  • 39

    So one might bother with SerializableVersionUID if one were concerned about compatibility w/ old versions of a class?

    – Ziggy

    Jan 1, 2009 at 7:28

  • 15

    Yup, in case if the newer version changes any public member to protected, the default SerializableVersionUID will be different and will raise an InvalidClassExceptions.

    Jan 13, 2012 at 19:49

  • 3

    class Name, implemented interfaces, all public and protected methods,ALL instance variables.

    – Achow

    Mar 1, 2013 at 4:38

  • 36

    It is worth noting that Joshua Bloch advices that for every Serializable class it’s worth specifying the serial version uid. Quote from chapter 11: Regardless of what serialized form you choose, declare an explicit serial version UID in every serializable class you write. This eliminates the serial version UID as a potential source of incompatibility (Item 74). There is also a small performance benefit. If no serial version UID is provided, an expensive computation is required to generate one at runtime.

    Jul 8, 2014 at 13:25

  • 1

    Seems relevant. A link to a couple approaches to generate the serial version UID using IDEs:

    – Ben

    Dec 20, 2020 at 8:29