Why serialversionuid

Improve this question. Find a good practise about serialversionUID; dzone. Add a comment. Active Oldest Votes. Serializable 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.

Improve this answer. Jon Skeet Jon Skeet 1. 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? 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.

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

Show 18 more comments. MetroidFan MetroidFan 28k 16 16 gold badges 61 61 silver badges 79 79 bronze badges. 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. 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. Using SuppressWarnings documents the intent better if you don't wish to use the class for permanent storage.

Changing the actual serialVersionUID is a last resort, a counsel of despair. I would say, jvm generated serial id, should be fine. Show 7 more comments. Praveen Kumar Verma 2, 2 2 gold badges 13 13 silver badges 29 29 bronze badges. Scott Bale Scott Bale Yup, in case if the newer version changes any public member to protected, the default SerializableVersionUID will be different and will raise an InvalidClassExceptions.

It is worth noting that Joshua Bloch advices that for every Serializable class it's worth specifying the serial version uid. Quote from chapter 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 There is also a small performance benefit. If no serial version UID is provided, an expensive computation is required to generate one at runtime.

Seems relevant. If the poster said "i'm serializing this thing and But the questioner also wants to know why he might not want to be warned. The questioner obviously cares about why there should be an UID. So simply telling him to ignore the warn should be downvoted. Alexander Torstling Alexander Torstling Adding or removing non-transient fields doesn't make the class serialization-incompatible. There is therefore no reason to 'bump it' on such changes. EJP: Huh? Adding data definitely changes the serialization data in my world.

AlexanderTorstling Read what I wrote. I didn't say it doesn't 'change the serialization data'. I said it 'doesn't make the class serialization-incompatible'. It isn't the same thing. You need to read the Versioning chapter of the Object Serialization Specification.

EJP: I realize that adding a non-transient field doesn't necessarily mean that you make the class serialization-incompatible, but it is a structural change which alters the serialized data and you usually want to bump the version when doing so unless you handle backwards compatibility, which I also explained later in the post.

What is your point exactly? My point remains exactly what I said. Adding or removing non-transient fields doesn't make the class Serialization-incompatible. You therefore don't need to bump the serialVersionUID every time you do so. The javadocs for Serializable say : the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassException s during deserialization.

Therefore, you must declare serialVersionUID because it give us more control. Jens Bannmann 4, 5 5 gold badges 47 47 silver badges 74 74 bronze badges. Thalaivar Thalaivar Vinothbabu but serialVersionUID is static so static variables cannot be serialized. The one thing not mentioned in this answer is that you may cause unintended consequences by blindly including serialVersionUID without knowing why.

Tom Anderson's comment on MetroidFan's answer addresses this: "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 ability of the serialVersionUID mechanism to protect you from incompatible changes. The fully-qualified class name is that. It is a version indicator. Gray k 22 22 gold badges silver badges bronze badges. Rupesh Rupesh 2, 1 1 gold badge 24 24 silver badges 42 42 bronze badges.

Please explain what difference it makes. So different numbering schemes of different classes and libraries can't interfere in any way. Or did you imply code-generating libraries? The thing I always found crazy was that the algorithm to derive serialVersionUID when none is explicitly declared is based on package, name, attributes but ALSO methods Show 2 more comments. First I need to explain what serialization is. There are some rules for serialization.

An object is serializable only if its class or its superclass implements the Serializable interface An object is serializable itself implements the Serializable interface even if its superclass is not. InvalidClassException in runtime All primitive types are serializable. Static fields with static modifier are not serialized. Where we need serialVersionID: During the deserialization to verify that sender and receiver are compatible with respect to serialization.

Let's try this with an example. FileOutputStream; import java. IOException; import java. FileInputStream; import java. Not to execute the Writer class and you will get the exception. Exception in thread "main" java. InvalidClassException: com. JegsVala JegsVala 1, 17 17 silver badges 26 26 bronze badges. You can encounter this situation when you are communicating with a server that has updated its 3rd party libs, but you the client did not yer done this.

Paul Brinkley 6, 3 3 gold badges 22 22 silver badges 33 33 bronze badges. If you're not going to serialize the objects, why are they Serializable? It isn't mentioned anywhere in the Java Language Specification. It's mentioned in the Object Versioning Specification. Here is the link to the Java 8 Object Versioning Specification. I think you're right that composition over inhneritance makes more sense, particularly when you're discussing classes such as ArrayList.

However, many frameworks require people to extend from abstract superclasses which are serializable such as Struts 1. I think you're right, it would be nice if the warning were ignored in certain cases like if you were extending from an abstract serializable class — piepera. Surely if you add a class as a member, rather than inheriting from it, you would have to write a wrapper method for EVERY method of the member class that you wished to use, which would make it unfeasible in a large number of situations But I suppose that this case is a sign of a design mistake - the users of your class e.

What I don't like about delegation is the need to hold a reference to the delegate. And every reference means more memory.

Correct me if I'm wrong. If I need a CustomizedArrayList of objects then this wouldn't matter much but if I need hundreds of CustomizdeArrayLists of a few objects then memory usage increases significantly.

Throwable is serializable, and only Throwable is throwable, so it's not possible to define an exception that isn't serializable. Delegation isn't possible. Nitesh Soni Nitesh Soni 2 2 silver badges 3 3 bronze badges. The algorithm doesn't vary, but it is slightly under-specified. ID RMI:com. FileInputStream fis. Next Serialization and Deserialization in Java with Example.

Recommended Articles. Article Contributed By :. Bishal Kumar Dubey. Easy Normal Medium Hard Expert. Writing code in comment? Please use ide.

Load Comments. What's New. Most popular in Java. This versioning technique is useful if we store serialized data which survives several versions of your code.

Read more : Java serialization compatible and incompatible changes. So the deserialized class type must be in the classpath. Uninitialized non-serializable, non-transient instance fields are tolerated. Different compilers, or different versions of the same compiler, will generate potentially different values. Computation of serialVersionUID is based on not only fields, but also on other aspect of the class like implement clause, constructors, etc.

So the best practice is to explicitly declare a serialVersionUID field to maintain backward compatibility. If we need to modify the serializable class substantially and expect it to be incompatible with previous versions, then we need to increment serialVersionUID to avoid mixing different versions. Happy Learning!! Subscribe to get new post notifications, industry updates, best practices, and much more. Directly into your inbox, for free. The result mentioned in the example is wrong and need to be corrected.

I assume because the serialVersionUID is not serialized but the class is. Also its not required to serialize the serialVersionUID. Its just for the JVM to uniquely identify the class during deserialization. What is the difference whether we use default serial version UID i. Serial version id is used while de-serialization. If its generated, then changing class structure will change the serial version id as well.

You can assume them as version number for classes. There are two ways. So what is the difference between these two aproaches? You stated that static fields can not be serialized.

But i can get the static field data after deserialization. You are assigning the value of age during instance creation initialized with it. So, when de-serilization happens; it first creates a blank object age is set at this stage only ; and now serialized values are read and overwritten on field of Employee instance. Please run the code into two steps. I have removed the static initialization from Employee class, and writing to it when I am serializing the Employee class only.

If it was serialized then I must get it back during deserialization, BUT i do not. The answer is yes, provided that the non-serializable super-class has a no-arg constructor, which is invoked at de-serialization to initialize that super-class. In one of my business use case i need to implement the reverse of the above quoted line i. So is there any way of serializing only the super class using your subclass ref without change the structure of the subclass.?

It will prevent the subclass fields to serialize and still you have the same structure. Basically, the difference between Serializable and Externalizable is on default capabilities. Classes which implement Serializable, the serialization of the object is taken care of automatically, while classes that implement Externalizable is responsible for serializing itself, without the help of default serialization procedures.

Only the identity of the class of an Externalizable instance is written in the serialization stream and it is the responsibility of the class to save and restore the contents of its instances.