[GitHub] [lucene-solr] gerlowskija commented on a change in pull request #1728: SOLR-14596: equals/hashCode for common SolrRequest classes

[GitBox <gi...@apache.org>]

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:
users@infra.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@lucene.apache.org
For additional commands, e-mail: issues-help@lucene.apache.org