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.bachm...@trialox.org>
> alexander.ber...@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-unsubscr...@felix.apache.org
> For additional commands, e-mail: users-h...@felix.apache.org
>
>
--
Cheers, Stuart
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
