felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stuart McCulloch <mccu...@gmail.com>
Subject Re: possible framework bug in hashCode() function
Date Fri, 06 Mar 2009 11:54:45 GMT
2009/3/6 Reto Bachmann-Gmür <reto.bachmann@trialox.org>

> Alexander.Berger@finnova.ch said the following on 03/06/2009 12:04 PM:
> > [...] As to my understanding hashCode() should never throw an exception
> and always return the same integer value for the same object instance. If
> this contract is violated classes like HashMap will not work correctly,
> possibly introducing memory leaks if the Map (Set or whatever) entries are
> not removed due to changing hash codes or thrown exceptions.
> >
> Just as a side note: while it what you describe is probably the best
> practice it is not mandated by the java-spec. In fact java the classes
> from the collection framework would violate this contract: the hashcode
> changes when the collection changes and hashcode() throws an exception
> when the collection is self-containing.

correct, from the actual hashCode() javadoc:

   "Whenever it is invoked on the same object more than once during an
execution of a Java application,
    the hashCode method must consistently return the same integer, provided
no information used in equals
    comparisons on the object is modified. This integer need not remain
consistent from one execution of
    an application to another execution of the same application."

the gotcha part is:

   "... provided no information used in equals comparisons on the object is
modified ..."

which is why you should be careful what objects you use as hashmap keys...

> Regards,
> Reto
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org

Cheers, Stuart

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message