[
https://issues.apache.org/jira/browse/LANG-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18054151#comment-18054151
]
Ivan Ponomarev commented on LANG-1813:
--------------------------------------
If we treat this as a bug, then it’s a bug (or a design choice) in
{{{}HashCodeBuilder{}}}, because {{ArrayUtils.hashCode(..)}} delegates to it.
It’s true that JDK utilities such as {{java.util.Objects.hashCode(Object)}}
(and {{{}Objects.hash(Object...){}}}) return {{0}} for {{{}null{}}}, and
{{Arrays.hashCode(..)}} also returns {{0}} for {{null}} inputs. That said, I’m
not sure there is much practical value in relying on “hash == 0 means null”:
users can always check for {{null}} directly, and a non-null object may
legitimately have a hash code of {{0}} anyway.
Given that the current {{HashCodeBuilder}} behavior has been in place for ~23
years without reports, I suspect changing the runtime behavior now may be more
risky than beneficial. If you decideto harmonize behavior with
{{{}java.util.*{}}}, that’s of course a valid direction — but it could be a
change with potential compatibility impact.
My proposed minimal/safe fix for this ticket is documentation-only: replace
{{@param array the array to get a hash code for, \{@code null} returns zero}}
with
{{@param array the array to get a hash code for, may be \{@code null}}}
This removes the incorrect promise while still documenting that {{null}} is
accepted, in order not to mislead the coding agents, which, unlike humans, do
read the documentation carefully.
> `ArrayUtils#hashCode` Javadoc incorrectly states “null returns zero” (actual
> result is 629)
> -------------------------------------------------------------------------------------------
>
> Key: LANG-1813
> URL: https://issues.apache.org/jira/browse/LANG-1813
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.*
> Reporter: Ivan Ponomarev
> Priority: Trivial
>
> Since commit 8c6294dd70f986088262a6b75a382cbc9e980543 (dated Jul 19, 2003),
> the Javadoc for {{org.apache.commons.lang3.ArrayUtils#hashCode(...)}} states
> that a {{null}} array input “returns zero”.
> However, this has never been true in practice: the method delegates to
> {{{}new HashCodeBuilder().append(array).toHashCode(){}}}, and
> {{HashCodeBuilder}} returns *629* for {{null}} input (with its default
> initial value and multiplier). This creates a long-standing discrepancy
> between documented and actual behavior.
> Given the age of the issue and the possibility that some legacy code may rely
> on the current behavior, changing the implementation to return 0 for {{null}}
> could be a breaking change. The safest resolution appears to be updating the
> Javadoc to match actual behavior (i.e., remove the “null returns zero”
> promise).
> Reproducer: the following test fails
> {code:java}
> @Test
> void testNullArrayHashCode() {
> // According to javadoc: "null returns zero"
> assertEquals(0, ArrayUtils.hashCode(null));
> }{code}
>
> Fix: https://github.com/apache/commons-lang/pull/1580
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
