Hi Duncan,
Does it make sense to create a method specifically for array types,
which calls reflectonHashCode on each element to compute a final hash code?
This would solve the poster's problem and avoid polluting
reflectionHashCode with the behavior.
Regards,
Mike
On Sep 26, 2014 6:32 AM, "Duncan Jones" <djo...@apache.org> wrote:
> Hi folks,
> I'd welcome someone else's viewpoint on LANG-1039. The question is: what
> should HashCodeBuilder.reflectionHashCode() do when given an array object
> as input.
>
> My argument is that the intended use of this method is for overriding
> Object.hashCode() and so it should never be the case than an array object
> is passed to this method. (It will always be "this").
>
> The complaint from the poster is that arrays return the result 17. This is
> because arrays have no fields, so our reflection logic doesn't find
> anything to add to the cumulative hash code.
>
> I'm in favour of saying this isn't a problem, but it might be worth adding
> something extra to the Javadocs to make it clearer how this method is
> intended to be used and how it works. Something like "If object has no
> fields, the result will be a constant value (default = 17)" or similar.
>
> However, we could extend the method to recognise array types and return a
> hashcode for the array.
>
> I welcome thoughts on the matter.
>
> Kind regards,
>
> Duncan
>
