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.