Why doesn't java.lang.Object implement the Serializable Interface? [duplicate]

Question

Possible Duplicate:
Why Java needs Serializable interface?

According to Serializability in Java docs :

Serializability of a class is enabled by the class implementing the java.io.Serializable interface. Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. The serialization interface has no methods or fields and serves only to identify the semantics of being serializable

Why doesn't the Object already implement Serializable? Members that we wouldn't want to be serializable may be made as transient. Why prevent the default Serializability?

Soda

This question contains few nice answers that could interest you. – Tarantella

Indeed. I should have tried alternative keywords before posting :) – Soda

Answer 1

Potential security hole

All subtypes of a serializable class are themselves serializable.

In other words: all classes you ever create, were or will be created are all serializable. transient only excludes fields, not whole classes.

This is a potential security hole - by coincidence you can serialize e.g. your DataSource with database credentials inside - if the creator of this particular DataSource implementation forgot to make such fields transient. It's surprisingly easy to serialize random Java object, e.g. through inner classes holding implicit reference to outer this.

It's just safer to use white-list of classes which you explicitly want and allow to serialize as opposed to carefully examining your code, making sure no fields you do not desire are ever serialized.

Moreover you can no longer say: MySuperSecretClass is not serializable (by simply not implementing Serializable) - you can only exclude the guts (fields).

Transvalue

OKay, I think I completely missed out the security aspect of it. Makes sense. But don't we use Private/Public/Protected for compile time access? Couldn't transient or something similar been made a mandate for run time? Just asking. Or would it have been just cumbersome. – Soda

@TJ-: IMHO just a small fraction of classes need to be serializable (value objects, DTOs). Marking classes that need to be serializable is much more convenient that marking those that do not neet that. Not that Java isn't cumbersome in that matters: again IMHO all fields should be private and all methods public by default, but what can you do? – Transvalue

Answer 2

1. Serializable is marker interface, which is empty, but when a class is marked Serializable that means its objects are Serializable.

2. The reason the java.lang.Object didnt implement Serializable is because, what if you do NOT want to make certain fields as Serializable and you my mistake missed to add transient to that field, then will be a havoc.

3. By making the programmer implement Serializable for his class, it makes an awareness among the programmer that he has consciously implemented it, and should take necessary step to prevent anything to be serialized which should not be.

Toinette

Answer 3

Most classes don't need to be serializable. With the current design you can easily notice that the class is serializable. Essentially it's just a compiler-checked self-documentation. Otherwise you would probably write something like:

/** DON'T SERIALIZE IT!!! */
class Connection { ... }

and it's better to have language or library feature than comments.

Cheesewood

Answer 4

I think it makes more sense to implement Serializable for objects which needs to be persisted and declaring every fields of the class transiennt will be more cumbersome. Another point for which I am not sure is that Object is the root of all classes, which includes reflection related classes, so it'll be inappropriate to implement Serializable for the Object class.

Sherysherye