What exactly does @EqualsAndHashCode(callSuper=true) generate

[Kevin Wong]

I have entities that subclass a common base entity (containing the id
field, equals/hashCode, etc.). I want to use @Data, but don't want it
to generate the equals method, as the superclass' implementation
applies. I thought that adding @EqualsAndHashCode(callSuper=true)
might delegate to the super impl of equals, but that doesn't seem to
work.

[Reinier Zwitserloot]

callSuper=true will simply include the results of super.hashCode() and
super.equals(other) in its calculations. If you want to use ONLY the
superclass implementations and ignore any fields including in this
class, then roll your own methods, like so:

@Data public class Whatever {
private int foo;

@Override public int hashCode() { return super.hashCode(); }
@Override public boolean equals(Object other) { return super.equals
(other); }
}


There's a general lombok rule: If lombok wants to generate something
you already wrote, it will simply not generate it, presuming that you
know better.

[Kevin Wong]

Thanks. Yes, I know about the override way to handle this. I was
trying to avoid it, as it means I'll have to put those override
methods in all my entities (boilerplate). Worse, if I forget I won't
know it until I get some unexpected behavior.

Maybe an @Accessors (or @GettersSetters) annotation would be nice, so
I could gen the getters/setters w/o the equals/hashCode stuff.

Great lib, BTW.

[v6ak]

On Sep 24, 6:33 pm, Reinier Zwitserloot <reini...@gmail.com> wrote:
> There's a general lombok rule: If lombok wants to generate something
> you already wrote, it will simply not generate it, presuming that you
> know better.

What about @OverrideLombok to be sure that Lombok tried to generate it?

[Reinier Zwitserloot]

I don't think that's worth the added complexity of the annotation, and
explaining to new users what it does, etc, etc.

[v6ak]

OK. However, if somebody don't know what is it, (s)he would ignore it,
I think.

There is one important advantage: When I tried overriding generated
methods, I was not sure whether is it correct. If I knew about
@OverrideLombok, I would be sure.

[Reinier Zwitserloot]

The next release will probably have a 'delombok' tool which you can
run on the command line, and prints the code that lombok would
generate. If at any time you're unsure, you could use that to see what
lombok is doing with your code. Should fulfill the job of
@LombokOverride, and more (such as letting you make proper javadoc :P)

[Vít Šesták]

I agree that delombok is useful. However, I don't think that it is
very useful to understand Lombok, because:
1. You can currently use another ways, e.g. some java decompilers.
2. If something works now, it can be a bug. I was not sure about this
feature. I thought that further implementation can break code that
uses this behavior.
Note that @OverrideLombok (+warnings when this annotation is missing)
can avoid annoying troubles when some generated code is unexpectedly
overriden by a written or generated code. Unexpected collisions with
another annotations can be very annoying.
I don't think that overriding generated methods is common for newbies.
I also think that simple warning ("If you want to avoid generating
this method by Lombok, you should use @OverrideLombok.") solves all
important troubles about @OverrideLombok.