gerlowskija commented on a change in pull request #1728:
URL: https://github.com/apache/lucene-solr/pull/1728#discussion_r471012967
##########
File path: solr/solrj/src/java/org/apache/solr/client/solrj/ResponseParser.java
##########
@@ -49,4 +52,31 @@ public String getVersion()
{
return "2.2";
}
+
+ @Override
+ public int hashCode() {
+ return new HashCodeBuilder()
+ .append(getWriterType())
+ .append(getContentType())
+ .append(getVersion())
+ .toHashCode();
+ }
+
+ @Override
+ public boolean equals(Object rhs) {
+ if (rhs == null || getClass() != rhs.getClass()) {
+ return false;
+ } else if (this == rhs) {
+ return true;
+ } else if (hashCode() != rhs.hashCode()) {
+ return false;
+ }
+
+ final ResponseParser rhsCast = (ResponseParser) rhs;
Review comment:
I didn't make an intentional choice against Objects.hash - I'm just more
familiar with HashCodeBuilder, so that's what I used.
Anyone have a concrete reason to prefer one vs the other? If not, I'll do a
little digging to see if one has advantages and report back.
Also relevant to this discussion is that @dsmiley made an argument in the
[jira ticket](https://issues.apache.org/jira/browse/SOLR-14596) that hashCode
impls aren't worth the maintenance burden and should be skipped here. Since
you guys showed some interest in the PR, either of you want to cast a vote
there to settle things out more conclusively? (I don't agree personally with
his argument, but am happy to go with a clear consensus.)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
