```
public interface Serializable
```
Marks classes that can be serialized by ObjectOutputStream and deserialized by ObjectInputStream.
Warning: this interface limits how its implementing classes can change in the future. By implementing Serializable you expose your flexible in-memory implementation details as a rigid binary representation. Simple code changes--like renaming private fields--are not safe when the changed class is serializable.
The Serialized Form
By default, the serialization mechanism encodes an object's class name, the names of its non-transient fields (including non-public fields), and the values of all of those fields. The output is an opaque sequence of bytes. Those bytes can be decoded into a new, equivalent instance as long as the decoder has compatible versions of the originating classes.
Changing the class name, field names or field types breaks serialization compatibility and complicates interoperability between old and new versions of the serializable class. Adding or removing fields also complicates serialization between versions of a class because it requires your code to cope with missing fields.
Every serializable class is assigned a version identifier called a serialVersionUID. By default, this identifier is computed by hashing the class declaration and its members. This identifier is included in the serialized form so that version conflicts can be detected during deserialization. If the local serialVersionUID differs from the serialVersionUID in the serialized data, deserialization will fail with an InvalidClassException.
You can avoid this failure by declaring an explicit serialVersionUID. Declaring an explicit serialVersionUID tells the serialization mechanism that the class is forward and backward compatible with all versions that share that serialVersionUID. Declaring a serialVersionUID looks like this:
```
   

     private static final long serialVersionUID = 0L;
 
```
If you declare a serialVersionUID, you should increment it each time your class changes incompatibly with the previous version. Typically this is when you add, change or remove a non-transient field.
You can take control of your serialized form by implementing these two methods with these exact signatures in your serializable classes:
```
   

   private void writeObject(java.io.ObjectOutputStream out)
       throws IOException {
     // write 'this' to 'out'...
   }

   private void readObject(java.io.ObjectInputStream in)
       throws IOException, ClassNotFoundException {
     // populate the fields of 'this' from the data in 'in'...
   }
 
```
It is impossible to maintain serialization compatibility across a class name change. For this reason, implementing Serializable in anonymous inner classes is highly discouraged: simply reordering the members in the file could change the generated class name and break serialization compatibility.
You can exclude member fields from serialization by giving them the transient modifier. Upon deserialization, the transient field's value will be null, 0, or false according to its type.
Implement Serializable Judiciously
Refer to Effective Java's chapter on serialization for thorough coverage of the serialization API. The book explains how to use this interface without harming your application's maintainability.

Interface Serializable

The Serialized Form

Implement Serializable Judiciously