Mailing-List: contact avro-dev-help@hadoop.apache.org; run by ezmlm
Precedence: bulk
Reply-To: avro-dev@hadoop.apache.org
Message-ID: <600284236.1257888207894.JavaMail.jira@brutus>
Date: Tue, 10 Nov 2009 21:23:27 +0000 (UTC)
From: "Philip Zeyliger (JIRA)" <jira@apache.org>
To: avro-dev@hadoop.apache.org
Subject: [jira] Commented: (AVRO-182) hashCode and equals are not consistent
 with compareTo
In-Reply-To: <1085960523.1257452912368.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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