Re: rmi vs cajo

[Andrew Haley]

Stuart Ballard writes:
 > I've seen various blog posts and things that give the general advice
 > that calling a virtual method from a constructor is pretty much always
 > a bad idea. "Considered harmful", that kind of thing.
 > 
 > That's difficult advice to follow in Java since almost everything's
 > virtual and there's no definite cue as to whether it's *intended* to
 > be overridden or not, but at the very least it's safe to say that
 > hashCode is intended to be overridden, since that's the whole point of
 > its existence.
 > 
 > Even ignoring the fact that this seems to be required for Sun
 > compatibility (which is sufficient by itself to make the decision), I
 > think we ought to change this code.

I've been trying to figure out what the problem in this case really
is.  It seems to me that the real issue here is that the constructor
for UnicastRemoteObject has the side-effect of exporting the object,
and it exports it *before* it is fully constructed.  This cannot be
right, no matter how much it may be be required for Sun compatibility.

The idea of using an IdentityHashMap is pretty sound.  But it also
might be a very good idea to make HashCode() robust.

Andrew.