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. _______________________________________________ Classpath mailing list [email protected] http://lists.gnu.org/mailman/listinfo/classpath
