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] Created: (RIVER-127) Issues with EntryRep.equals() and hashCode() methods, and hash field
Date Fri, 27 Jul 2007 19:13:53 GMT
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
    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.


Mime
View raw message