[
https://issues.apache.org/jira/browse/LUCENE-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15290616#comment-15290616
]
Dawid Weiss commented on LUCENE-7277:
-------------------------------------
Paul, which git commit is this patch against? Because, oddly, it doesn't apply
for me now (master) and the commit sha's inside the patch I can't find in my
local checkout... odd.
In any case, my notes from manual review:
- one of the reasons I don't like getClass().hashCode() is that it changes with
every execution and runtime (classes delegate up to object identity which is
ephemeral). While I'm a big fan of randomized testing, I'd like to keep things
predictable and with a changing hashCode the layout of hashmaps (iteration
order, collisions) will be different every time -- something that may or may
not drive you crazy when debugging... For this reason I'd opt to integrate
something constant (a hashcode of the name of the class?) rather than the
hashcode of the class object itself.
- I'd throw an AssertionError (explicitly via new AssertionError) rather than
UnsupportedOperationException in places where we think these methods should
never be called (because of rewriting or other reasons).
I can make these changes, but let me know what revision this patch was made
against (so that I can apply it first and then rebase against master).
> 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]
