@EqualsAndHashCode changed behaviour when calling super

[embuc]

Previous version: 1.16.12
New version 1.18.4

After upgrade to newer (1.18.4) version, generated hashCode() method changed (and thus broke our test suite).
This is the generated hashCode in the previous (1.16.12) version:
public int hashCode() { int PRIME = 59; int result = 1; result = result * 59 + super.hashCode(); return result; }

and this is the hashCode (in the same class) after upgrade:
public int hashCode() { int result = super.hashCode();return result; }

This newer code generates another value of hashCode for the same object (missing 'result * 59 + ' part). Consistent hashCode across versions is an imperative for our application.

Is there a config flag for this perhaps? Or is it a bug?

[Maaartinus]

Disclaimer: Just a lombok fan here.

This change is fixing #1505 (according to my proposal). The original behavior was buggy as it returned different hashCode for equal objects, so I don't think, a configuration makes sense.

You might be able get the part back using a dummy field with value one placed first in the class. A method like @EqualsAndHashCode.Include private int dummy() {return 1;} might do, too (the position of the method matters). I'm not sure.

Replacing callSuper=true by a method returning super.hashCode() should probably work. Anyway, as a sure workaround, you can copy the generated code from delombok. It's ugly, I know.

[embuc]

Yes, I can see that the original implementation was a bit flawed - it shouldn't have included 'result * 59' blindly like that. We'll adapt to the correct version of generated code and try to handle the legacy with as little (bad) impact as possible.

[rzwitserloot]

Good catch by @Maaartinus - thanks!