Java Practices -> Implementing Serializable

readObject and writeObject:

• readObject implementations always start by calling default methods
• deserialization must be treated as any constructor: validate the object state at the end of deserializing - this implies that readObject should almost always be implemented in Serializable classes, such that this validation is performed.
• deserialization must be treated as any constructor: if constructors make defensive copies for mutable object fields, so must readObject
• when serializing a Collection, store the number of objects in the Collection as well, and use this number to read them back in upon deserialization; avoid tricks using null

Other points:

• use javadoc's @serial tag to denote Serializable fields
• the .ser extension is conventionally used for files representing serialized objects
• no static or transient fields undergo default serialization
• extendable classes should not be Serializable, unless necessary
• inner classes should rarely, if ever, implement Serializable
• container classes should usually follow the style of Hashtable, which implements Serializable by storing keys and values, as opposed to a large hash table data structure

Read full article from Java Practices -> Implementing Serializable