Externalizable vs Serializable
Last modified on August 1st, 2014 by Joe.
- Externalizable is an interface that enables you to define custom rules and your own mechanism for serialization. Serializable defines standard protocol and provides out of the box serialization capabilities.
- Externalizable extends Serializable.
- Implement writeExternal and readExternal methods of the Externalizable interface and create your own contract / protocol for serialization.
- Saving the state of the supertypes is responsibility of the implementing class.
- You might have seen in my previouse article on how to customize the default implementation of Serializable. These two methods readExternal and writeExternal (Externalizable) supersedes this customized implementation of readObject and writeObject.
- In object de-serialization (reconsturction) the public no-argument constructor is used to reconstruct the object. In case of Serializable, instead of using constructor, the object is re-consturcted using data read from ObjectInputStream.
- The above point subsequently mandates that the Externalizable object must have a public no-argument constructor. In the case of Seriablizable it is not mandatory.
- Behaviour of writeReplace and readResolve methods are same for both Serializable and Externalizable objects. writeReplace allows to nominate a replacement object to be written to the stream. readResolve method allows to designate a replacement object for the object just read from the stream.
- In most real time scenarios, you can use Serializable and write your own custom implementation for serialization by providing readObject and writeObject.
You may need Externalizable,
- If you are not happy with the way java writes/reads objects from stream.
- Special handling for supertypes on object construction during serialization.
Since
2008
nice explanation …. thank u
Every thing what you write is very help full.
Thank you so much.
Every thing what you write is very help full.
Thank you so much.
right to point explaination
Thank you so much sir it is really helpful. :)
You can also change default serialization behavior with Serializable interface by overriding writeObject and readObject methods.
Superb Post…I like the way ur present the things with graphical images.
thanks again…love your posts that educate quickly, efficiently and to the point:)
great post
Kalakure Joe…
Hi Joe,
I am Jagdish, i have some question in Java.
Please give me ur email id so that i can contact
you….
Hi
I am Hari, i found exactly what i was looking for in this post, it would be great if you can provide some example here as well. Keep up the good work you. Thanks for sharing your knowledge.
thank yu so muchhhh….
i have passed my interview with CTS…
main reason is your site and it helped me a lot, thanks..
thank you
its really helpful and knowledgeable.
Thanks so much Sir,
Really it’s knowledge jargon it’s amazing Wow…
if we use serialization to save an object on memory then we modify that class(definatly object has changed now) now we deserialize that object what will be happen, kindly answer
Hi Joe,
What a blog you have created. It is really very much useful when we are facing interviews. I have learnt a lot from your blog.
Thanks,
Amzad
Thank you, It is really helpful.
IT is good but not best.
It has very useful information for the beginners… good job..joe
this site is very interesting and it is presented in the good manner….
Short & Sweet…….. Tx
Your article are always short and genuine answers.
Thanks,
Vishwanath
good explanation …thanks for the article
thanks for providing helping material
Explanation states that during deserialization constructor runs, but it is not the case. Please update the article.
What I have written is, “..In object de-serialization (reconsturction) the public no-argument constructor is used to reconstruct the object. In case of Serializable, instead of using constructor, the object is re-consturcted using data read from ObjectInputStream…”
Looks like you have misunderstood what I have written :-)
So happy to know that.
All the best for your career Preethi.
It helps me a lot…
Thank you.
Hi Joe,
Y singleton object will be de-serialized to a new instance even though it is singleton.
Can u pls explains this.
Hello Joe,
This is really a nice blog.
When I was reading this blog, a q comes in my mind, why we have externalization when we can override our writeObject and readObject for Serialization and can have a customer implementation for write and read Object.
YOu have mentioned that in case of serialization, “the object is re-consturcted using data read from ObjectInputStream…” but
ObjectInputStream is used in de-serialization process. It’s little confusing. Please clarify a bit more that..
why we have Externalizable when we can override writeObject and readObject in java
Very useful article, thanks a lot!