Serialization and serialVersionUID in Java

I recently had with a colleague, a very controversial discussion on "Serialization and serialVersionUID. And I started the discussion with the following designs and ideas put forward. :cool:

If a Java class can implement the interface Serializable and does not define any static class variable called serialVersionUID, you get the following warning from Eclipse:

The serializable class XYZ Does not declare a static final serialVersionUID field of type long.

I want you now to give time for reflection, whether this mechanical response is really useful. First, one must be clear about what you need serialization at all and what is the meaning of these serialVersionUID actually. This is, among other things, the case when it comes to transfer Java objects in binary form based on a network protocol (eg RMI or Spring HTTP invoker) between a client and an Application Server. If I want to send an instance of the class XYZ from client to server, the class must be serializable and XYZ be known on both the client and the server.

Here it can happen in principle, that is present on the client a different version of the class as on the server, so an inconsistency between the client and server exist, which can easily lead to a malfunction of the application. To detect such inconsistencies, but it is exactly the serialVersionUID mechanism. Constitutes the JRE is deserialized on a fixed network received instance, the serialVersionUID of this instance does not match the serialVersionUID of the loaded class, it throws an exception, so the inconsistency detected quickly and (for example, by redeployment of the application) can be adjusted.

Anyone having different opinions feel free to post here.

What actually happens when it is specified in a serializable class has no explicit serialVersionUID? Then is given implicitly by the JRE when loading a class. And while this is done through a complicated calculation, included in the all class attributes and the signatures of all non-private methods. This means that once you add a class attribute, a delete, change the type or something changes in the interface automatically changes implicit serialVersionUID. Changing only the implementation of a method, this has no effect on the calculated implicit serialVersionUID!

If I decide to award an explicit serialVersionUID, so I'm in the duty to maintain this in the future! So that for each class change, which I do, I need to think about whether I need to change the serialVersionUID. In my experience, does so almost no developer and I have even this little pleasure. But if the serialVersionUID is not maintained, the whole mechanism is bypassed and useless. Because of these considerations, I usually do without an explicit serialVersionUID to serializable classes instead and add more annotation.

It sounds interesting and plausible. What happens if you can generate from Eclipse any UID, but the default UID used?

• private static final long serialVersionUID = 1L;

Is it the same way then, as if a generated id with the class version does not change, or more so that when loading the class a new UID is generated. If the latter is the case, you could be generated in the Eclipse always DefaultId.

Quote:

---

Is it the same way then, as if a generated id with the class version does not change, or more so that when loading the class a new UID is generated. If the latter is the case, you could be generated in the Eclipse always DefaultId.

---

What value for serialVersionUID is set, not interested in the VM. As soon as one is set, does not generate internally. Thus, one must again take care of itself to the consistency of versions etc.. It therefore makes no difference whether the value to 1 or is a value generated by Eclipse.

My arguments have yet a small mistake by the way: the calculation of the implicit serialVersionUID does not happen when loading the class but the first time you serialize / deserialize an instance. But that is irrelevant because it happened more than once after loading the class. There used to time the argument that the calculation cost of the implicit serialVersionUID time. But this is irrelevant, because the few milliseconds, the price of this one-time calculation, in a typical enterprise application completely irrelevant.

I personally almost never produce an explicit serialVersionUID, so strike just such inconsistencies. The only exception: if the serialized data is not transient (eg, temporarily stored), I forgive a UID, so I at least have the chance to deserialize the data, if that took place during the storage of a deployment. I effective Java just not at hand will put the recommendation on a UID there always justified in any way?

The grounds of Bloch, is that the calculation of serialVersionUID extremely sensitive response to changes in the class, ie even a small change (eg in a method or class variable) that a different value comes out. When I enter a client / server scenario but does not allow that there are different levels on client and server of a serializable class (because this would entail a considerable additional complexity, I would have to dominate), this sensitivity to change but just what I want: an automatic mechanism reveals the different levels on client and server side. A very different scenario is the long-term storage of serialized instances on record. It uses a sophisticated versioning approach is needed, since I at a later date must be able to read again what I have written out at some times. In such a scenario, an explicit serialVersionID it will become very important.