Although it an advertised feature, you cannot write an RMI remote object
implementation class that does not extends UnicastRemoteObject but has
implementations of the hashcode() and equals() methods that make instances
"equal" to remote stub objects for those instances.

The problem is that the hashcode() method for the object must return the same
value as the hashcode() method for the instance's stub object, but this stub
object is only available on return from the exportObject() method. Prior to
receiving the correct stub object, the hashcode() method for the remote class
will be invoked during the object exporting process when the server is placed
in the runtime's object table. Not having access to the stub at this point,
the hashcode() method will not be able to return the correct value. But if,
in the future, it does return the stub's hash code, the remote object will
probably no longer be successfully looked up in the runtime's object table,
because it was likely inserted into the wrong hash bucket to begin with. Thus,
if the object is sent as a parameter or return value of an RMI call, its stub
object will not be found to replace it with.

Regressed with jdk1.1.6e and it is fixed.