felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From <Alexander.Ber...@finnova.ch>
Subject AW: possible framework bug in hashCode() function
Date Fri, 06 Mar 2009 12:59:06 GMT
Thanks for your immediate reply (all of you)

If it is already fixed in Trunk then I am happy. So this is my fault (was looking at the source
of 1.4.1), next time I will first check the Trunk before taking your time.

P.S. Regarding the side note about the java-spec, Of course you are right. But I've just seen
too many bad memory leaks
       cause by implementations of hashCode() or equals() that did not behave as expected
by some kind of container (collection).
       So I am a little bit concerned every time I see such things, please forgive me in being
so :-)

- Alex

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

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


Mime
View raw message