felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Karl Pauls <karlpa...@gmail.com>
Subject Re: possible framework bug in hashCode() function
Date Fri, 06 Mar 2009 13:40:52 GMT
On Fri, Mar 6, 2009 at 1:59 PM,  <Alexander.Berger@finnova.ch> wrote:
> 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.

you can search JIRA as well as we use that for bug tracking. FELIX-892
is your problem for example :-)

regards,

Karl

> 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
>
>



-- 
Karl Pauls
karlpauls@gmail.com

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


Mime
View raw message