river-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John McClain (JIRA)" <j...@apache.org>
Subject [jira] Updated: (RIVER-127) Issues with EntryRep.equals() and hashCode() methods, and hash field
Date Fri, 27 Jul 2007 23:31:53 GMT

     [ https://issues.apache.org/jira/browse/RIVER-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

John McClain updated RIVER-127:

    Component/s: com_sun_jini_outrigger

> Issues with EntryRep.equals() and hashCode() methods, and hash field
> --------------------------------------------------------------------
>                 Key: RIVER-127
>                 URL: https://issues.apache.org/jira/browse/RIVER-127
>             Project: River
>          Issue Type: Bug
>          Components: com_sun_jini_outrigger
>    Affects Versions: jtsk_1.1
>            Reporter: John McClain
>            Priority: Minor
> Bugtraq ID [4947179|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4947179]
> First, {{hashCode()}} and {{equals()}} are not in sync, and {{equals}} is
> technically wrong. {{hashCode()}} returns the {{hashCode}} of the {{className}}.
> {{equals}} compares the elements of the values arrays and the hash fields,
> but class info hash does not include the {{className}} and thus two entry reps
> could have different values returned by there {{hashCode}} methods, but have {{equals()}}
> return {{true}} (if they had the same field structure and super class structure with
different names). We could also have two {{EntryRep}}s where {{equals()}} would return true
but they would be of different classes. Seems unlikely that either would happen in practice.
> Second, {{shareWith()}} overwrites the value of the hash field. When
> the hash field was a Long this was the right thing to do, now
> that it is a long it server little purpose, and will tend to
> obscure class hash related bug that might occur in other places
> (e.g. if there was a bug in {{OutriggerServerImpl.checkClass()}}).
> There is also an interesting question if we actually use {{EntryRep.equals()}}
> and {{hashCode()}} anymore. May just want to allow them to default.
> Comments :
> Depending how this bug is fixed it could break database compatibility.
> Seems like the sort of thing where we where one would expect content equality, even if
we don't use it now, keeping with a notion of content equality seems like the best option.
> There are other ways to fix this, but my guess is really want the
> class name in the class info hash. This will fix the first part of the
> bug and making the class info hash "better". The only problem with
> this approach is we can only do when we are not worried about breaking
> store (and wire protocol?) capability.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message