Am 29.07.2017 um 13:20 schrieb sebb:
On 23 July 2017 at 15:45, Felix Schumacher
<[email protected]> wrote:
Hi all,
I wonder if the implementation for 'equals', 'hashCode' and possibly
'toString' of UnmodifiableJMeterVariables are correct.
I think - for symmetry and since they are not the same classes - the methods
'hashCode' and 'equals' should include a test for the class.
Currently with:
JMeterVariables vars = somehowGetThem();
UnmodifiableJMeterVariables unmodifiable = new
UnmodifiableJMeterVariables(vars);
we have
unmodifiable.equals(vars) == true
vars.equals(unmodifiable) != true
That is clearly broken; equals() must be reflexive.
and
unmodifiable.hashCode() == vars.hashCode()
That does not matter.
I think we should have
unmodifiable.equals(vars) != true
vars.equals(unmodifiable) != true
OK
and
unmodifiable.hashCode() != vars.hashCode()
Not necessary.
objects that are the same to equals() must have the same hashCode, but
the equal hashCodes don't have to compare as equal().
What do you think?
See above.
Hashcode and equals() are tricky to do correctly, especially with subclasses.
I have implemented the changes with r1802732.
The hashCode of UnmodifiableJMeterVariables and its included
JMeterVariables will be different, but as you said, it will not matter.
Thanks for your feedback,
Felix
Felix