The side-effects could include breaching the Singleton design pattern. Also if you alter your class, your SerialVersionUID might change, and it would then be impossible to Serialise or Deserialise objects of older versions of the class. Bound to be more side-effects.
Originally posted by Patricia Samuel: Can someone throw light on how does serialization breach singleton pattern?I am not able to figure out.
Someone can write a singleton instance to disk, and then read it back up, effectively getting a new instance. Even though the constructor is private, the serializable tools have special access to create instances of a class regardless. Source
Serialization should not be used for any kind of long-term storage.
One problem with serialization is that it works only as long as you don't change the classes that you serialize. Suppose you are building an application that saves its data by serializing a bunch of objects. And now suppose that you are developing a new version of the application. If you change anything in the classes that are serialized, the new version of your application will no longer be able to read the files saved by the old version. You'll get errors because the serialized objects don't match the classes anymore.
Serialization is useful for temporary, short-term storage or for transporting objects over a network (with RMI, for example), but it's not suitable as a general way to store data.