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



Reply via email to