12

Because the Java language required all interface members to be public and the original designers didn't want to force the "methods" of java.io.Serializable to be public, this was not possible in Java.

Scala doesn't have this restriction, but things like readObject/writeObject are still not specified in the scala.Serializable trait.

Wouldn't this help developers because

  • they had a guarantee that their signature is correct
  • it would make accessing these methods less akward.

or do I miss something important?

soc
  • 27,983
  • 20
  • 111
  • 215
  • What do you mean by the first sentence? You can have empty interfaces in Java. [`Serializable` is empty](http://download.oracle.com/javase/6/docs/api/java/io/Serializable.html). – Matt Ball Jun 11 '11 at 21:15
  • @Matt Ball but you can't have private methods in interfaces. But good question (and I have a feeling I know where the source for this question comes from ;-) ), hope we'll get some interesting answers – Voo Jun 11 '11 at 21:18
  • @Matt The reason why `java.io.Serializable` is empty is because they didn't want to force these methods to be public. I'll clarify. – soc Jun 11 '11 at 21:19
  • @Voo...Where does this question come from? :-) – Swaranga Sarma Jun 11 '11 at 21:22
  • @Swarange: http://stackoverflow.com/questions/6317941/has-the-design-of-marker-interfaces-like-javas-serializable-or-cloneable-evolved, http://stackoverflow.com/questions/6317896/how-could-an-idiomatic-design-of-serializable-cloneable-look-like-in-scala and http://stackoverflow.com/questions/6256608/which-functionality-feature-in-scala-only-exists-as-a-concession-to-the-underlyin probably – soc Jun 11 '11 at 21:24

3 Answers3

5

Answering from a Java background but I would guess the same reasoning applies to Scala: Java does not require methods marked Serializable to implement any methods; the runtime provides the serialization mechanism itself. That's why the interface is empty. readObject and writeObject are not part of Serializable not because they aren't public but because objects derived from Serializable don't need to implement them.

Serializable really shouldn't be an interface but an annotation (especially because a class derived from a Serializable class may very well not be Serializable itself), but it was part of the language before the language had annotations.

antlersoft
  • 14,636
  • 4
  • 35
  • 55
5

or do I miss something important?

Yes, you do.

readObject/writeObject methods have to be private and NOT overridden for the mechanism to work properly.

They are called in reverse way (i.e. superclass->class) too. Morealso you do wish that the method remains private to prevent misuse (and explicit calls)

Serializable mechanism offers other methods as well: like writeReplace+readResolve, that are usually not used in the same class + readObjectNoData (that's not so useful).

Now if you need specific method take a look at java.io.Externalizable. It does publish its methods and implementing it overrides the default serialization mechanism.

bestsss
  • 11,796
  • 3
  • 53
  • 63
-1

There are no methods to make public in serialization. There are four methods you may implement but they are all optional. Your question doesn't make sense.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • @downvoter OK Which is it? (1) There *are* methods to make public in Serialization? If so please name them. One will do. (2) There aren't four methods you can implement that are all optional? If so please state how many there are, if any, and name them. (3) The question *does* makes sense, given the issues at (1) and (2)? Please. – user207421 Jan 05 '17 at 09:42