[
https://issues.apache.org/jira/browse/LUCENE-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15292149#comment-15292149
]
Paul Elschot commented on LUCENE-7277:
--------------------------------------
I rebased locally to a more recent master. This went without conflicts, so I
wonder why the patch did not apply cleanly.
I then added one more commit with more use of sameClassAs in the lucene test
code, so now ant compile-test passes for lucene.
In this last commit I used AssertionError in few places.
I did not change getClass().hashCode() into getClass().getName().hashCode().
Then I pushed the local branch to github, with an added date in the branch name
in order to avoid confusion with other rebases (just treat it as a tag):
https://github.com/PaulElschot/lucene-solr/tree/lucene7277-20160519
In case this git branch is not usable, please holler, I'd gladly post another
patch here.
> 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-20160518.patch, 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-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
