[freenet-dev] [freenet-cvs] r18969 -?trunk/freenet/src/freenet/clients/http/bookmark

[Florent Daignière]

* Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-05 11:22:48]:

> On Saturday 05 April 2008 04:22, Florent Daignière wrote:
> > * Matthew Toseland <toad at amphibian.dyndns.org> [2008-04-04 19:13:51]:
> > 
> > > On Friday 04 April 2008 06:27, nextgens at freenetproject.org wrote:
> > > > Author: nextgens
> > > > Date: 2008-04-04 05:27:02 +0000 (Fri, 04 Apr 2008)
> > > > New Revision: 18969
> > > > 
> > > > Modified:
> > > >    trunk/freenet/src/freenet/clients/http/bookmark/BookmarkItem.java
> > > > Log:
> > > > implement BookmarkItem.hashCode()
> > > 
> > > Again, two points:
> > > - This will change, and therefore break containing HashSet's etc, if the 
> parts 
> > > cease to be null. Are they all essential? If they are, are they final, and 
> > > can they be null?
> > 
> > We must do the same checks as for equals()... If it breaks the code somehow 
> we should fix it.
> 
> Of course, but I'm not sure we are doing this here:
> - It is *NOT* necessary for hashCode to always return different values for 
> different objects. We can ignore elements with impunity.

granted

> - equals() is true if two BookmarkItem's have the same key and different 
> editions. So your code breaks equals/hashCode consistency.

ok

> - key and name cannot in any case be null.

I'll dig up and see if I can find a reference here... but I'm almost
sure the java spec says we should assume it can be.

> 
> I've fixed the above.
> 
> Also you haven't explained the mathematical voodoo... hashtables will 
> generally depend on the first few bits, which will in this case depend on the 
> description's hash followed by the alerts hash. Wouldn't it be better to 
> simply XOR all the parts together?
> > 

In my implementation order matters with XORs it wouldn't.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://emu.freenetproject.org/pipermail/devl/attachments/20080405/ab6447ef/attachment.pgp