On 4/27/05, Elliot Metsger <[EMAIL PROTECTED]> wrote: > Felix Meschberger wrote: > > Hi, > > > > Just a small clarification... > > > > Stefan Guggisberg schrieb: > > > >> regarding missing hashCode(): i intentionally do never override > >> hashCode() > >> for mutable objects. hashCode() should imo only be implemented for > >> immutable objects. > >> > > Unfortunately this is not in line with the general contract of the > > hashCode and equals methods, which says - amongst other things - that > > for two objects being equal according to equals the hashCode must be the > > same. If you do not overwrite the hashCode method whenever you overwrite > > the equals method, you will get into troubles. Josh Bloch has written a > > nice text on this issue in his famous book. > > yes, you run into problems when inserting objects that override equals() > but not hashcode() into Set's for example. >
well that's exactly the problem. if your override equals() and hashCode() in a mutable class you e.g. risk losing track of data in a hashtable. that's why i intentionally did not override hashCode() in order to hint that this class should not be used in hashtables etc. on second thought i realize that i had better overriden hashCode() returning a constant integer. cheers stefan
