framework for encoding objects as byte streams and reconstructing objects from their byte-stream encodings
Encoding an object as a byte stream is known as serializing the object; the reverse process is known as deserializing it
Implement Serializable judiciously
A major cost of implementing Serializable is that it decreases the flexibility
to change a class’s implementation once it has been released.
- Once you distribute a class widely, you are generally
required to support the serialized form forever
- default serialized form ==> the class’s private and package-private instance fields
become part of its exported API
- Maintaining the original serialized form - using ObjectOutputStream.putFields and ObjectInputStream.readFields
- The automatically generated value(serialVersionUID) is affected by the class’s name, the names of the
interfaces it implements, and all of its public and protected members.
A second cost of implementing Serializable is that it increases the likelihood of bugs and security holes.
- serialization is an extralinguistic mechanism for creating objects
- deserialization is a "hidden constructor"
A third cost of implementing Serializable is that it increases the testing burden
associated with releasing a new version of a class.
Implementing the Serializable interface is not a decision to be undertaken lightly.
Classes designed for inheritance should rarely implement Serializable,
and interfaces should rarely extend it.
Must consider providing a parameterless constructor on nonserializable classes designed for inheritance.
Don't accept the default serialized form without first considering whether it is appropriate.
Even if you decide that the default serialized form is appropriate,
you often must provide a readObject method to ensure invariants and security.