While working on a small class called FractionNumber I found asking myself if I should implement an interface that I am already implementing. Sounds stupid, I know, but bear with me.

My class FractionNumber extends Number; Number implements Serializable. And I am unsure if FractionNumber should explicitly implement Serializable as well.

Of course it does not really matter because Serializable only defines final methods and FractionNumber inherits the Serializable 'implementation' of Number. But I kind of like making my FractionNumber explicitly Serializable.

Now to my question: Is this simply useless or does the verbosity help in some way? Does it make sense, in a philosophically sense, to declare FractionNumber being something it already is?

  • 1
    You might just remind that in a JavaDoc comment. Or add a line comment before the class fields to warn yourself before you try to modify them. Though, if you have a serialVersionUID, it probably gives enough reminder.
    – SOFe
    Commented Jul 28, 2016 at 8:31
  • I'm not after reminding me or other people that this class is searializable (all the fields are primitive so there is no danger there). I only want the class to be clearly serializable - also only because I think any class meant to store information should be serializable. But maybe you're right with your last point, the serialVersionUID field indicates that already.
    – kalsowerus
    Commented Jul 28, 2016 at 8:50

2 Answers 2


From a code point of view

Contracts set by the parent type should be implied for the sub type.

If you feel the need to express serialization abilities in every type that can be serialized (maybe you feel you need to explicitly remind yourself/co-developers that something can be serialized) you should refactor your code to strengthen the implication.

From a JavaDoc point of view

All interfaces implemented by the type, including inherited interfaces, are displayed in the header under "All implemented interfaces". The only difference is the actual declaration displayed in the JavaDoc:

If directly implementing interface:

public class Sub extends Super implements Serialization

If inherited:

public class Sub extends Super

To me, this is clutter (duplication), and I recommend against it.


In general, you probably should not be redeclaring that you implement interfaces in this way but Serializable is not a normal interface. You say that "Serializable only defines final methods" but that's not the case (I double-checked). Serializable declares no methods at all. It's a marker interface which is widely considered to be an anti-pattern and I am in full agreement with that assessment.

The fact that your class must be serializable because a super-class (or interface) implements Serializable is an artifact one of the most prominent design flaws in Java. Serializable is specifed using an interface but transient is a keyword. Why serializable isn't a keyword too is a bit of a head scratcher. If java serialization was designed now, it likely would be done with annotations.

Because of all this wackiness, if you are going to implement Serializable, I would go ahead and redeclare it to show that you actually intend it to work with java serialization and that it's not Serializable because simply because a base class was declared that way. Personally, I wouldn't use java serialization, though. There are many better ways to create wireformat and I think the idea of 'object transmission' is inherently flawed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.