Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

What are the pros and cons of using serialVersionUID and @SuppressWarnings("serial") on classes implementing Serializable?

This question has been the subject of some lively discussions in my team. My personal choice is to use

@SuppressWarnings("serial")

My thoughts are that it means there is one less thing to maintain compared to using

serialVersionUID

Am I correct in thinking that using this allows the compiler to generate the UID and is therefore more likely to pick up changes to the class?

My biggest fear is that relying on a developer to change the UID when they change the class is more likely to lead to unforeseen errors.

Are there any pitfalls to my approach? Has anyone else had good or bad experiences using either of these approaches?

like image 741
James DW Avatar asked Oct 03 '11 14:10

James DW


People also ask

What is the use of serialVersionUID in serialization?

The serialization at 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.

What is the use of serialVersionUID and if not used what is the impact?

Simply put, we use the serialVersionUID attribute to remember versions of a Serializable class to verify that a loaded class and the serialized object are compatible. The serialVersionUID attributes of different classes are independent. Therefore, it is not necessary for different classes to have unique values.

What is serializer and deserializer in Java?

Serialization is a mechanism of converting the state of an object into a byte stream. Deserialization is the reverse process where the byte stream is used to recreate the actual Java object in memory. This mechanism is used to persist the object. The byte stream created is platform independent.

What value should I use for serialVersionUID?

1L. Puts serialVersionUID=1L ; It should be sufficient in most cases.


1 Answers

It boils down to this questions:

  • Shall the serialized streams be read and written by the just same code or by different code?

"Different code" can mean several things:

  • old versions vs. new versions
  • two independent programs with perhaps old and new libraries
  • more of stuff like that.

In these cases you should strongly adhere to the Serialization contracts - and this not done by just setting serialVersionUId - usually you must also overwrite the methods for serialization and deserialization to cope with different versions.

If - on the other hand - the same program reads and writes the stuff for something like an internal cache and that cache can be rebuild from scratch on when the software is updated - then feel free to make your life as easy as you can.

Between these extremes are of course various shades of grey.

like image 167
A.H. Avatar answered Oct 20 '22 02:10

A.H.