[jira] [Commented] (LUCENE-6744) equals methods should compare classes directly, not use instanceof

["Scott Stults (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/LUCENE-6744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14947564#comment-14947564 ] 

Scott Stults commented on LUCENE-6744:
--------------------------------------

Java 7 is the documented minimum language level for Solr, so I think it's okay to use the  Objects class for its static equals(Object a, Object b) method. (While we're at it we might even consider using its hash(Object...) function.)

That would make ConstValueSource.equals look something like this:
{code}
  @Override
  public boolean equals(Object o) {
    if (this == o) return true;
    if (o == null || getClass() != o.getClass()) return false;
    ConstValueSource that = (ConstValueSource) o;
    return Objects.equals(constant, that.constant) &&
        Objects.equals(dv, that.dv);
  }
{code}

Moreover, if we want to jump into Objects usage with both feet we can change hashCode to this:
{code}
  @Override
  public int hashCode() {
    return Objects.hash(constant, dv);
  }
{code}

> equals methods should compare classes directly, not use instanceof
> ------------------------------------------------------------------
>
>                 Key: LUCENE-6744
>                 URL: https://issues.apache.org/jira/browse/LUCENE-6744
>             Project: Lucene - Core
>          Issue Type: Bug
>            Reporter: Hoss Man
>              Labels: newdev
>
> from a 2015-07-12 email to the dev list from Fuxiang Chen...
> {noformat}
> We have found some inconsistencies in the overriding of the equals() method
> in some files with respect to the conforming to the contract structure
> based on the Java Specification.
> Affected files:
> 1) ConstValueSource.java
> 2) DoubleConstValueSource.java
> 3) FixedBitSet.java
> 4) GeohashFunction.java
> 5) LongBitSet.java
> 6) SpanNearQuery.java
> 7) StringDistanceFunction.java
> 8) ValueSourceRangeFilter.java
> 9) VectorDistanceFunction.java
> The above files all uses instanceof in the overridden equals() method in
> comparing two objects.
> According to the Java Specification, the equals() method must be reflexive,
> symmetric, transitive and consistent. In the case of symmetric, it is
> stated that x.equals(y) should return true if and only if y.equals(x)
> returns true. Using instanceof is asymmetric and is not a valid symmetric
> contract.
> A more preferred way will be to compare the classes instead. i.e. if
> (this.getClass() != o.getClass()).
> However, if compiling the source code using JDK 7 and above, and if
> developers still prefer to use instanceof, you can make use of the static
> methods of Objects such as Objects.equals(this.id, that.id). (Making use of
> the static methods of Objects is currently absent in the methods.) It will
> be easier to override the equals() method and will ensure that the
> overridden equals() method will fulfill the contract rules.
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org