title: Do class changes like field addition or removal maintain Serializable's backward compatibility?
body: <p>I have a question about Java serialization in scenarios where you may need to modify your serializable class and maintain backward compatibility.</p>
  
  <p>I come from deep C# experience, so please allow me to compare Java with .NET.</p>
  
  <p>In my Java scenario, I need to serialize an object with Java's runtime serialization mechanism, and store the binary data in permanent storage to reuse the objects in future. <em>The problem is</em> that, in the future, classes may be subject to changes. Fields may be added or removed.</p>
  
  <p>I don't know Java serialization in the deep, except for this fantastic article about how <a href="http://thedailywtf.com/Articles/Serializalicious.aspx" rel="noreferrer">not to program in Java</a> when dealing with serialization.
  As I imagine(d), the serialVersionUID plays a key role in Java serialization, and this is where I need your help.</p>
  
  <p>Apart from the article's example (I know it's bad coding), shall that field not be modified when Eclipse asks to update it after I modified the class?</p>
  
  <p>I remember from the .NET world that when I add new fields I must add the <code>[OptionalField]</code>Attribute to the field to get the backward compatibility, so CLR won't require it in old serialized data. Also, when I need to deprecate a field I must only remove the public methods and not the private fields.</p>
  
  <p>What are the guidelines for best serialization?</p>
  
  <p>Thank you.</p>
  
  <p>[Add] Here is an example. Suppose I have class Foo</p>
  
  <pre><code>public class Foo {
      private String bar;
  }
  </code></pre>
  
  <p>Then I change to:</p>
  
  <pre><code>public class Foo {
      private String bar;
      private Integer eggs;
  }
  </code></pre>
  
  <p>Is compatibility broken between these two version? If I deserialize an "oldFoo" when I have the "newFoo" compiled, does eggs equals null or is an exception thrown? I prefer the first, obviously!!</p>