Originally posted by Dale DeMott:
What exactly does Serialiable do for you? I've seen it used but not sure of its uses. What are the advantages and disadvantages of it.
-D
Oh wow! Serialization is, in my very humble cowgirl opinion, THE coolest thing in all of Java. It was the biggest treat when it came out with 1.1 (not available in 1.02, which very much depressed me).
Serialization in Java is known in general OO terms as "object flattening" or "object persistence". I came from a game development background, and in order to "Save Game", we had to write what we called 'spill your guts' methods into each class. Those methods would be called and each object would faithfully write out it's own instance variable state. YUCK!
Well, even if *that* isn't so bad, imagine what happens if you accidentally get your own protocol wrong (and since without Serialization you'd be on your own for a protocol) and then you try to *restore* (essentially de-serialize) the state of the objects. You have to know the order in which you wrote out each and every instance variable, so that you can bring everything back to life. It was very, very ugly.
With serialization in Java, it takes a couple lines of code and you've written not just a single object -- but the entire object *graph* for that object. In other words, the instance variables in the object... and if those instance variables are object references -- then it means the objects at the other end of those references have to be written. And, well, that means the instance variables of *those* objects have to be written. Objects all the way down.
It is like magic, how clean and easy. Best of all, if something goes wrong, you will NOT be able to restore an object *partially*. It either restores (deserializes) correctly or it throws an exception. So you don't end up with objects that look like they've come from a bad Star Trek transporter accident.
Best, best of all: Without Serialization, how easy would it be to do RMI? Jini? For that matter,
EJB? Serialization is the way in which distributed objects (in other words, two objects running on different virtual machines -- usually different *physical* machines as well) pass arguments and return values. And since it is a common protocol, you don't even have to do the serialization yourself when you use RMI, Jini, EJB, etc.
Serialization lets objects -- real live objects -- move over the network. So you're not just passing data, you're passing real honest-to-goodness objects. They get flattened, shipped, and reanimated on the other side, almost transparently.
DISADVANTAGES:
*The class must be marked serializable, and the instance variables you want to save must be marked serializable. (Although it's usually fairly trivial to serialize an object even if it DOES have a non-serializable instance variable).
*That object graph could be HUGE. May not be a problem if you're using serialization for persistence, in other words, to save an object to disk or an object database. But if you're using serialization to ship objects over the network, then you DO care, and you might have to get involved. Fortunately, there are mechanisms in serialization that let you easily step into the middle of the flattening/unflattening (i.e. serialize/deserialize) process to tweak it for your needs.
*Not a speed demon, although virtually all business apps are far more likly to be slowed down by bandwidth issues anyway, as opposed to being slowed down by the overhead of serialization and deserialization.
* The class MUST be present and accessible to the VM trying to deserialize the object. No problem for anything in the core library, otherwise you have to get the class to the "client". But... since technologies like Jini would never work if you had to KNOW who all your potential clients were, there is a fabulous mechanism in RMI called dynamic class downloading that lets you do the following:
*ship an object over the network via RMI, say, an object that you're sending as the return value of a remote method call.
* now imagine the calling client code (the code that invoked the remote method) is written to use an interface type, so that it doesn't specify which actual class your object is instantiated from.
* No problem until the client VM tries to deserialize the object so that you can get a full, live, breathing object as that return value. At *this* point, the client had better have the class. But wait! The serialized object is shipped with a little label that says, "Hello. Here is where my class lives... you'll find it by doing an http 'get' on this URL here." So even if the class is NOT on the client, it will then be AUTOMATICALLY fetched, loaded, and the deserialization can continue un-noticed to the client. It takes VERY little effort to set up dynamic code downloading, and it allows the ultimate in flexibility and maintability, extensibility -- all those good 'ilities'.
Whoops, before I go any further in evangelism land, I just realized that we're in the Threads forum. This belongs on the Distributed forum (Michael Ernest's forum, guru of all things distributed).
Maybe someone who knows how will move this
But you just had to get me going...