Externalizable vs Serializable

15/01/2012
  • 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,

  1. If you are not happy with the way java writes/reads objects from stream.
  2. Special handling for supertypes on object construction during serialization.
This Core Java tutorial was posted on 15/01/2012.
Ads by Google

38 comments on “Externalizable vs Serializable

    • thanks for providing helping material

  1. Every thing what you write is very help full.

    Thank you so much.

  2. Every thing what you write is very help full.

    Thank you so much.

  3. Thank you so much sir it is really helpful. :)

  4. You can also change default serialization behavior with Serializable interface by overriding writeObject and readObject methods.

  5. thanks again…love your posts that educate quickly, efficiently and to the point:)

  6. Hi Joe,
    I am Jagdish, i have some question in Java.
    Please give me ur email id so that i can contact
    you….

  7. 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.

  8. thank yu so muchhhh….

    i have passed my interview with CTS…

    main reason is your site and it helped me a lot, thanks..

    • So happy to know that.

      All the best for your career Preethi.

  9. Thanks so much Sir,

    Really it’s knowledge jargon it’s amazing Wow…

  10. 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

  11. 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

  12. It has very useful information for the beginners… good job..joe

  13. this site is very interesting and it is presented in the good manner….

  14. Hi Joe

    You are doing great work for Open Source Technology like Java.
    Keep up ur Good Work.

    God bless U.

    Thanks
    Atul Kumar
    it.atul@gmail.com

  15. Your article are always short and genuine answers.

    Thanks,
    Vishwanath

  16. good explanation …thanks for the article

  17. 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 :-)

      • 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..

  18. Hi Joe,

    Y singleton object will be de-serialized to a new instance even though it is singleton.

    Can u pls explains this.

  19. 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.

  20. why we have Externalizable when we can override writeObject and readObject in java

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>