[
https://issues.apache.org/jira/browse/ACCUMULO-1627?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13776688#comment-13776688
]
Bill Havanki commented on ACCUMULO-1627:
----------------------------------------
It's tricky to implement {{equals()}} in a subclass ({{ConditionalMutation}}
being a subclass of {{Mutation}}), especially since the former adds significant
fields. It boils down to the old {{instanceof}} vs. {{getClass()}} debate.
Currently, {{Mutation}} uses {{instanceof}}, but none of its subclasses really
address implementing {{equals()}} currently.
I'm inclined to go with {{getClass()}} for defining {{equals()}} in this
hierarchy. This will preserve the {{equals()}} contract but violate the Liskov
substitution principle (i.e., a {{ConditionalMutation}} object won't ever equal
a {{Mutation}} object with the same common fields, and vice versa, so you
couldn't use one to find the other in a set, say). I think in this case that's
OK.
However, I absolutely would love input from the experienced committers and
contributors on this decision. I could implement it either way.
> Add hashcode() and equals() to ConditionalMutation
> --------------------------------------------------
>
> Key: ACCUMULO-1627
> URL: https://issues.apache.org/jira/browse/ACCUMULO-1627
> Project: Accumulo
> Issue Type: Sub-task
> Components: client, tserver
> Reporter: Keith Turner
> Assignee: Bill Havanki
> Labels: newbie
> Fix For: 1.6.0
>
>
> ConditionalMutation should define equals() and hashcode() methods that
> consider the conditions. Its parent class defines those methods, so it
> should.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
