murblanc commented on a change in pull request #1579:
URL: https://github.com/apache/lucene-solr/pull/1579#discussion_r445346816
##########
File path: solr/core/src/java/org/apache/solr/pkg/PackageAPI.java
##########
@@ -211,7 +211,7 @@ public boolean equals(Object obj) {
@Override
public int hashCode() {
- throw new UnsupportedOperationException("TODO unimplemented");
+ return Objects.hash(version, manifestSHA512);
Review comment:
I believe that when `hashCode()` is called (when using a collection) it
is followed by a call to `equals()` if there's an element in that slot. More
efficient (better spreading) `hashCode()` would save calls to `equals()`.
Therefore, I'm not sure saving on execution time on `hashCode()` makes sense,
as we will have to pay it in the cost of computing more `equals()`.
It might pay in cases where the collections will contain very few elements,
in which case `hashCode()` is not really important, but in these cases its
performance is likely not an issue either.
The approach I would take here is do the right thing in implementing
`hashCode()`, then if we have performance issues with some objects, understand
what those are and solve them (_insert Donald Knuth quote here_).
Therefore I would base `hashCode()` on version and files like `equals()`.
----------------------------------------------------------------
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
