EJB interface Backward compatibility

When working on core piece of enterprise application, we face lot of challenges in terms of versions. We cannot force all the client applications to upgrade to new release at the same time.

1. interface needs to be well defined
2. when planning for next release, need to take care of backward compatibility, this can be easily achieved by serial version id. This can be defined with any random Long number (there is no rule to define at first time).
But what happens, if we missed to specify serial version id at the first release? How to handle this? use "serialver" command with the old class and find out SUID and then define that in the next release.

For example:
serialver test.test.testa.TestA
test.test.testa.TestA: static final long serialVersionUID = -8902737804282067121L;



What are all the changes acceptable as backward compatible?

Compatible Changes:

• Addition of new fields or classes does not affect serialization, as any new data in the stream is simply ignored by older versions. When the instance of an older version of the class is deserialized, the newly added field will be set to its default value.
• You can field change access modifiers like private, public, protected or package as they are not reflected to the serial stream.
• You can change a transient or static field to a non-transient or non-static field, as it is similar to adding a field.
• You can change the access modifiers for constructors and methods of the class. For instance a previously private method can now be made public, an instance method can be changed to static, etc. The only exception is that you cannot change the default signatures for readObject() and writeObject() if you are implementing custom serialization. The serialization process looks at only instance data, and not the methods of a class.

Incompatible changes:

• Once a class implements the Serializable interface, you cannot later make it implement the Externalizable interface, since this will result in the creation of an incompatible stream.
• Deleting fields can cause a problem. Now, when the object is serialized, an earlier version of the class would set the old field to its default value since nothing was available within the stream. Consequently, this default data may lead the newly created object to assume an invalid state.
• Changing a non-static into static or non-transient into transient is not permitted as it is equivalent to deleting fields.
• You also cannot change the field types within a class, as this would cause a failure when attempting to read in the original field into the new field.
• You cannot alter the position of the class in the class hierarchy. Since the fully-qualified class name is written as part of the bytestream, this change will result in the creation of an incompatible stream.
• You cannot change the name of the class or the package it belongs to, as that information is written to the stream during serialization.

This is just extract from vast subject. To understand more refer below links

• Serailization discussion
• Externalizable