You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Paul Elschot (JIRA)" <ji...@apache.org> on 2016/05/17 19:54:13 UTC

[jira] [Comment Edited] (LUCENE-7277) Make Query.hashCode and Query.equals abstract

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

Paul Elschot edited comment on LUCENE-7277 at 5/17/16 7:53 PM:
---------------------------------------------------------------

An intermediate class with attributes uses these attributes in its equals()/hashCode(), and a leaf class without attributes currently still has its class used by the default implementation that is called via super.

The same can be done with sameClassAs() from the patch for equals(), combined with a getClass() in an intermediate hashCode() implementation. I think I'll give that a try.


was (Author: paul.elschot@xs4all.nl):
An intermediate class with attributes uses these attributes in their equals()/hashCode(), and a leaf class without attributes currently still has its class used by the default implementation that is called via super.

The same can be done with sameClassAs() from the patch for equals(), combined with a getClass() in an intermediate hashCode() implementation. I think I'll give that a try.

> Make Query.hashCode and Query.equals abstract
> ---------------------------------------------
>
>                 Key: LUCENE-7277
>                 URL: https://issues.apache.org/jira/browse/LUCENE-7277
>             Project: Lucene - Core
>          Issue Type: Improvement
>            Reporter: Dawid Weiss
>            Assignee: Dawid Weiss
>            Priority: Trivial
>         Attachments: LUCENE-7277.patch
>
>
> Custom subclasses of the Query class have the default implementation of hashCode/equals that make all instances of the subclass equal. If somebody doesn't know this it can be pretty tricky to debug with IndexSearcher's query cache on. 
> Is there any rationale for declaring it this way instead of making those methods abstract (and enforcing their proper implementation in a subclass)?
> {code}
>   public int hashCode() {
>     return getClass().hashCode();
>   }
>   public boolean equals(Object obj) {
>     if (obj == null)
>       return false;
>     return getClass() == obj.getClass();
>   }
> {code}



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