[
https://issues.apache.org/jira/browse/LUCENE-7277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283975#comment-15283975
]
Paul Elschot commented on LUCENE-7277:
--------------------------------------
bq. I fail see how an equivalence relationship over all objects of a class
could be useful for caching reason
The idea is to make super.equals() determine equality as far as the (object of
the) superclass is concerned, and when it returns true to test the local class
attributes.
bq. it's misleading ... assuming defaults ... inherited from Object
So at least javadocs are needed to indicate that the current implementation
only determines class equivalence.
bq. redeclare an overridden method as an abstract one
Thanks for that.
So there are some solutions here:
- javadocs only (not preferred),
- javadocs + redeclaration of overridden method as abstract
- abstract methods only
I'm fine with the latter two.
Redeclaration is probably a smaller change because it would keep the common
code in the superclass.
> 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
>
> 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
