Java Enterprise Best Practices

Set Version Numbers Independently of serialVersionUID

serialVersionUID is a very coarse-grained versioning control. If one Java Virtual Machine (JVM) is using a class with a serialVersionUID that has been set to 1, and the other JVM is using a later version of the class with a serialVersionUID that has been set to 2, the call never reaches your server code because the RMI runtime in the server’s JVM will throw an instance of UnmarshalException (as demonstrated earlier).

This level of protection is often overkill. Instead of having the RMI runtime reject the call, you should have your code look at the data that was sent over the wire, realize that there is a versioning problem, and behave appropriately. The following scenario illustrates the problem:

Bob, a busy executive, has been traveling around Europe. While in Europe, he occasionally plugs his laptop into a local Internet connection and attempts to use a corporate application. However, the latest version of the server has been rolled out, and his client is out-of-date. The application fails completely because serialVersionUIDs have been updated, and the RMI runtime throws instances of UnmarshalException with every remote call. Bob has to live without the application for the remainder of his sales trip, use the web-based version of the application (which has a much poorer user interface), or install the new version of the client application himself.

Bob would really prefer that the application just worked.

This problem is easy to ...