The Serializable interface is what's called a tagging interface. If a class MyClass implements a tagging interface like Serializable, then other code can say, in effect,
That's the whole reason for its existence; the JVM decides whether serializing a class is legal or not based on whether it implements this interface. [ May 31, 2004: Message edited by: Ernest Friedman-Hill ]
The Serializable interface demands adherance to a specific contract. When a class implements the interface, it is done so with the understanding that the class understands and adheres to the contract, thus it is called a "tagging interface" - meaning "This class is tagged as understanding what it means to be Serializable".
A good real world example is hiring a lawyer. You (the class) understand that you are engaging in a contract by hiring a lawyer (the interface). That contract involves giving the lawyer money (the Serializable contract) but the lawyer doesn't have to actually do anything for that money (the Serializable interface contains no methods), and at the end of the day, nothing will have been achieved by you (the class), as long as you adhere to contract - the lawyer gets paid.
Originally posted by Tony Morris: A good real world example is hiring a lawyer. You (the class) understand that you are engaging in a contract by hiring a lawyer (the interface). That contract involves giving the lawyer money (the Serializable contract) but the lawyer doesn't have to actually do anything for that money (the Serializable interface contains no methods), and at the end of the day, nothing will have been achieved by you (the class), as long as you adhere to contract - the lawyer gets paid.
well, that clears things up... :roll:
I've heard it takes forever to grow a woman from the ground
I suspect it's actually a pretty good analogy, if you've ever had to hire a lawyer. But I can see where it may not be clear to everyone. Alternately:
Java provides a pretty good implementation of serialization, by default. Basically it just goes through all the fields of a class (and its superclasses) and writes them to a stream. OK, cool, this is all you need for many classes. It's a pretty good default. However, it's not always appropriate. And example is the Connection class. You can write the parameters of a connection to a file somewhere, fine. However if you deserialize it - you read the host name and use name and password and whatver else is necessary, and create a Connection using those parameters - have you really recreated the original Connection? Well, no, at least not as far as the DB is concerned. You've merely created a new Connection with the same parameters as the original. If, for example, you close() the original Connection, this would have no effect on the new one. So serialization isn't really appropitate here, at leat not in the sense of reconstituting the original object. We don't want people to think they've rebuilt the original object here - that would be too confusting. There are other classes it may not be appropriate to serialize. Java chose to make the default serialization process an opt-in mechanism - that is, Java will only serialize a class if the class declaration specifies that the default serialization mechanism is appropriate. (Or they can specify an alternate mechanism via Externalizable, but that's another post.) The way to opt in is simple - just specify that the class implements Serializable. That's it. The JVM can test this easily enough - the default implementation of writeObject() can be thought of as:
In other words, the only role of a marker interface like Serializable is as a sort of binary flag. Either the JVM should use the default serialization process, or it shouldn't. It's up to the class author to decide whether (obj instanceof Serializable) should return true - if so, you'd better implement Serializable.