If either method already exists, then @EqualsAndHashCode will not generate that particular method. If they all exist, @EqualsAndHashCode generates no methods, and emits a warning instead to highlight that its doing nothing at all. The parameter list and return type are not relevant when deciding to skip generation of a method; any method named hashCode will make @EqualsAndHashCode not generate that method, for example.

By default, all fields that are non-static and non-transient are used in the equality check and hashCode generation. You can exclude more fields by specifying them in the exclude parameter. You can also explicitly specify the fields that are to be used by specifying them in the of parameter.

Normally, auto-generating hashCode and equals implementations in a subclass is a bad idea, as the superclass also defines fields, for which equality checks/hashcodes won't be auto-generated. Therefore, a warning is emitted when you try. Instead, you can set the callSuper parameter to true which will call super.equals and super.hashCode. Doing this with java.lang.Object as superclass is pointless, so, conversely, setting this flag when NOT extending something (other than Object) will also generate a warning. Be aware that not all implementations of equals correctly handle being called from a subclass! Fortunately, lombok-generated equals implementations do correctly handle it.

Array fields are handled by way of Arrays.deepEquals(Object[], Object[]) where necessary, as well as deepHashCode. The downside is that arrays with circular references (arrays that contain themselves, possibly indirectly) results in calls to hashCode and equals throwing a StackOverflowError. However, the implementations for java's own ArrayList suffer from the same flaw.