When class implements Serializable in eclipse i have two options: add default serialVersionUID(1L) or generated serialVersionUID(3567653491060394677L). I think that first one is cooler, but many times i saw people using the second option. is there any reason to generate long serialVersionUID?
+8
A:
As far as I can tell, that would be only for compatibility with previous releases. This would only be useful if you neglected to use a serialVersionUID before, and then made a change that you know should be compatible but which causes serialization to break.
See the Java Serialization Spec for more details.
Michael Myers
2009-05-20 14:44:50
+3
A:
The purpose of the serialization version UID is to keep track of different versions of a class in order to perform valid serialization of objects.
The idea is to generate an ID that is unique to a certain version of an class, which is then changed when there are new details added to the class, such as a new field, which would affect the structure of the serialized object.
Always using the same ID, such as 1L means that in the future, if the class definition is changed which causes changes to the structure of the serialized object, there will be a good chance that problems when trying to deserialize an object.
If the ID is omitted, Java will actually calculate the ID for you based on fields of the object, but I believe it is an expensive process, so providing one manually will improve performance.
Here's are a couple of links to articles which discuss serialization and versioning of classes:
coobird
2009-05-20 14:45:33
The idea behind using 1L is so that you increment it every time you change the class properties or methods.
R. Bemrose
2009-05-20 14:47:42
Thank you for the information :)
coobird
2009-05-20 14:51:31
There is no runtime performance impact of allowing the serialversionUID to be generated automatically - it's generated at compile time by javac...if you decompile the class's bytecode, you'll actually see the variable statically in the bytecode.
Jared
2009-05-20 18:58:00
One more note - by managing the number explicitly you get to decide when you consider versions of a class "compatible", rather than requiring the class definition to be exactly the same.
Scott Stanchfield
2009-05-21 13:56:32
@ JaredAccording to Item 75 in Josh Bloch's Effective Java: 2nd Edition: "declare an explicit serial version UID in every serializable class you write.... If no serial version UID is provided, an expensive computation is required to generate one at runtime."
ckeh
2009-12-17 00:54:13
+4
A:
The main reason for the generated one would be to make it compatible with an existing version of the class that already has persisted copies.
Robin
2009-05-20 14:45:43
A:
If you don't specify a serialVersionUID then Java makes one on the fly. The generated serialVersionUID is that number. If you change something in your class that doesn't really make your class incompatible with previous serialized verisons but changes the hash, then you need to use the generated very-large-number serialVersionUID (or the "expected" number from the error message). Otherwise, if you are keeping track of everything yourself, 1, 2, 3... is better.
joeforker
2009-05-20 14:45:50
+3
A:
The "long" default of the serialVersionUID is the default value as defined by the Java Serialization Specification, calculated from the default serialization behaviour.
So if you add the default version number, your class will (de-)serialize faster as long as nothing has structurally changed, but you'll have to take care that if you change the class (add/remove fields) you also update the serial number.
If you do not have to be compatible to existing bit streams, you can just put 1L there and increment the version as needed when something changes. That is, when the default serialisation version of the changed class would be different from the default version of the old class.
David Schmitt
2009-05-20 14:49:37