Why is java.io.Serializable not a class?

Question

I understand this question can sound quite weird, but I wonder why the java.io.Serializable interface has been implemented precisely as an interface, and not as a class?

What made me think about that point, is that we're talking about overriding the readObject/writeObject methods, while by definition, we don't override them (i.e. there's no super type of our Serializable objects that already implement these methods).

Thus, if Serializable would have been a class, it could have implemented the default readObject/writeObject methods, and the exenting classes could then have been able to really override the said methods.

Here is a not working workaround that illustrates my words:

public class Serializable implements java.io.Serializable {

    private static final long serialVersionUID = 356223041512972356L;

    protected void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
        stream.defaultReadObject();
    }

    protected void writeObject(ObjectOutputStream stream) throws IOException {
        stream.defaultWriteObject();
    }

}

public class MyClass extends Serializable {

    private static final long serialVersionUID = -5437634103734137046L;

    @Override
    protected void readObject(ObjectInputStream stream) throws IOException, ClassNotFoundException {
        super.readObject(stream);
        // custom readObject method
    }

}

PS: the provided workaround doesn't work since the readObject/writeObject methods have to be declared as private while mine are protected.

possible duplicate of [Why are readObject and writeObject private, and why would I write transient variables explicitly?](http://stackoverflow.com/questions/7467313/why-are-readobject-and-writeobject-private-and-why-would-i-write-transient-vari) resp one of the answers: http://stackoverflow.com/a/7472723 — Puce, Mar 05 '13 at 16:04
The methods could have been put into `Object`, just as for `clone` and `Cloneable`. But see all the reasons why `Cloneable` is a bad idea for why `Serializable` shouldn't be a class. — Tom Hawtin - tackline, Mar 05 '13 at 18:15
It's the same reason why any interface isn't a class. So as not to constrain what you can inherit from. — user207421, Mar 05 '13 at 23:02

score 12 · Accepted Answer · answered Mar 05 '13 at 15:51

12

Because then you're really screwed if you want to inherit from another class and implement Serializable. This is the general trade-off Java made when choosing not to support true multiple inheritance.

You'll note that Java 2.0 languages (Groovy and Scala) reversed that decision via what they call traits or mixins - which are pretty much exactly designed so you can just "mix in" e.g. the Serializable functionality without logically just deriving from it - which you might take as evidence that you are making a very good point and Java would have done well to heed your opinion.

answered Mar 05 '13 at 15:51

djechlin

59,258
35
162
290

Ahem, yes, of course, this is quite obvious... I don't know why I didn't think about it before posting the question. Many thanks though! – sp00m Mar 05 '13 at 15:54
It follows that since it's an interface, you could add the method signatures for read/WriteObject to it, but then that would require an implementation which is not actually necessary. – eipark Apr 01 '13 at 20:07

score 4 · Answer 2 · answered Mar 05 '13 at 15:52

4

If java.io.Serializable would've been a class, you would've been unable to inherit from another base class.

To put it another way, it's either inheritance or serialization.

answered Mar 05 '13 at 15:52

Robert Munteanu

67,031
36
206
278

Why is java.io.Serializable not a class?

2 Answers2