Databases
StackOverflow2013
Postsdbo
PODo class changes like field addition or removal maintain Serializable's backward compatibility?
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PODo class changes like field addition or removal maintain Serializable's backward compatibility?
    primarykey
    data
    text
    <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="nofollow 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>
    singulars
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PTQuestion
    1. USCiro Santilli 新疆改造中心 六四事件 法轮功
    1. USusr-local-ΕΨΗΕΛΩΝ
    plurals
    1. PL
      singulars
      1. LTLinked
    2. PL
      singulars
      1. LTLinked
    3. PL
      singulars
      1. LTLinked
    1. PL
      singulars
      1. LTLinked
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    3. PO
      singulars
      1. PTAnswer
    1. VO
      singulars
      1. PODo class changes like field addition or removal maintain Serializable's backward compatibility?
      1. This table or related slice is empty.
      1. VTUpMod
    2. VO
      singulars
      1. PODo class changes like field addition or removal maintain Serializable's backward compatibility?
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PODo class changes like field addition or removal maintain Serializable's backward compatibility?
      1. This table or related slice is empty.
      1. VTUpMod
    1. COCheck out following links : - [Is java object serialization compatible between 1.5 and 1.6](http://stackoverflow.com/questions/152757/is-java-object-serialization-compatible-between-1-5-and-1-6) - [.NET to Java serialization/deserialization compatibility](http://stackoverflow.com/questions/1303792/net-to-java-serialization-deserialization-compatibility) - [Java Serialization 1.4 vs 1.6](http://stackoverflow.com/questions/318707/java-serialization-1-4-vs-1-6) - [Serialization FAQ](http://www.jguru.com/faq/core-java-technology/serialization)
      singulars
      1. PODo class changes like field addition or removal maintain Serializable's backward compatibility?
      1. USJavascript is GOD
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload