• 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

Serializable and Externalizable !!

 
Ranch Hand
Posts: 244
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hello friends ,
Can anyone site me when shoud Externalizable should be used when we already have the Serializable interface ??
or
What are the points of difference between both ?
i hope i get good feedback from all the JGURUS out here !!
Thanks ,
SAurabh
 
Ranch Hand
Posts: 704
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
You will find an good article on this subject here
Regards
Nigel
 
Ranch Hand
Posts: 1873
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Okay...beyond that article I would point out what I have prepared...
I would use short forms,
S for Serialization
E for Externalization
1.
DIFF:
-----
In S, when you deserialize the object is constructed without the help of any constructurs in the object,
- In E, you need to have "public" no arg constructor in the object to deserialize
EFFECT:
-------
Effect of the above is-
a) When we use E, we make our object "public" for sure which could be an issue for us sometime. e.g. We want to pass the object to other machine but not allow them create a new object via the constructor but we can't get around it anyhow if we use E.
b) When we use E, we have this flexibilty of initializing some variables automatically to their default values upon deserilization as no-arg constructor is called. This is not possible to achieve easily (it could be possible by putting hacks or something) via S. This functionality could be useful in some cases where we didn't serialize all the data via E but still upon deserialization we want that data to be having default values...

2.
DIFF:
-----
- In S the parent object's serialization automatically happens if the Parent is also serializable.
- In E no matter what parent is, E or S. The child must take care of serializing required attributes and deserializing them via writeExternal, readExternal
EFFECT:
-------
This could be hurdle for us in somecase. May be this is a remote possibility but we can't predict that it would not happen..
3.
DIFF:
------
- In addition to the article's point that we have more constrol in E,
as S is automatically done by JVM it could result in slower performance and bigger serialized state than E.
Please refer to JDC Techtips for more information on this...
EFFECT:
-------
Only if we have significant objects to write that affects our performance due to this reason...

Also, I strongly recomment "Thinking In Java , 3rd Edition" book for reading about all these fundamentals. Its amazing book and you can be sure of the higher level as I am too choosy about books. I read 10 and buy 1.
Just my 2 cents!
Regards
Maulin
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
reply
    Bookmark Topic Watch Topic
  • New Topic