On Fri, Mar 6, 2009 at 1:59 PM, <alexander.ber...@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.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 > > -- Karl Pauls karlpa...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@felix.apache.org For additional commands, e-mail: users-h...@felix.apache.org
