The specifications for the interfaces java.rmi.server.RMIClientSocketFactory and java.rmi.server.RMIServerSocketFactory should make more clear the ramifications of the behavior of the Object.hashCode and Object.equals methods for classes that implement those interfaces.

Judging by posts to the RMI-USERS mailing lists, an extremely common pitfall encountered by developers first trying to use RMI's support for per-object custom socket factories (i.e. implementations of the RMIClientSocketFactory and RMIServerSocketFactory interfaces) is to neglect to make sure that functionally equivalent instances of their socket factory classes appear equivalent according to their Object.hashCode and Object.equals methods.

Doing so is important for several reasons, including:

- allowing sharing of server-side listening sockets across exports with equivalent but non-identical RMIServerSocketFactory instances (and same port number)-- otherwise, multiple non-anonymous port exports in this situation will simply fail, and anonymous port exports will not share a port: this, in turn, affects the client-side scalability possibilities of batching DGC messages and processing to different remote objects in the same VM

- allowing sharing of client-side connections across invocations on remote stubs with equivalent but non-identical RMIClientSocketFactory instances, a very likely occurrence given that each newly deserialized RMIClientSocketFactory will become a different instance (without special deserialization care in the class)

- again, allowing client-side batching of DGC messages and processing to even the same remote object, or different remote objects exported on the same host and port, for remote stubs with equivalent but non-identical RMIClientSocketFactory instances, which is again an important scalability factor

- correctly evaluating remote stub equality

The most typical approach to avoid this pitfall is to have the socket factory classes override Object.hashCode and Object.equals so that they make functionally equivalent instances (i.e. same class, and presumably same data, if any) appear equal (and, of course, have the same hash code).

An alternate approach is to implement an instance canonicalization scheme for the socket factory classes to guarantee that there will only ever be one accessible instance of a given socket factory class with a given value, thus enabling the default Object.hashCode/Object.equals behavior (i.e. identity comparison) to be sufficient.  Any such approach would require use of a class defined "readResolve" method in (at least) the RMIClientSocketFactory implementation (or whatever object represents the serialized data for the class), to resolve all equivalent deserialized values to the same instance.

In summary, therefore, because handling these details correctly is so important for healthy use of custom socket factories with RMI, the ramifications should be spelled out more explicitly in the specifications of the socket factory interfaces, instead of assuming implicit understanding.