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