• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Object Serialization!

 
Ranch Hand
Posts: 232
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi folks,
why do we need object serialization? i am trying to practice on creating socket and trying to send an employee object containing name and address. why do i need to make an employee class serializable?
please explain me in laymans term.
thanks.
 
Greenhorn
Posts: 11
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
To be able to send an object to any type of stream the object must be serialized. Serializing an object pretty much packs it up so that it can be used again elsewhere. One example would be you can save a serialized object that contains settings to a file when your program exits and next time you run your program you could load the object and have the same settings over again.
 
Cowgirl and Author
Posts: 1589
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Howdy --
Java's an OO language, so it's a more natural fit to SEND whole objects (over a network, for example), and to SAVE whole objects when you need persistence. I used to write games, and before Serialization (which didn't appear until Java 1.1), saving the state of a game and its characters was AWFUL -- you had to have your classes implement a 'Saveable" interface (just made that up), and then implement the saveYourself() method in each class. That saveYourself() method had to look at the state of all the important variables and then write them out to the file and then -- OH GOD you had to be absolutely certain you knew what you were doing when you tried to 'restore' the objects later using that data. You had to keep track of exactly in which order you wrote the variables out to, and obviously all classes were different, and... I get the chills just thinking about how many Bad Things Happened.
So that's the Saving part of Serialization, which is cool all by itself. But then there's the Shipping part of Serialization, where you pass a whole object over the wire instead of the object's individual values which you use to later build a similar object on the other side. Serialization is really great for this purpose because it allows RMI, and RMI lets you call a method on an object running in some other JVM (probably on some other physical machine on the network) almost as simply as calling a method on an object in the same JVM heap.
Serialization comes in to play in several ways, but most importantly in passing arguments and return values. Without Serialization, you couldn't have the ease of RMI (where all the sockets/streams/protocol issues are handled for you behind the scenes!) because you'd have to split apart the object's data, agree on a protocol, send it over the wire in a stream, and then figure out how to parse and use the info on the other side.
With RMI, the client just calls a method... getBalance(aCustomer) passing in a local reference to an object, just like you always do with a method call, and the object on the other side (the remote object with the getBalance(Customer aCustomer) method) just treats the aCustomer parameter like any other object reference. As far as the remote object getting the call is concerned, it's just a plain old local object. But in reality, whatever object was originally referenced on the client by aCustomer was actually serialized, shipped over, deserialized, and then the new reference was passed to the remote object with the method.
Serialization is just fantastic!! Every OO language needs a way to 'flatten' or 'persist' objects, and Serialization is Java's way. Saving, passing, writing objects through Serialization is the more OO way to save, pass, and write the data that makes up an object's state. It's just better OO. (in many cases, anyway).
cheers,
Kathy Sierra
reply
    Bookmark Topic Watch Topic
  • New Topic