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 ofUnmarshalExceptionwith 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 ...