[
https://issues.apache.org/jira/browse/LUCENE-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290641#comment-15290641
]
Paul Elschot commented on LUCENE-7277:
--------------------------------------
The patch is against commit 4bc3477fbf9be688c14bbb07f5982d5f4b615591 on master
of yesterday.
It was made with git diff -w master from a local lucene7277 branch, which has
commits roughly for each lucene module.
I don't know which sha's git puts in a patch.
I would not mind rebasing the local branch to update the patch, but I'll have
very little time the coming days.
In case replacing getClass().hashCode() by something like
getClass().getName().hashCode() is preferred for easier testing, it would
probably be better to add that in a companion method to sameClassAs(), for
example classHash().
> 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: [email protected]
For additional commands, e-mail: [email protected]
