java.io.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.
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.
streaming API
and a
tree API
to read and write JSON. Use a binding library
like
GSON
to read and
write Java objects directly.