Some comments of RMI

  1.About Stub:
  java.rmi.server.RemoteStub is a class that implements the Serializable interface. The RMI serialization mechanism knows that whenever a remote server is "sent" over the wire, the server object should be replaced by a stub that knows how to communicate with the server (e.g.,a stub that knows on which machine and port the server is listening).Calling Naming.rebind( ) actually winds up passing a stub to the RMI registry.
  When clients make calls to Naming.lookup( ), as in the following code snippet, they also receive copies of the stub. Since the stub is serializable, there's no problem in making a copy of it.

  2. About serialVersionUID:
  serialVersionUID: serialization detects Class Change.
  serialVersionUID doesn't have to be private. However, it must be static, final, and long. 
  Setting serialVersionUID is a simple, and often surprisingly noticeable, performance improvement. If you don't set serialVersionUID, the serialization mechanism has to compute it. This involves going through all the fields and methods and computing a hash. If you set serialVersionUID, on the other hand, the serialization mechanism simply looks up a single value.
 
  An important point is that you can decide whether to implement Externalizable or Serializable on a class-by-class basis. Within the same application, some of your classes can be Serializable, and some can be Externalizable. This makes it easy to evolve your application in response to actual performance data and shifting requirements. The following two-part strategy is often quite nice: 
·  Make all your classes implement Serializable. 
·  After that, make some of them, the ones you send often and for which serialization is dramatically inefficient, implement Externalizable instead. 
This gets you most of the convenience of serialization and lets you use Externalizable to optimize when appropriate. 
  Experience has shown that, over time, more and more objects will gradually come to directly extend Object and implement Externalizable. But that's fine. It simply means that the code was incrementally improved in response to performance problems when the application was deployed. 

  Note: Serialization mechanism is deep copy, so, the class will be serialized should be as 'thin' as possible.