Thursday, April 8, 2010

serializable, serialVersionUID and Eclipse

The other day, I saw this in my current project
private static final long serialVersionUID = 1L;
Quick question around, "why are you adding the serial version UID to the class? Are you maintaining it, between different version of the class for clients of the application ? "
Of course not, and I knew the answer : Eclipse throws a warning otherwise, or automatically generates one.
Besides Eclipse configuration, again on an in-house when you exchange the object within the same application (lets say from application server to web server) what is the need of such ID ?

From the Serializable API

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

First, I am wondering how many people having fun with different compiler within the same project.

Then, does it really happen  that you have a different version between let's say a RMI client and the server. Again within the same application I am pretty sure that if you change the server code, you would like the client to have the same version.
And finally, what happen when someone change an attribute of the class ? Well of course the serial version uid is not being changed. ( Similar to hascode/ equals implementations not being updated)

Now let's have fun and check what would happen if I change the class with the same UID, and doing the worst case : deleting a field or renaming one. What happened ? nothing, no InvalidClassException no other exception, the object is just deserialized, with empty fields, since the previous ones have been removed.

No comments: