3

I was reading Effective Java, and I came across passages that talk about ways you might implement a serializable singleton, as if this was a perfectly normal thing to do in Java. This immediately baffled me, because my intuition says that:

  • Being serializable necessarily implies value semantics.
  • Being a singleton necessarily implies reference semantics.
  • Value and identity semantics are mutually exclusive.

The Effective Java author even appears to share at least some of this intuition, if I'm reading this later passage correctly:

As a rule of thumb, value classes such as Date and BigInteger should implement Serializable, as should most collection classes. Classes representing active entities, such as thread pools, should rarely implement Serializable.

When I searched the book, this site and some blog posts, I found a lot of examples where readResolve() is little more than return INSTANCE;. Maybe I'm just really bad at Java, but a class like that looks to me as if it's saying "when deserializing an object of this class, ignore the serialized data completely and return the existing instance" which would imply the object is not actually serializable in any meaningful way. And yet there's this SO answer which seems to say "the only use for readResolve() is to make serializable singletons", so...that's about where I gave up and started writing this question.

Are there any huge misunderstandings in what I've said so far? If not, what would be a legitimate use case for a serializable singleton class, and what would its semantics be?

  • 1
    If not, what would be a legitimate use case for a serializable singleton class? - since there is no legitimate use cases for plain old singletons... – Telastyn Jun 20 '15 at 14:14
  • @Telastyn I lean pretty strongly toward agreeing with that myself, which is part of the reason this puzzled me. Singletons only seem to make sense to me for something like a GraphicsContext, Keyboard or FileSystem where most apps really can't ever have more than one and definitely should not be trying to serialize such things. – Ixrec Jun 20 '15 at 14:28
  • Serialization can hydrate the values of an object that is referenced with a Singleton. – Robert Harvey Jun 20 '15 at 15:26
  • What you call "value classes" are "immutable classes" in other languages. – gnasher729 Dec 10 '16 at 16:21
1

If you're doing logging, it would often be convenient to log the state of any singletons, as they represent global state that might be required to reproduce a crash. If your singleton can be logged by serializing a complete representation of itself, this is ideal as you might also be able to deserialize that state and rerun your program with the singleton in the same state.

tl;dr, reproducibility.

Edit: I didn't really want to get too far into the relationship of Value and Reference semantics, because I'm not a Java guy and it sounds like the books you're saying understand these things in a more specific way that probably makes complete sense in Java, so I don't know that I should contradict them or you.

However, I'll give two cents on this. Value and reference semantics (to me) generally relate to what happens when you copy something: do you copy the values (and have a genuine, new, fresh object), or do you copy a reference (so you have a new reference to the same thing). However, the whole point of Singletons is that they're not copyable at all. So in my mind, I wouldn't really think of a Singleton as having either semantics.

Now, in C++, this is a bit clearer: generally in C++ when you have a singleton, you can't get the "actual" singleton object, only a reference to it. And the reference of course has reference semantics, which says nothing about the semantics of the singleton, which is ok, because you can't get access to the actual singleton. In Java though, this is a lot blurrier because you generally manipulate all objects by reference. So it looks like a singleton is just behaving like any other by-reference object.

  • When you copy a reference, you don't actually copy an object. You can have only one singleton, but you can have any number of identical references to that singleton. – gnasher729 Dec 10 '16 at 16:19
0

"Being serializable necessarily implies value semantics" - not at all. After an object with reference semantics is serialized, it absolutely makes sense to either create another object matching the serialized representation, or mutate a mutable object with reference semantics to match the serialized representation.

I usually take the point of view that a singleton has no persistent state, but often gives access to some kind of persistent state. The persistent state might be on a server, possibly accessed by other instances of the application, or it might be stored locally. If it is stored locally, it might be considered part of the singleton and might be stored through serialising.

In that case, at the one point where the singleton would be created, it could be created by either de-serializing a previously serialized singleton, or by creating it from scratch if it was never serialized before.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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