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?

Good question. In Python everything is `serializable` or `pickle-able` by default. — Martin Konecny, Feb 24 '15 at 05:20
Answer can be found here: http://stackoverflow.com/questions/441196/why-java-needs-serializable-interface — Martin Konecny, Feb 24 '15 at 05:22

score 4 · Answer 1 · edited Feb 28 '15 at 11:37

4

When a programmer marks a class as Serializable he takes responsibility that if this class will change in future, programs which saved objects will be able to read them back to the updated class. Details are in Effective Java Item 74: Implement Serializable judiciously

There is another rationale. Did you ever notice that ObjectOutput.writeObject(Object obj) accepts Object, not Serializable? This is because it assumes that objects may be saved using different serialization mechanizms. Serializable means that object is supposed to be saved using Java standard serialization

edited Feb 28 '15 at 11:37

user207421

305,947
44
307
483

answered Feb 24 '15 at 05:24

Evgeniy Dorofeev

133,369
30
199
275

You mean `ObjectOutput.writeObject()` or `ObjectOutputStream.writeObject()`. – user207421 Feb 24 '15 at 06:29
I mean interface ObjectOutput, ObjectOutputStream.writeObject(Object ) accepts Serializable only – Evgeniy Dorofeev Feb 24 '15 at 06:38

score 0 · Answer 2 · answered Feb 24 '15 at 05:31

The interface Serializable only works as a mask for identification.If every class has the ability of being serialized ,then every class need to maintain the serialVersionUID in order to avoid version conflict.Also, it may cause the security problem : some one will use it as a way for creating new object,though the object is not intended to be created by client code.Using Serializable interface is not safe.See Effective Java for more information.

score 0 · Accepted Answer · edited Apr 12 '17 at 07:31

Because:

Not all objects have meaningful semantics for this. Example: singleton object
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.
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.
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.
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

What's the rationale behind "Serializable" interface?

3 Answers3