What's the rationale behind "Serializable" interface?

Question

If we want to serialize an object, we can simply do the following implementation:

class MyClass implements Serializable
{
  private static final long serialVersionUID = 12345L;
}

And no extra effort is needed to imperatively implement how the object will be written into and read from files. Java simply takes care of everything.

On the other hand, Externalizable does define explicit serialization and deserialization methods so we can program imperatively.

This leaves me the question: if no extra effort is needed for Serializable, what's the rationale to make it an interface that we have to implement to serialize/deserialize objects, instead of making it by default that every object can be serialized/deserialized?

Answer 1

Because:

1. Not all objects have meaningful semantics for this. Example: singleton object
2. Security. If you pass objects to someone else's code and they could always capture and transmit the object then there would need to be an opt out for security related code and there would be security bugs when people overlooked an object. So "off by default" is more secure.
3. The built in serialisation format writes out the classname for every object you write so it is very inefficient. Only use it for very simple cases with little data.
4. The default serialisation does not share data easily with code written in other languages so using a specific representation should be considered if data written today may need to be read by other software in the future. So it's not a good long term format.
5. The exact rules of how it works in all cases are not well remembered by all developers.

If you read the book Effective Java by Joshua Bloch it explains how tricky using the built in feature can be. Most developers avoid it for a lot of cases. This answer gives a good rule of thumb https://softwareengineering.stackexchange.com/a/240432/129659