[
https://issues.apache.org/jira/browse/SOLR-14596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17179184#comment-17179184
]
Jason Gerlowski commented on SOLR-14596:
----------------------------------------
bq. You didn't say "all" but I think your reasoning ultimately leads to "all"
I disagree that's where the reasoning leads. The Object javadocs require
hashCode impls only where {{equals}} is also overridden. ("equal objects have
equal hashcodes" is trivially met when the definition of {{equals}} is
reference-equality based). A blanket claim about needing hashCode for all
classes everywhere would def be objectionable, but that's not what Object.java
calls for.
bq. It's easy for code evolution (new fields) to leave equals/hashCode out of
date, leading to very subtle bugs!
I understand the out-of-date scenario you're describing here, but I'm not sure
what type of subtle bugs you're referring to. Not including a field in an
{{equals}} check could cause some weird bugs in a client's logic, but you're
not objecting to implementing {{equals}}, afaict, just {{hashCode}}. If we
zoom in to {{hashCode}} specifically - if hC doesn't include a new field in its
impl - well, nothing severe happens. Equal objects will still have equal
hashcodes. Unequal objects may or may not have equal hashcodes. Both of those
are "correct".
So even if these impl's fall out of date, there's no risk afaict. Maybe the
specifics or these bugs are a point to zoom in on, since it's important to the
argument you've made so far around the debt/risk to having these around, and
also where we're seemingly furthest from a shared understanding. Can you
clarify the class of "subtle bugs" you're referring to?
In terms of the UOE approach, I think it's very user-unfriendly. We're talking
about taking an operation that works ootb on the vast majority of Java classes
and intentionally breaking it for users of our classes. Further, we're doing
this as a break to back-compat (if in 8x) and without any real sense of how
common/uncommon it is. I feel like that might make this proposed change a
net-negative for users, even taking into account the improved assert-ability
that {{equals}} gives.
> Add equals()/hashCode() impls to SolrJ Request objects
> ------------------------------------------------------
>
> Key: SOLR-14596
> URL: https://issues.apache.org/jira/browse/SOLR-14596
> Project: Solr
> Issue Type: Improvement
> Components: SolrJ
> Affects Versions: master (9.0), 8.5.2
> Reporter: Jason Gerlowski
> Priority: Minor
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently, many SolrRequest classes (e.g. UpdateRequest) don't implement
> {{equals()}} or {{hashCode()}}
> This isn't a problem for Solr's normal operation, but it can be a barrier in
> unit testing SolrJ client code. {{equals()}} implementations would make it
> much easier to assert that client code is building the request that
> developers _think_ it's building. Of course, this testing benefit would
> apply to Solr's own tests which use SolrJ.
> This ticket covers making sure that the more popular SolrRequest objects have
> equals/hashcode implementations useful for testers.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
