title: Java Externalization vs Transient
body: <p>I was thinking about the purpose of Externalisation, given that you could simply label a property as <code>transient</code> and prevent its serialisation. However, upon further research I found out that this approach (i.e. labelling as <code>transient</code>) may not be ideal if you need to decide what's required at run-time. Theoretically, it makes sense to me. However, practically I don't see how Externalisation is more run-time friendly. I mean, you still have to decide what's required or not within the <code>writeExternal()</code> and <code>readExternal()</code> during the definition of the class. So, how is that more run-time friendly?</p>
  
  <p>The document that highlighted this is as follows,</p>
  
  <blockquote>
    <p>If everything is automatically taken care by implementing the
    Serializable interface, why would anyone like to implement the
    Externalizable interface and bother to define the two methods? Simply
    to have the complete control on the process. OKay... let's take a
    sample example to understand this. Suppose we have an object having
    hundreds of fields (non-transient) and we want only few fields to be
    stored on the persistent storage and not all. One solution would be to
    declare all other fields (except those which we want to serialize) as
    transient and the default Serialization process will automatically
    take care of that. But, what if those few fields are not fixed at
    design tiime instead they are conditionally decided at runtime. In
    such a situation, implementing Externalizable interface will probably
    be a better solution. Similarly, there may be scenarios where we
    simply don't want to maintain the state of the Superclasses (which are
    automatically maintained by the Serializable interface
    implementation).</p>
  </blockquote>