avro-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Philip Zeyliger (JIRA)" <j...@apache.org>
Subject [jira] Commented: (AVRO-182) hashCode and equals are not consistent with compareTo
Date Tue, 10 Nov 2009 21:23:27 GMT

    [ https://issues.apache.org/jira/browse/AVRO-182?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12776083#action_12776083
] 

Philip Zeyliger commented on AVRO-182:
--------------------------------------

> equals()

I think you should include the instanceof check.  I read the contract for equals (http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#equals%28java.lang.Object%29)
as indicating that equals() should never throw on valid objects.  I agree that in practice
this hardly ever crops up, but as a Java user, I would be very confused by the error.

> public int incrementHash(int hashCode, Object o, Schema s) {

I like this.  I'm nowhere near expert enough in hash functions to say whether there should
be xors or shifts, but it seems fine as is.

> GenericData, GenericArray, etc.

Thanks for the explanation.  I think what I meant to say was that GenericData.Array (itself
an implementation of GenericArray) calls back into GenericData.  I see now that if you want
people to use different GenericArrays, you have to do it this way.  I hadn't noticed that
GenericDatumReader is designed to be subclassed to have different newArray() implementations.
 So all is clear(er) now, thanks.

-- Philip

> hashCode and equals are not consistent with compareTo
> -----------------------------------------------------
>
>                 Key: AVRO-182
>                 URL: https://issues.apache.org/jira/browse/AVRO-182
>             Project: Avro
>          Issue Type: Bug
>          Components: java
>            Reporter: Doug Cutting
>            Assignee: Doug Cutting
>             Fix For: 1.3.0
>
>         Attachments: AVRO-182.patch
>
>
> Java's specific and generic APIs implement compareTo according to the schema, where some
fields might be ignored.  To be consistent, fields that are ignored when comparing for ordering
should also be ignored when comparing for equality and for computing hashCodes.

-- 
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