[
https://issues.apache.org/jira/browse/TINKERPOP-3170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18012423#comment-18012423
]
Cole Greer commented on TINKERPOP-3170:
---------------------------------------
I came across a particularly egregious example of this issue in RangeLocalStep
such that
{code:java}
__.limit(Scope.local, 10L).equals(__.skip(Scope.local, 10L))
// True
{code}
RangeGlobalStep is one of the few steps which currently overrides equals(),
presumably in response to this exact issue.
https://github.com/apache/tinkerpop/blob/077e3eb22c463545c3fc974944d4bf1d5d6a32fd/gremlin-core/src/main/java/org/apache/tinkerpop/gremlin/process/traversal/step/filter/RangeGlobalStep.java#L128-L135
> Majority of steps violate hashcode/equals contracts
> ---------------------------------------------------
>
> Key: TINKERPOP-3170
> URL: https://issues.apache.org/jira/browse/TINKERPOP-3170
> Project: TinkerPop
> Issue Type: Bug
> Affects Versions: 3.7.3
> Reporter: Andrea C
> Priority: Major
>
> AbstractStep.java is the parent class for all steps which has the following
> `equals` method implementation which relies on the hashCode value to
> determine equality:
> {code:java}
> @Override
> public boolean equals(final Object other) {
> return other != null && other.getClass().equals(this.getClass()) &&
> this.hashCode() == other.hashCode();
> } {code}
> This is a violation of the hashCode and equals contracts because unequal
> objects may have the same hashCode. This reliance on hashCode comparison for
> equality can lead to unexpected behaviour and bugs which are difficult to
> troubleshoot. Almost all steps use this logic as I can only see 2 which
> override the equals method from the abstract parent.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)